I have created certain functionalities for an application. These functionalities include -
ADD USER
EDIT USER
DELETE USER and so on
Now I have written all these in seperate pages. So when I have to delete a user I go to USER_DELETE.aspx page to do that.
My new requirement is that there should be a single page from which all these can be done. Being more specific, I want that there should be separate panels in a page called "USER_MANAGER". Each panel will have the required functionality.
Is there a way I can do this by just creating the new UI of the USER_MANAGER page and calling the other pages (as User Controls or any other easier way) into the UI of USER_MANAGER?
I don't want to do any changes to the existing pages for various functions. I hope the question is clear, I am a bit novice in this technology so I am not really sure.
Thanks and regards
It sounds like you want to turn your pages in to ASP.NET User Controls. User Controls are just as easy to create as pages and can be used in similar fashion as Server Controls. If you want to create controls that can be shared between projects, then you want to write Server Controls but thos cases are probably not so common.
There are many ways to tackle this problem. If you are listing the users in a gridview you could use inline editing and do it within there.
You could retain the pages you wrote and use a modal popup or iframe. Another way would be with a multiview or tabs or panels.
I would design the UI and the then decide what the best solution for your application is then write these elements.
Related
I have an existing web application built using ASP.NET 4.0 and C#. The application has an Administration page, that contains many different sections in which you can change different settings. I've attached screenshots for clarity.
Currently everything is contained to one page. Which means I have a massive amount of controls on just one page. I would like to have a navigation panel where you could select the "section" you want and it would load a central content area with that "section". I'm wondering what would be the best way to do this. Would it be best to make each section it's own control, or would I separate each section into a separate page?
I want to make sure I go about it the right way so that it will be easy to maintain and scale.
I appreciate any help.
I would definitely recommend using controls for each piece. The nice thing about controls is that if you ever need to use them in a completely different part of your application you are good to go!
As for loading in separate controls you can simply use query string variables. For instance let's say you have an anchor tag like this:
Business Hours
Now we can build a single page: /admin/index.aspx and on the page load we can check the query string. Now depending on that query string we can then load the appropriate control.
Reading from a query string: http://triaslama.wordpress.com/2008/04/12/retrieving-query-string-values-in-aspnet-and-javascript/
Loading User control via code behind: http://www.codeproject.com/Articles/1939/Programatically-include-an-ASP-NET-UserControl-in
If this is too hypothetical and needs to be somewhere else, please let me know.
I have a project that needs specific gridviews to appear on multiple pages. Instead of copying and pasting the gridviews on each of the pages I thought creating a user control for each specific gridview or create a page for each gridview and then use iframes would be my best options.
I have not used either extensively so I am looking to the SO community's experience, are there known problems with using user controls and/or iframes when it comes to:
validation
communication between user control/iframe and parent page
ajax/updatepanels containing user control/iframe
thanks in advance
Since a gridview is essentially a user control (that's very flexible), I would first explore doing this with neither of your options. If possible, use the standard gridview and let your data layer do most the work. However, assuming you already know that... but your requirements require one or the other of your options, here are things to consider.
An iframe is easy to implement but unless your need is really simplistic in terms of user interaction, the user control will be the most flexible. Another downside to an iframe is it's size (you're essentially loading two pages). The downside of user controls are the upfront time in building them.
Based on your criterion:
1. validation - can do with either option but you'll have more flexibility with a user control
2. communication between user control/iframe and parent page - much easier with user control unless query string parms will do the trick
3. ajax/updatepanels containing user control/iframe - again user control
Using which of these is the best approach while planning Silverlight application? UserControls or Page.
My understanding is that when you have to encapsulate some of the logic of some component, which is truly generic and reusable then use usercontrol else use Page because Page is tightly integrated with browser's history etc, so you can move back and forth and can make use of NavigationService to navigate across pages because if you keep using usercontrols, it is very tiresome to navigate all the way to the required page. Thus we cannot bookmark it because it serves no purpose. We will have to again find our way through the menus in application to reach our desired location.
Is my understanding correct?
Your understanding is correct. Use Pages to integrate with the Navigation framework and the main pages and controls for custom components etc.
I am struggling with finding clear answers to dynamically creating the same page over and over. The questions and samples I have found seem to be all over the board on this topic. I have studied the life cycle and still seem to not have a clear answer as to where code should go.
I have a master page and a content page. All the content in the content area needs to be dynamically created (text boxes, ddl's, page tabs, buttons/onclick etc.).
After a user fills in data and clicks a submit button, I need to read the values off the form and rebuild the page completely again (not add/remove controls to current content).
My question is then.
Where do I put my code to build the page?
Will this area allow me to use IsPostBack so I can rebuild content with Request.Form values?
Will my buttons _Click events work?
Are there any working samples out there you could direct me to?
Thank you very much for the feedback...
I don't know all the answers to your questions, but I hope this may get you started. When dynamically generating the UI through code, this happens in Init. Controls dynamically loaded on Init is key because between init and load, on postback, viewstate is loaded for these controls.
This means you need, on every postback, recreate the page as is to match the previous control tree, then deconstruct it after init and recreate the new UI, if something is supposed to change UI wise. This is because it validates the tree structure to determine its the same UI. Now, if you don't need viewstate, this may not be as much of an issue. I haven't verified this without viewstate to see if it behaves different.
It depends how dynamic you need it, whether you need viewstate (is a big factor).
HTH.
Try creating the controls in the page's PreInit method. "IsPostBack" should work and the click event handlers should work as well.
What you need is a web user control, see ASP.NET User Controls
Brian's advices are good and you should follow them.
This might not really answer your question but still I add it as an advice. I'm professionally creating ASP.net web applications at quite a large scale and from my experience I can say that too much "dynamics" is usually bad and should be avoided because it just introduces complexity. Normally you might want to expose UI parts into ASP.net UserControls or if you want to make them even more reusable (if that's a factor) then into ASP.net Server controls. Then you replace different of them dynamically rather than creating everything from scratch.
User Controls -- Do they serve a special purpose?
As far as I can tell they are no different to forms - they have the same toolbox and features.
Are there certain times when they are appropriate to use over forms?
It would be interesting to understand what they are good for.
You use them to group a set of controls and behaviors together in a re-usable way. You can't show a control on the screen unless it's added to a form somewhere.
One good example is a textbox. It's very common to have a label next to your textboxes. You can build a user control to make this easier. Just drop a label and a textbox on the control, expose whatever your properties you want, setup the new control in your toolbox, and now you can just drop this control on your form instead of needing to arrange a label and a toolbox on the form separately.
You could kind of think of them as a panel which "remembers" what controls you put on it. And there's one more important piece. You can put code in these controls as well, and use that to also build special behaviors into your custom controls.
I have to disagree (slightly) with the selected answer. Reusability is only part of what a UserControl is for.
All Controls are reusable. Almost all controls are reusable on the same Form/Window/Panel/etc. For example, a TextBox is a control.
There are two ways to create your own reusable control:
Custom Control
Completely custom, and reusable.
Created entirely in code.
You get a bit more granular control over what your control is doing this way.
Lighter weight (usually), because there isn't anything added in for designability within Visual Studio.
In ASP.Net only: No "HTML" type file to use or edit.
User Control
Completely custom, and reusable.
Created partially in a designer in Visual Studio, and partially in code. (via code behind)
Much easier to deal with from a visual aspect.
A little heavier, as there is pre-existing code added in by the framework to support designing inside Visual Studio.
In ASP.Net only: You can change the appearance a bit simply by editing the .ascx file (basically HTML).
User Controls serve the purpose of reusing controls.
Imagine you need a search box in several pages of your application. You can create a search user control and drop it in every page where you want it visible.
So, it's nothing more than a container that aggregates reusable blocks for your pages.
Forms have a lot of extra furniture that you don't need if you simply want a collection of controls together - the minimize and maximize buttons for example. If you just simply grouped your controls in a Panel, you'd have all the event handlers on the same form as the panel - with a user control, the event handling code is in the user control class, not the form class.
You can reuse the same control on many forms. In fact all items you are using while creating windows forms are the controls. User controls are just extra controls extending controls library provided by .NET.
In ASP.NET, user controls enable you to split your page into reusable components. For example, you may want to have a search box which can be used in different places on your website, so you'd use a user control. They can also be used for partial page caching. You can cache portions of your page to improve performance.