ASP.Net Custom controls vs. user controls: Are these two the same - asp.net

If they are different, under what circumstances should we decide to use either approach?
Also, what is the advantage of ascx over aspx?

user controls are a form of custom control, that gives you a visual designer. They are ideal for use when you want a reusable control within the same web site. (It is possible to create and package user controls as seperate assemblies but that is beyond the scope of this question and I know has been asked on SO).
A custom control is typically used to refer to a Web Control, or a Composite Control which is specialized form of a web control. These controls have no designer and are usually implemented in seperate projects from your web allowing them to be reused accross many sites.
Now your second question, ASCX and ASPX are two different things. ASCX is the extension for a User Control, where as ASPX is an ASP.Net Page. You cannot use an ASCX by itself it must be placed onto an ASPX or Master page.
One way I like to use user controls is I have for example a very complex page which have 7 tabs, 5 of those have grids, of those grids three of them are identicle. Well what I can do is create a seperate user control for the content of the tabs, this now reduces the code I need down significantly (Since three grids are identicle except for the data).
Further more it allows multiple to work on various parts of the page, and it helps me keep everything straight since I am reducing the complexity of the page. You do not use User Controls instead of Pages, you use them in conjuction with a page.
Edit
You do not use ascx over aspx. You use ascx to complement. For example on my site every page has the same footer, but I don't want every page to derive from a single master page. I can create my footer as an acsx control and put it in each of my master pages.
Another example, I have a form that lets a user enter three different date ranges. (And we have other forms). So I put the logic to enable a calender button, and a text box that when clicked on opens up the calender, in a user control. I can then reuse that user control in all my aspx pages.

Custom controls are control build entirely in code. The pro is that you can put them in libreries, add an icon to the toolbox and other fine control.
User controls are more easy to do, and in general is a way to encapsulate things to simplify other pages or when you need to use the same markup in several pages.
The advantage of controls over regular aspx pages is that you only need to do some part of the markup (not the whole page)

User Controls/Composite controls
User controls that are made up of other ASP.Net or custom controls. They are usually quite straight forward and can be created quite quickly. They Are generally not shared across projects however there are some tricks that can allow you to do this.
Custom controls
Custom controls are controls that you implement the UI by creating everything from the HTML output to design time support. Custom controls take much longer to make. You must use either Web.UI.Control or inherit from a sub control (Textbox for example). Custom controls are compiled to binary format to allow them to be distributed more easily. Since they are compiled they can be referenced from the toolbox in visual studio.
There are 2 main advantages to using a control in an aspx page. Encapsulation of logic and reuseability.

Related

Why don't my user controls render?

I've created a set of user controls in vb.net and in their original project they work fine.
I've since created a user control library dll and I wish to use it in a new project.
I add the reference to the dll fine, specify the tag library in an asp.net page fine and define controls on the page fine.
Everything seems to work except I get no rendered output.
Various properies of the controls and the page_load methods are all called.
Asp.net trace shows the controls in the page hierarchy etc
Just no output where the controls should be - any suggestions?
Update 1
I just compared a trace of the working output compared to the non working.
The working output contains the user controls (and all elements in them)
The non working output only lists the user controls - no content
It therefore seems that the content of the controls is missing somehow - as if the markup is not being compiled with the codebehind, only the codebehind seems to be working.
Update 2
The controls are inheriting from UserControl not control.
You are correct in your summarization in Update 1- your markup has not been included!
You need to provide a bit of elbow grease if your trying to distribute .ascx controls in a .dll but not too much thankfully.
The two main things you need to do:
Embedded your .ascx controls. The .ascx controls need to be marked as an embedded resource in your .dll (as oppossed to 'content')
Create a VirtualPathProvider. This will allow you to load the ascx files directly from the dll they are embedded in.
Unfortunately explaining step 2 is slightly lengthy, however this excellent article helped me out in doing exactly what you want to do.
The beauty of distributing .ascx controls like this is that you dont have to tear your hair out writing custom controls (rendering anything over than very simple html is a nightmare to make sense of).
I assume that you are not confusing between user control (.ascx) and custom controls. For user controls to work, one needs both ascx (mark-up file) along with corresponding code-behind class. User control are typically consists of constituent child controls whose hierarchy is specified within ascx file that provides some UI. In a class library (dll) project, you cannot package ascx files - all you get is the code-behind class. Without ascx, the code-behind class will not have any child controls and hence will render empty. In short, you cannot package user controls (ascx) in a class library - you have to add them into your actual web project.
For shared control, one has to use custom controls. Custom controls are code-only and typically provides render override that emits necessary html (or creates the own child control tree dynamically). These controls can be package as a class library and shared across project. Typically, a custom control will also have other helper classes to provide design time assistance (UI Editors etc).

why not user control?

why should be used use control template in asp.net? please, someone say me.
Can anyone tell me why I should use a Control Template over a UserControl in ASP.Net?
If you're familiar with MVC, a User Control is like the WebForms equivalent of a partial view.
Update (when I answered, the question asked when to use a User Control...):
A server control is appropriate when you want to bundle assets and functionality for wider distribution than a single project. It is more complex to develop a server control than it is a User Control, but a server-control allows you to completely encapsulate HTML, CSS, JavaScript, images, and server-side logic within a single DLL.
Conversely, a User Control is much easier to develop, but cannot contain assets such as external CSS/JS or images. User Controls are basically just partial bits of an ASPX page.
Unless you know that you need the features of a server control, I would always recommend a User Control for simple de-duplication of content that's repeated in multiple ASPX pages.
A User Control enables you to create your own custom control modules. They're useful because they are reusable, meaning you don't have to duplicate a lot of code. You can embed them in ASP.net pages, and you can define methods and properties for them.

Dynamically creating many instances of ASP.NET usercontrols: How do I create it, and where will my conflicts be?

I haven't seen this implemented before in ASP.NET, but am thinking about a UI that would look and act like this:
Conceptual Overview
A TabControl is loaded and the first tab contains a grid
When a row is double-clicked, a new tab is created with the record detail
The content of the tab/record detail is created by a usercontrol
Many tabs could be created, and therefore many instances of the usercontrol will be created
I know ASP.NET will rename my (runat="server") ID's for me, and that I can use jQuery or ASP.NET server-side code to work with the ID's... My concerns are:
How can I ask ASP.NET to generate a unique ID for each Nth instance of my usercontrol (to be rendered in a placeholder)
How do I actually create that extra instance of the control?
What else do I need to keep in mind?
Since I don't want postbacks I'm considering basing my implementation off of ComponentArt's Callback Control, and using ASP.net usercontrols to achieve this effect. This will allow me to do most things that require a postback, but won't refresh all the elements on a page... just the section that contains the user control. That being said, I'm not tied to a particular implementation.
You should look into the Page.LoadControl method. It works nicely and as far as I remember you put placeholders on your page and load the controls into the PlaceHolders, that's how you control the ids.
One thing that doesn't work out so well with this approach is when your control raises events that your Page object has to handle. If your control is selfcontained however you shouldn't have a problem.
This might help you get started:
http://www.codeproject.com/KB/aspnet/LoadingUSerControl.aspx

Custom server control, with form and scriptmanager

I am building a set of asp.net server controls and in one of them, essentially a container control, I want to add a form control, a script manager and an update panel. Is this possible or will I have to create these in a Page base class that I have for the web project for page/control life cycle reasons?
I am not using master pages.
Regards,
Andrew
ASP.NET allows only one form on the page. When you create controls, they are used on a page. You need a Page object to add controls to. This is why controls like the form and ScriptManager (who can only have one instance on a page) are put on the Page itself, or on the masterpage (if you have one). Putting them in a control would provide the opportunity to have two instances on the page, which would not work.

Visual inheritance in ASP.NET without master pages

I have a certain page and depending on an administrator role a lot of extra validation controls have to be inserted. However I don't want to take the risk that a validator gets turned on for other users.
What I was thinking is to use some form of "Visual inheritance" but I don't know which path to choose. Perhaps have separate .aspx pages which inherit from the same class (which inherits from Page)?
Side note: this has to be done in webforms, not mvc.
Extra information: The problem I'm trying to solve is the separation of roles and the impact on the page without having to duplicate the page and having to maintain any changes in both. There are clients who get to see the vanilla page and admins can see the same information but with added validation controls. However these validation controls should not be seen by the clients. Also some more information can be seen but that could be handled by using rolebased viewing of certain user control.
Anyone has an idea about this?
Why don't you want to use master pages? Master pages do exactly what you want to do - they can even "inherit" from each other (in a manner of speaking).
I would suggest that you use master pages to do what you want.
ASP.NET master pages allow you to
create a consistent layout for the
pages in your application. A single
master page defines the look and feel
and standard behavior that you want
for all of the pages (or a group of
pages) in your application. You can
then create individual content pages
that contain the content you want to
display. When users request the
content pages, they merge with the
master page to produce output that
combines the layout of the master page
with the content from the content
page.
If the problem you are trying to solve is role based viewing of controls and you are using the builtin asp.net membership/roles providers, you could use the LoginView control to manage the visibilty of the admin stuff:
<asp:LoginView runat="server" ID="LoginView">
<RoleGroups>
<asp:RoleGroup Roles="Admin">
<ContentTemplate>
Special Admin content
<asp:RequiredFieldValidator></asp:RequiredFieldValidator>
</ContentTemplate>
</asp:RoleGroup>
</RoleGroups>
</asp:LoginView>
Often such problems can be solved by splitting the page into user controls (.ascx). It can become a bit messy, but gets the job done.
Inheritance of pages is difficult, although possible. What you must realize, is that one .aspx page cannot inherit from another .aspx page. This is because of how the ASP.NET compiler works: your .aspx XML markup is compiled into a class that derives from your code-behind class. Since this only happens at runtime, you cannot have another .aspx page inherit from it, because the class is simply not there when the code-behind is being compiled.
What you can do is to create another class that inherits from Page and make your .aspx code-behind classes inherit from that. That is possible, but note that this class will not have an .aspx XML part - you will have to instantiate all the controls yourself, as well as assign their properties. In most cases this will be quite messy.

Resources