Eden Ridgway's Blog

We have always taken a framed approach when designing the sites. Hence we'll have frameset for the site with two frames containing the top navigation menu and the main content area. In the administration section of the site we'll often have three pages per logical page:

1. A frameset page
2. A left hand list page (where the filter is in the diagram above)
3. The add/edit page on the left hand side

So for every administration screen we have three pages instead of one and have two levels of frames (or a frameset nested inside of a frame in another frameset). Whether we were using IFrames or normal frames it would not really make any real difference (but we do love IFrames). Proponents of this approach (and I used to be one of them) will tell you the following:

1. It is more efficient it is to update part of the page in a frame rather than the whole page
2. It leads to modular code since you code the add/edit logic on one page and the list logic on another

This approach faces a problem when it comes to updating the list on the left hand side:

You have to wire in logic when the page is rendered after a save to refresh the list on the right hand side. Some people go so far as to call location.reload() on the whole frameset page.

I personally think that this should be changed for the following reasons:

1. There is a lot of duplicate layout code. By this I mean the frameset and listing pages are copied for each administration page and site. If we were to change the way the pages looked or were skinned (which we did) it would require a big effort on our part.
   
2. The problem mentioned above where you have to use JavaScript to synchronise the list information is not a very elegant solution.
3. I don't believe that the overhead of sending the list to the client on each call is that significant particularly since the majority of users are intranet users.
4. We could use masterpages to replace our n x 3 page approach with a 1 (masterpage) + n page design.
5. We are missing out on making the pages more generic. Surely we should be able to change the list area into a control that is used across applications. All that one should need to do when creating an admin page is worry about how to retrieve the list data and creating the add/edit functionality.

This leads one on to another area of discussion. Shouldn't the entire site be using MasterPages? As Scott Rosa points out in his article Working with Frames in .NET the client doesn't always need to see a complete page refresh. The SmartNavigation property of the page (can be set in the @page directive) gives you the following functionality transparently for I.E. 5.5 and above:

• Elimination of the page refresh flash
• Persists the page scroll position
• Persists element focus between navigation

Of course that seems to be too good to be true. There appears to be several people on the web who have had issues with SmartNavigation. It has also been deprecated (but is still supported) in ASP.Net 2 (see: http://forums.asp.net/thread/1204983.aspx). It has been replaced with MaintainScrollPositionOnPostBack and SetFocus properties. This however only covers part of what SmartNavigation did. A possible solution if page refreshs are such a big isssue is to use the Atlas update panel. Scott Allen seems to think this is a bad idea, but I don't think the statements he makes is convincing at all. You could also use IE only CSS page transitions to hide refreshes (examples can be found at: http://www.permadi.com/tutorial/iePageTransition/index.html).

I personally however would much rather try and keep it simple and have brief page flashes. If one is really concerned you could hook in a loading or processing message that appears everytime a form is submitted to the server.

Other Reading:

• http://geekswithblogs.net/synboogaloo/archive/2005/04/27/38504.aspx