I have what I imagine to be a pretty standard web-interface.
There are 4 different ListViews (grid controls) which are accessed by a series of Tabs on the top.
I have implemented this as follows:
alt text http://img402.imageshack.us/img402/1530/pagedu8.jpg
Tab 1 will load Page 1 containing Grid 1 into Frame 2, Tab 2 will load Page 2 containing Grid 2 into Frame 2 etc.
However this then means that if you click on an item in the Grid, and I load DetailsPage1.aspx into Frame 2, then Frame 1 and the tabs are still visible and active.
I've been advised that I should just have one Frame, and load the Pages in dynamically based on the tab click, using HttpRequest (or WebRequest in asp.net).
Is this the correct approach to take? If you have any resources or tips at hand, it would be appreciated!
Thanks
Frames are an absolute no-no. There is no benefit to frames that can't be achieved using other techniques.
Does that mean you must use AJAX? Not necessarily. AJAX is a perfectly good solution if you feel the need to provide a rich, seamless interface, but it's not strictly necessary.
You could use server-side includes to separate your tabs into a another (common) sub-page, but since you mention ASP.NET, (assuming you are running on framework v2 or greater) you might want to use Master Pages, where your tabs are in one content section or in the Master itself, and your grids/details are in another content section.
The key difference between the two techniques is that using AJAX, the transition from tab to tab will be slick and seamless, but a) it takes a little extra work (particularly if you are unfamiliar with any give AJAX framework) and b) since you essentially have 4 pages rolled into one, the pages are 'heavier' and are more complex to maintain. If you opt for the non-AJAX route, the key difference is that there will be a small but distinct refresh effect when you click on each tab (since it loads a new page each time).
Of course, Master Pages are useful for maintaining a consistent site style and structure anyway, so there is no reason why you can't use AJAX with a Master Page system.
Frames are lame: you will get problems, if users want to set a bookmark and if users visit your site via google: Then your navigational frame is not visible. So you need a lot of dirty javascript. to check this. If you need javascript, do it right from the start and use AJAX
Ajax is the best pick. But keep in mind to make it browse-able via back/forward. The best pick is to change page hash. I used something like this:
domain.com/#tab1 for first tab
domain.com/#tab2 for second tab
and so on.
If you use jQuery, this can be a good start (i use that and i had NO problem with). I'm sure there is a solution for all popular framework though :)
Instead of using frames, you should just include your navigation page in all of your other pages. The browser will see that you're including the same document in all of your pages and cache it.
Have you tried the TabContainer or loading all 4 detail panes and just showing/hiding panels on tab selection change?
Depending on what screens your users will see, if you load the detail views dynamically (Ajax or postback) you may have trouble persisting any information that the user has entered, and you will incur a wait (users dont like to wait)
I would recommend using jQuery and jQuery UI plugin. No frames will be needed, just div containers.
Like StingyJack, I would suggest having a look at the TabContainer control, but you might want to take care that your ViewState doesn't get too large if you do.
So for example, don't load anything into a GridView until that Tab is being viewed and remove it contents if it is not (saving back to the database of course if required. Using the TabContainer's ActiveTabChanged event would be key to this strategy.You diable ViewState for the grids but leave it on for the container.
You're using ASP.NET, so just load all 4 controls into a mutliview and then on postback set the visible one to be which ever button has been clicked.
http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.multiview.aspx
DO NOT uses frames (or iframes for that matter) unless you absolutely must...
The only valid reasons I can think of to use (i)frames is file upload controls in fact, and I am not sure it's valid there either...
Related
Sorry in advance if this is not the right place to ask this.
I have a task of making a asp.net site into responsive. The site consists of various ASP.NET controls as well as Telerik ones. The problem is that the designs that i have for the mobile view do not comply with the current structure of site, so in many occasions i have to put the same control twice in the same page, and the hiding/showing depending on the width of the screen.
So i did my research and found that only unique IDs are permitted in same page. Is there any alternative to have the same control twice in same page?
No, there isn't. Controls' IDs must be unique.
Perhaps wrapping them in user control instances and using those a few times over and exposing public properties for what you need is one approach.
Consider using tools like RadPageLayout that help you hide/move unwanted controls/pieces of the page: http://docs.telerik.com/devtools/aspnet-ajax/controls/pagelayout/overview.
Or, create helper methods that get the needed user input/control depending on what is visible or not. These could even be properties in your page that return the currently visible control so you can set properties, data sources, get input, etc. With this you will reference the duplicated controls via this property rather then via their instance ID. Tough to maintain, but without completely redesigning your page and needing duplicates I am not sure there is much else you can do.
I am developing a website using asp.net 4.0(Browser IE8).My page contains a tabcontainer with 5 tabs .Each tab contains a grid without paging i.e each grid can contain 250 to 300 records. I am loading tabs on demand but once all tabs are loaded. My UI becomes too slow. How do i manage to make my UI faster & smoother ?
What do you mean by loading tabs "On Demand"? If it just means that you populate grid data when tab is clicked then it explains your problem. Essentially, ASP.NET data bound control stores their data into view-state, so as you go on loading the grids, your view-state keep increasing and essentially, you have a large page size making page retrieval and post-back slower.
Quick solution will be to disable view-state for all grids and always bind the grid on current tab from actual data store (you may cache the data on server side in session or ASP.NET cache for improved performance). This will make sure that only one grid is populated at a time and there is no-burden on the view-state.
Alternate techniques will involve loading contents for only current tab but it involve arranging contents into user control etc and a bit tricky to get working in post-back scenarios etc.
Relatively simple approach is to use your own control/html to render tabs and each tab is a GET request to a separate page. For example, if you have four tabs then you will have one master page providing common layout including tabs and 4 content pages representing each tab.
If you want to avoid page refresh on tab switch then you may try loading content page using AJAX request.
I'm not certain if this will help your issue or not, but one option is to hide the grid contents (style.display='none') when the user switches to another tab. It's worth a shot.
I have been asked to design & develop a page in asp.net which contains 7 tabs.Each table contains 2 Editable gridview & clicking on gridview cell should open a popup & that popup will open a new popup ( I would say nested popup). even when i switch from one tab to another. It should hold the griddata & whenever user will finish all the operations he/she will click on save button which will save all the data contained in the tabs.
The page is really too too too heavy. It will definitely take a long time to load as it contains gridview operations , popup related jobs, tab data & tab switching.
I am finding the best way i can achieve this with an acceptable speed of operation. Any suggestions or help would be greatly appreciated.
With all of the web-based controls (tabs, grids, anything that uses an intensive postback model) included in ASP.NET, plus those made by 3rd party vendors (Telerik, Infragistics, and the like), it is possible to make very big web pages. And I've made more than a few in my days. Tabs. Multiple update panels. Drop-downs created from dozens of sources. I have decided to remember one simple fact:
WEB_APPLICATION != CLIENT_SERVER
Just because you can, doesn't mean you should. If changing the UI is not an option, keep in mind the following
Look into paging your grid views. Limiting the amount of data rendered on the page will speed up the page.
You can look at caching operations. If you have access to modern browsers, you can make use of isolated local storage on the client. This will be even faster than caching on the server, but you're limited to the really new stuff.
Become a big friend of partial page loads and AJAX operations. You can still build a bigger UI, but keep the actual data operations small and focused. Data-driven drop downs on a hidden tab can be loaded after the visible components of the page have loaded.
I've made a lot of customers very happy because I keep my UI's incredibly fast, and they never break. I keep them fast by keeping them focused. A page is built for a single task. Design for simplicity into UI. You will not be sorry.
Paging.
Caching.
Lazy Loading (through Ajax).
I am not a ASP.net programmer but I think you need to go back to the basics. I am assuming that gridviews are tables.
You could look into the following basic optimizations:
each of your 7 tabs could be a separate http request, that would cut down your load times by 7 for starters
Possible use a combination of cookies and session objects to hold on to the data in the other 6 tabs.
Also, as #LordCover suggested:
Look into ASP.net caching options if any
Use Ajax where you can (editable table cells)
Also, think in terms of the HTML being generated from the ASP page rather than have a completely ASP centric mindset around this.
Also do not rule out a UI redesign, there are many ways to do the same thing. You may be able to break up the UI into simpler pages
What choices do I have for creating stateful dynamic content in an ASP.Net web site?
Here's my scenario. I have a site that has multiple, nested content regions. The top level are actions tied to a functional area Catalog, Subscriptions, Settings.
When you click on the functional action, I want to dynamically add content specific to that action. For example, when Catalog is clicked, I want to display a tree with the catalog folders & files, and a region to the right for details.
When a user clicks on the tree, I want a context sensitive details to load in the details region (like properties or options to manage the files).
I started with UserControls. They worked fine as long as I kept loading everything into the page, and never let one disappear. As soon as one disappeared, ViewState for the page blew up because the view state tree was invalid.
(I didn't want to keep loading stuff into my page because I don't want the responses to be too huge)
So, my next approach was to replace my dynamic regions with IFrames. Then instead of instantiating a UserControl, I would just change the source on my IFrame. Since the contents of the IFrames were independent pages I didn't run into any ViewState problems.
But, I'm concerned that IFrames might be a bad design choice, but don't fully understand why. The site is not public, so search engines aren't a concern.
So, finally to my question.
What are my options for this scenario? If I choose an Ajax Solution (jQuery), will I have to maintain my own ViewState? Are there any other considerations I should take into account?
Controls that are added dynamically do not persist in viewstate, and this is the reason that it doesn't matter if you use AJAX or iframes or whatever.
One possible work-around is to re-populate controls on postback. The problem with this, is the page life-cycle (simplified) is:
Initialize
LoadViewState
Load Postback Data
Call control Load events
Call Load event
Call control events
Control PreRender
PreRender
SaveViewState
Unload
What this means is the only place to re-add your dynamic controls is Initialize -- otherwise posted data (or viewstate information) is not loaded into that control. But often, because Viewstat/postback data isn't available yet in Initialize, your code doesn't have the information it needs to figure out which controls need to be added.
The only other work-around I've found in this situation is to use a 3rd party control called DynamicControlsPlaceholder. This works quite well, and persists the control information in viewstate.
In your particular case, it doesn't seem like there are that many choices/cases. Is it practical just to have all the different sets of controls in the page, and put them inside of asp:placeholder controls, and then just set one to visible, depending on what is selected?
Some other options:
Content only appears to be dynamic. You load enough controls on the page to handle anything and only actually show what you need. This saves a lot of hassle messing with view state and such, but means your page has a bigger footprint.
Add controls to the page dynamically. You've already been playing with this, so you've seen some of the issues here. Just remember that the place to create your dynamic controls for postbacks is in the Page_Init() event, and that if you want them to be stateful, you need to keep that state somewhere. I recommend a database.
you've got a number of different options, and yes, IFrames were a bad design choice.
The first option is the AJAX solution. And with that there's not really a viewstate scenario, it's just you're passing data back and forth with the webserver, building the UI on the fly as needed.
The next option is to dynamically add the controls you need for a given post, everytime. The way this would work, is that at the start of the page life cycle, you'd need to rebuild the page exactly as it was sent out the last time, and then dump out all the unneeded controls, and build just those that want.
A third option would be to use Master pages. Your top level content could be on the Master page itself, and have links to various pages within the website.
I'm sure given enough time, I could come up with more, but these 3 appeared just from reading your problem.
dynamic controls and viewstate don't mix well, as noted above - but that is a Good Thing, because even if they did the viewstate for a complex dynamic page would get so bloated that performance would diminish to nil
use Ajax [I like AJAX PRO because it is very simple to use] and manage the page state yourself [in session, database tables, or whatever works for your scenario]. This will be a bit more complicated to get going, but the results will be efficient and responsive: each page can update only what needs to change, and you won't be blowing a giant viewstate string back and forth all the time
I've got a web application that I'm trying to optimize. Some of the controls are hidden in dialog-style DIVs. So, I'd like to have them load in via AJAX only when the user wants to see them. This is fine for controls that are mostly literal-based (various menus and widgets), but when I have what I call "dirty" controls - ones that write extensive information to the ViewState, put tons of CSS or script on the page, require lots of references, etc - these are seemingly impossible to move "out of page", especially considering how ASP.NET will react on postback.
I was considering some kind of step where I override Render, find markers for the bits I want to move out and put AJAX placeholders in there, but not only does the server overhead seem extreme, it also feels like a complete hack. Besides, the key element here is the dialog boxes that contain forms with validation controls on them, and I can't imagine how I would move the controls and their required scripts.
In my fevered imagination, I want to do this:
AJAXifier.AJAXify(ctlEditForm);
Sadly, I know this is a dream.
How close can I really get to a quick-and-easy AJAXification without causing too much load on the server?
Check out the RadAjax control from Telerik - it allows you to avoid using UpdatePanels, and limit the amount of info passed back and forth between server and client by declaring direct relationships between calling controls, and controls that should be "Ajaxified" when the calling controls submit postbacks.
I recommend that you walk over to your local book store this weekend, get a cup of coffee and find jQuery in Action by Manning Press. Go ahead and read the first chapter of this 300 page book in the store, then buy it if it resonates with you.
I think you'll be surprized by how easy jQuery lets you perform what your describing here. From ajax calls to the server in the background, to showing and hiding div tags based on the visitor's actions. The amount of code you have to write is super small.
There are a bunch of good JavaScript libraries, this is just one of them that I like, and it really is easy to get started. Start by including a reference to the current jQuery file with a tag and then write a few lines of code to interact with your page.
Step one is to make your "dirty" pieces self contained user controls
Step two is to embed those controls on your consuming page
Step three is to wrap each user control tag in their own Asp:UpdatePanel
Step four is to ensure your control gets the data it needs by having it read from properties which check against the viewstate for pre-existing values. I know this makes your code rely on ugly global variables but it's a fast way to get this done.
Your mileage may vary.