Loading ...

MasterPage and viewstate issue

 /5
0 (0votes)

There is an excellent article on MasterPages by Scott Allen in which the potential gotchas while working with MasterPages are explained very well. This article complements the article by Scott and focusses on the issue regarding enabling/disabling the ViewState while dealing with Master and Content pages in ASP.NET 2.0.

MasterPage is treated like a control in the ContentPages

Recently I was answering a question in the ASP.NET forums regarding ViewState handling in ContentPages while working with MasterPages. The question, in simplified form was:

In the web.config file, I have the setting:
                      <
pagesenableSessionState="false"enableViewState="false"theme="Default" />

And in a particular page I want to override the setting:
                         
<%@ Page Language="C#" ... EnableViewState="true" %>

I can see in the properties that the page's EnableViewState property is indeed set to true, but the web.config file appears to trump it!

I thought that the setting was overridable if explicitly declared in a page. Am I wrong? ..

Initially I also got confused as this was not happening at my end. But later when I asked for details, I  got to know that MasterPages were invloved, and this immediately made things crystal clear.

The problem was that the ContentPage controls were losing ViewState even when the Page had EnableViewState turned on explicitly. The reason for this is the fact that the Master pages are treated as a control inside the Content pages  and if we do not turn on the ViewState for the Master page, it will take the value from the Web.Config file by default (which is false for the above example). See the

concontrol hierarchy below:

Control hierarchy with Master Pages in ASP.NET 2.0

 






Unless the MasterPage has its ViewState turned on, all controls below it would lose their state. As another example, if you turn on the ViewState for all pages in the Web.config, and turn off the ViewState of the MasterPage, then all controls in the ContentPage will lose their Viewstate as they would be nested inside the MasterPage control.

But then, my friend argued: "I can understand the behavior you describe if I turned ViewState off for the MasterPage then on for the Page, but in my case enableViewState is off in web.config and on for the Page. You're saying that the MasterPage is a control within the page, which I understand, but in theory the child controls of a Page adopt the settings of their parent for their default. This is indeed true if you turn web.config state off but enable state in a Page without a MasterPage: the Page's child controls adopt the setting of the Page, not web.config."

I think the reason for this is the fact that the web.config setting applies only to the Pages (notice the element). There is no pre-defined way to set individual control's enbaleViewState property through the config file. They will take the same value as set for their parent page. But MasterPage CAN take the web.config value. Also, try placing a DropDownList control inside a Panel in a Page which has view state turned on. Add some elements to the DropDownList dynamically (may be one time on PageLoad where IsPostBack=false). Now turn off the view state for this Panel and run the Page. You will notice that on the first load, the drop down gets filled with values you added dynamically, but as soon as a PostBack happens, it loses its values even when the view state is turned on for the Page. This happens because the individual control settings override the ones of their Parent. But ofcourse if the view state is disabled for the entire Page, then all controls will have the same disabled (even though if we have some controls with view state turned on explicitly).

The main points to consider are:

1.We can turn on/off the view state only if the Parent control has the same turned on. If view state is disabled in the parent control, then there would be no effect even if we turn on property for individual controls.

2. The MasterPage takes its value from the Web.config file and will reflect the same only if the ContentPage has view state turned on. If not, then "there is nothing to turn off".

3. A MasterPage is slightly different from other controls, it is in charge of things until Page_PreInit() is over. Only after the PreInit() event, it behaves like a true child control of the Page.

MasterPages can be a bit tricky unless we undertsand the complete Page lifecycle and the sequence of events. In short, it is helpful to remember that a MasterPage behaves like a control inside the Conent Page and all events, except the Init(), fire first for the outer control and then for the inner ones. For e..g:, Page_Load() of a Conent Page will fire first and then of the MasterPage, similarly OnInit() of the MasterPage will fire before that of the ContentPage.

Comments (no comments yet)

Top Posts