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.
Related
The original problem is how to make the most maintainable code given that I need to have a menu bar that is very similar but not identical in most WebForms.
At first glance I thought I wanted to make a placeholder in a custom user control, which was placed in a master page, then access the placeholder, putting in the unique content within the WebForm and all is happy and maintainable. After reading through the forms and through trial and error, I realize there are some problems with every solution I have tried:
Putting a placeholder control in a user control makes the placeholder and each of its contents difficult to access in the web form (relying on nested instances of FindControl("ID")), events are difficult to bubble up (I assume I have to do this when the control is created in the code behind where it is referenced) or bind (not successful yet despite referencing: http://msdn.microsoft.com/en-us/library/t4z863dh(vs.71).aspx), and the code is difficult to maintain if I want to move/rename the control.
Nesting controls gives the same problem because I want to use one control - making small modifications on many pages. If I nest then I still have to have cross-control knowledge of each other which is difficult in ASP.NET. Regardless, if I nested user controls then I would also need a unique user control per WebForm right?
Copying and pasting the code to each WebForm while simple is also repetitive and error prone.
Apparently, I shouldn't even try to inherit user controls to make unique children: How (if at all) can you make an ASP.NET UserControl inherit from another UserControl?.
I'm new to ASP.NET. Is there some general strategy I should use to make good maintainable code in this scenario?
You need to use a Master Page, and put your menu in there...
http://msdn.microsoft.com/en-us/library/wtxbf3hh(v=vs.100).aspx
Then, for a data-driven menu, try to use one of the template controls like the Repeater to bind your data.
For example, I have a query that returns Page Name and Link - I bind this to a Repeater control to produce my Menu.
<asp:Repeater runat="server">
<HeaderTemplate><ul></HeaderTemplate>
<ItemTemplate><li><a href='<% Eval("Link") %>'><%# Eval("PageName") %></a></li></ItemTemplate>
<FooterTemplate></ul></FooterTemplate>
</asp:Repeater>
So far, all the web pages I met contain at most one <form> tag. Why not multiple ones? I can not think of reasons why multiple forms can't coexist within the same web page.
Also, to be specific to ASP.NET - why are all the server controls are placed within the <form> tag? Why not place them somewhere else?
Plus,
I noticed that in an .aspx file, the <form> tag has the runat=server attribute, while a normal server control such as Button also has one. So it seems the <form> is also a server control. But strangely enough, I cannot find it in the Visual Studio Toolbox.
There can be multiple forms, with hacks.
It is indeed a shortcoming of WebForms. In ASP.NET MVC you can implement as many forms as you want (and it is valid & correct behavior of web pages).
The reason all server controls are placed inside <form> tag is to allow the WebForms engine to recognize them, load their values & save their values from/to the ViewState. Almost all infrastructure of control management in WebForms is based on the idea that a tag contains everything you access from the code-behind.
As pointed out, this is one of the shortcomings of WebForms. I do want to point out, additionally, that with cross-page posting and validation groups, you can typically reach your desired behavior (for most "multi-form" solutions).
Regarding the additional question: the <form runat="server"> is parsed as HtmlForm class behind the scenes, which inherits from HtmlControl like any other HTML element with runat="server".
Unlike any other HtmlControl though, there can exist only one instance per page and it does not appear in the toolbox as it's added automatically to every new Form you create, so it's quite pointless.
Yes, it can be done - by creating a custom HtmlForm object and toggling the forms as needed. I've just answered a similar question here (with code):
Paypal Form Ruins My ASP.NET webforms layout -> How to Solve?
many non server forms - you can , but only one runAt Server form
i also found this :
A server-side form tag is the tag which has a runat="server" attribute. If this attribute
is missing, then it's a typical HTML form tag. The conclusion is that you are allowed to use
multiple form tags on a page, as long as only one has the runat="server" attribute. The
disadvantage of the form that doesn't have this attribute, is that view state won't work
(meaning form values will disappear when using the back/forward browser buttons). It's a
small price to pay if you really need multiple forms on a page.
Take master page & set design.
Take one form in master page.
Second form take in contain place holder.
In contain place holder in only for write form tag (not use)
Add aspx page & design second form but not write form tag only for control put
Take button click event fire code write
This is proper way of two form
I'm having the following problem - I have a master page with an ASP menu control on it which is inherited by every content page of the web site.
The thing is that in (almost) every content page I have a form with runat = "server" and I get a compile error that I can't have 2 form tags with runat = "server" in one page (since I must put the menu control in another form tag).
How should I go about it? I'm doing this as a course project for a university course in C#/ASP.NET and it is said in the asignment that we must use master pages and we must use the asp navigation controls for the site navigation, so I can't use clear html for the menu or drop the master pages...
The first and easiest option is to remove the forms from the actual pages and use a single form for everything. ASP.NET Web Forms is designed to work that way. Since it is a university project this will be fine.
The better way is to use client side (no runat="server" form). You can handle the posts manually in a sort of "PHP fashion" by using the Request.Form object and read values off of it. This will not work if you are required to use the ASP.NET menu controls. So basically you cannot use this approach based on requirements.
P.S. Why is the post tagged with ASP.NET MVC tag? You should not have this problem if you are using ASP.NET MVC. There are other problems though.
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.
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.