July 2005 - Posts

Thoughts on grids and viewstate
21 July 05 09:59 AM | despos | 4 comment(s)

Fritz raises an interesting point about grids and viewstate. I replied suggesting that simply resetting the DataSourceID property (to the same value) triggers a process that in the end fixes the issue. Sure, it's kind of hacky, but it works.

However, I coundn't agree more with Fritz that 1) disabled viewstate on the grid; 2) caching through the data source control are overall the best approach to displaying data through grids without killing the page--in download, but also in upload.

I thought I should share a few additional remarks on the topic here.

Caching is fine, especially now that it is kind of "free". You just set EnableCaching and go. Note that, for some reasons, caching is not enabled (Beta 2, at least) on ObjectDataSource when you use custom collections. In this case, caching should be implemented in the bound objects--your BLL.

• Easy and blissful caching might lead to sub-optimal code if this means that you let the page cache everything results from a query. Keep the size of the data in the cache under control.
• Back to viewstate and grids, note that the size of the viewstate that results from a grid (both DataGrid and GridView) mostly depends on styles and additional helper properties being saved. Control state is not the point here, as it is saved to the viewstate hidden field anyway. It differs from classic viewstate because of the different API and because it can't be disabled. 
• True data in the viewstate for a grid is not really much--just the displayed strings.

While disabling the viewstate is definitely a good option keeping everything else that is critical to the control to the control state, I'd spend some thoughts on the fact that style properties take up most of the viewstate and they're 90% of the time constant and written to the .aspx when not in a theme. Why persisting to the viewstate? With this info in the viewstate, the grid can rebuild itself with no data access when in the IsPostBack branch. This makes sense if you want to save a roundtrip to the database, but not if you have data cached.

 

ASP.NET 2.0: ViewState Numbers
21 July 05 08:06 AM | despos | 21 comment(s)

Although they still use it as if nothing was the matter, some people are a bit worried about viewstate and security. My personal opinion is that you should be concerned about the view state, but not for the potential security holes it might open in your code—unless you love shooting yourself in the foot. You should be more concerned about the overall performance and responsiveness of the page. Especially for feature-rich pages that make use of plenty of controls, the view state can reach a considerable size, measured in KB of data. Such an extra burden taxes all requests, in download and upload, and ends up being a serious overhead for the application as a whole. Let's review some numbers trying to learn from best practices.

You should endeavour to keep a page size around 30 KB, to the extent that is possible of course. For example, the Google’s home page is less than 4 KB. The home page of ASP.NET counts about 50 KB. The Google’s site is not written with ASP.NET so nothing can be said about the viewstate; but what about the viewstate size of the home of the ASP.NET site? Interestingly enough, that page has only 1 KB of viewstate. On the other hand, this page on the same site (ASP.NET) is longer than 500 KB of which 120 KB is viewstate.

The ideal size for a viewstate is around 7 KB; it is optimal if you can keep it down to 3 KB or so. In any case, the viewstate, no matter its absolute size, should never exceed 30% of the page size. 

PS1: In ASP.NET 2.0, a new serialization format (incorporated in a new formatter class, ObjectStateFormatter), significantly cuts down the size of the viewstate by about 50%. Which is just great! All that you have to do is recompile... 

PS2: All numbers mentioned are based on the size of the pages as of July 20, 2005.

 

ASP.NET Today: Smart Delete
06 July 05 11:14 AM | despos | 8 comment(s)

DetailsView and FormView controls support delete operations and delegate the execution to the underlying data source control. If the data source control is configured to execute the delete operation, all works fine, otherwise an exception is thrown.

The DetailsView generates command buttons automatically and doesn't expose them directly to page code. How can you add a bit of Javascript code to ask for confirmation? Here's the code.

protected void DetailsView1_ItemCreated(object sender, EventArgs e)
{
   // Test FooterRow to make sure all rows have been created 
   if (DetailsView1.FooterRow != null)
   {
     // The command bar is the last element in the Rows collection
     int commandRowIndex = DetailsView1.Rows.Count-1;
     DetailsViewRow commandRow = DetailsView1.Rows[commandRowIndex];
     
     // Look for the DELETE button
     DataControlFieldCell cell = (DataControlFieldCell) commandRow.Controls[0];
     foreach(Control ctl in cell.Controls)
     {
       LinkButton link = ctl as LinkButton;
       if (link != null)
       {
          if (link.CommandName == "Delete")
          {
             link.ToolTip = "Click here to delete";
             link.OnClientClick = "return confirm('Do you really want to delete this record?');";
          }
       }
    }
}

The ItemCreated event doesn't provide any information about the row being created. However, it can be figured out that the footer row is always created and is always the last row to be created. If the FooterRow object is not null, you can conclude that all rows have been created, including the command bar. The command bar is the first row after the data rows and is stored in the Rows collection--it's the last element in the collection. The command bar is a table row (type is DetailsViewRow) and contains a cell (type is DataControlFieldCell). The cell contains as many link buttons (type is DataControlLinkButton) as there are commands. Delete, Edit, New, Update, Cancel are the command names used and useful to identify the right button.

---

The FormView is fully templated and lets you manually define appearance and behavior of command buttons. If you place a custom button, or want to use a custom command name for a standard button (Edit, New, Delete), here's how to detect the click on the button. You start by adding a handler for ItemCommand. The code below shows how to deal with a custom Delete button that checks if the bound data source control is enabled for deletion before proceeding.

 protected void FormView1_ItemCommand(object sender, FormViewCommandEventArgs e)
{
  if (e.CommandName == "SmartDelete")
  {
    IDataSource obj = (IDataSource) FindControl(FormView1.DataSourceID);
    DataSourceView view = obj.GetView("DefaultView");
    if (!view.CanDelete) {
       Response.Write("Sorry, you can't delete");
       return;
    }
    else 
       FormView1.DeleteItem();
  }
}

ASP.NET Today: Frames and Grids
01 July 05 10:16 AM | despos | 12 comment(s)

Another relatively common scenario for Web apps. You display a list of items to the user, the user can click to perform any action on the displayed items but also might want to request more information. To exemplify, imagine a shopping application with a grid of products and a Add to Cart button. Next, you need your users to get a preview of the product and more information that for space constraints couldn't show up in the grid row. How would you do that?

• Option #1: You add a link somewhere (say, More on this item) and open a popup window. If you hate popups, you can simply redirect the user to another new page. It works, but you risk to flood the user with too many (and perhaps undesired) browser windows.
• Option #2: You add a hyperlink column and an IFRAME tag into the page. You direct the output of the linked page to the target represented by the IFRAME.

To me, the latter option has a few advantages. First, you use distinct pages for the grid and information. Second, users see what they need without refreshing the whole page or opening a brand new one putting at risk the already limited screen real estate.

Using IFRAMEs (inline frames) is a debatable choice; but all considered if you like the result you actually get it's probably a good compromise between usability and portability. Read more here. I try to use IFRAME whenever possible. Some sparse considerations:

• IFRAME is no longer an IE-only feature and is part of the HTML 4.0 standard
• FireFox supports IFRAME just fine. I didn't try with Netscape 7.x, but someone told me it supports it too.
• If you incorporate IFRAME in your Web page, pay attention to close it explicitly with </iframe>. For some reasons, it cuts the remainder of the page if you don't close the tag or use the shortcut.
• Sure, IFRAMEs have a number of additional problems (i.e., printing, unreachable URL, dimensions) you need to deal with. Latest browsers seem to be able to stem the growth of security risks.

I also like the _search target, that is the IE and FireFox ability to open a page in the search panel, a window docked on the left edge of the browser's window. Functionally speaking, it's a good way to avoid IFRAMEs while serving users with new pages in the same screen.

NB: If you google for "_search target" you easily run into articles that report security bugs connected to the feature, especially for Mozilla FireFox. One that I've found dates back to mid April 2005. As I understand it, those security bugs relate to the browser rather than to using _search panes from within an ASP.NET page. Security risks are related to the fact that some malicious script can exploit the _search pane to follow links. Displaying a page that puts a read-only, nonclickable piece of HTML in the pane doesn't seem to be a security hazard to me. However, having users to apply the latest patch of their browser of choice is anyway a good thing.