C# – Why can’t Themes and Master pages be applied dynamically after Page.PreInit event

Thought I would review some of my outstanding questions and see if I can close some of them off.

This one was an interesting one. I outright refused to believe you can only have one form on an ASP.NET page. This to me made no sense. I have seen plenty of webpages that have more than one form on a web page, why should an ASP.NET page be any different?

So, it got me thinking.

Why does a ASP.NET page need a form element?

ASP.NET pages try to emulate the WinForms environment, by provided state persistance through the PostBack model. This provides an element of state to a stateless environment. In order to do this, the runtime needs to be able to have the ability to maintain this state within each "form". It does this by posting back data to itself. It's important to note that:

• There is nothing really fancy about a PostBack.
• It uses a HTTP form and POST, the same as any other form, from any other stack.
• Just because it looks like it might be doing something special, its not, all that happens is it POST's back with some info about what caused it, so you can do things like handle client-side events, in server-side code.

So why only one?

This to me was the million pound question (I am British). I understand that ASP.NET needs this, especially if you are using ASP.NET server controls, but why the hell can't I make my own additional forms?

So, I thought screw it, just make your own form!

And I did. I added a bog-standard, simple form with a submit action of "#". This then performs a POST to the current page, with the Form data for the given form in the request.

Guess what? It all worked fine. So I ended up with:

• A master page, with a HTML form in
• This form posts back to the current page (basically the page using the master).
• In the Page_Load code-behind for the master, I then added code to check the request to see what data was passed in the request. If it contains data (say a hidden field) then I know the post was sourced from the Form on the master page, if not, then it is most liekly a PostBack from content, and can be ignored.
• I then surrounded the Content tags with <form runat="server" id="aspNetForm"...> </form> tags. This meant that all content pages automatically had a form to work with.

This provided me with a relatively simple, clean solution to my problem. My login form works fine in tandem with all the content forms created, some of which are complex forms, others use lots of server controls and many PostBacks, and so on.

I hope this helps others.

Your first assumption is correct.

To your second question, it depends on whether it is a post back or not and/or if you are binding explicitly. If it is not the post back and binding happens automatically then, roughly speaking, the value of the ControlParameter is retrieved when DataSourceView calls Select on DataBind, right before OnSelecting event. The sequence for the gridview (and any given control for that matter) is as follows:

Page.ProcessRequest
Page.PreRenderRecursiveInternal
...
GridView.EnsureChildControls
GridView.CreateChildControls
GridView.DataBind
GridView.PerformSelect
DataSourceView.Select //comes from either SQLDataSource or LinqDataSource
DataSourceView.ExecuteSelect
//for Linq:
    LinqDataSourceView.GetParameterValues(WhereParameters)
//for SQL:
    SqlDataSourceView.InitializeParameters(SelectParameters)
Parameters.GetValues
Parameters.UpdateValues //this is where values get retrieved using reflection
DataSourceView.OnSelecting //follows almost immediately
...get data...
DataSourceView.OnSelected

So, for each control in a control hierarchy, the framework recursively calls DataBind, which then triggers retrieval of parameters, OnSelecting, data retrieval, and OnSelected.

If it is a postback, however, then those parameters will get loaded from a viewstate on the page's OnLoadComplete, again, in the order they are declared.

Is this what you were looking for?

Edit

Q1 - Let’s assume ControlParameter is bound to property C1 of a control C. I would imagine that on postbacks ControlProperty would always be able to get C.C1’s value from ViewState, no matter of what type C is, and even if C has ViewState disabled?!

That's not entirely how it happens... On post back (and on initial request for that matter), ControlParemeter's view state is evaluated only to see if it changed so that the OnParameterChanged event could get fired. The actual value of the ControlParameter is evaluated against the control it points to (via reflection). In your case it'd be "C.C1". Now, when it reads C.C1, its value is most likely read from a view state. But at no point does the ControlParameter read C's view state directly.

Q2 - But may I ask why, if a page is created for the first time, can’t a value for ControlParameter also be retrieved from viewstate? Afterall, the moment lstCities retrieves data from data source, lstCities.SelectedValue has its value set?

That's the thing, at that point (the first time page loads) the lstCities did not retrieve any data yet. The first time a property evaluation happens is on Page.OnLoadComplete, but before any DataBind (which happens shortly after, when Page.PreRenderRecursiveInternal gets fired).

In the crude form, trying to place it in a life cycle of a page:

...request...
PerformPreInit
InitRecursive //SqlDataSource subscribes to Page.LoadComplete
OnInitComplete
if PostBack
    LoadAllState //the view state gets loaded
    ProcessPostData
OnPreLoad
LoadRecursive
if PostBack
    ProcessPostData
    RaiseChangedEvents
    RaisePostBackEvents //you handle your events
//notice that following sections assume that you did not do any data 
//binding inside your events
OnLoadComplete //This is where parameters (SelectParemeters/WhereParemeters)
    //get updated. At this point none of them are data bound yet.
    //And if it the first time, there are no values
    //as the ViewState is empty for them.
PreRenderRecursiveInternal //calls the DataBind (if you haven't already), 
    //then DataSourceView.Select; parameters evaluate their controls.
    //The control C would be bound at this point.
PerformPreRenderComplete
SaveAllState
OnSaveStateComplete
RenderControl

Second Edit

So ControlParameter evaluates C.C1 and thus retrieves C.C1’s value after C has been bound?!

The ControlParameter retrieves values whenever it is asked, which in this scenario happens (indirectly) in two places: OnLoadComplete and DataBind (triggered by PreRenderRecursiveInternal). On OnLoadComplete, the C is not bound. On PreRenderRecursiveInternal, after DataBind, the C is bound. Both times ControlParameter is asked to read C.C1. Maybe following will help...

Here are classes and methods of interest in a nutshell. Place them in perspective of the page cycle and hopefully it will be clear.

public class ControlParameter : Parameter
{
    public string ControlID { get; set; } //stored in ViewState
    public string PropertyName { get; set; } //stored in ViewState

    protected override object Evaluate(HttpContext context, Control owner)
    {
        Control sourceControl = DataBoundControlHelper.FindControl(owner, this.ControlID);
        //evaluate C.C1 using reflection
        return DataBinder.Eval(sourceControl, this.PropertyName);
    }

    internal void UpdateValue(HttpContext context, Control owner)
    {
        //PostBack or not, read stored value (on initial load it is empty)
        object storedValue = this.ViewState["ParameterValue"];
        //Get the actual value for this parameter from C.C1
        object actualValue = this.Evaluate(context, owner);
        //Store received value
        this.ViewState["ParameterValue"] = actualValue;
        //Fire a change event if necessary
        if ((actualValue == null && storedValue != null)
         || (actualValue != null && actualValue != storedValue))
            this.OnParameterChanged();
    }
}

public class SqlDataSource : DataSourceControl
{
    //fired by OnLoadComplete
    private void LoadCompleteEventHandler(object sender, EventArgs e)
    {
        //UpdateValues simply calls the UpdateValue for each parameter
        this.SelectParameters.UpdateValues(this.Context, this);
        this.FilterParameters.UpdateValues(this.Context, this);
    }
}

public class SqlDataSourceView : DataSourceView, IStateManager
{
    private SqlDataSource _owner;

    //this method gets called by DataBind (including on PreRenderRecursiveInternal)
    protected internal override IEnumerable ExecuteSelect(DataSourceSelectArguments arguments)
    {
        DbConnection connection = this._owner.CreateConnection(this._owner.ConnectionString);
        DbCommand command = this._owner.CreateCommand(this.SelectCommand, connection);
        //This is where ControlParameter will read C.C1 values again.
        //Except this time, C.C1 will be already populated by its own DataBind
        this.InitializeParameters(command, this.SelectParameters, null);

        command.CommandType = GetCommandType(this.SelectCommandType);
        SqlDataSourceSelectingEventArgs e = new SqlDataSourceSelectingEventArgs(command, arguments);

        this.OnSelecting(e);

        if (e.Cancel)
            return null;

        //...get data from DB

        this.OnSelected(new SqlDataSourceStatusEventArgs(command, affectedRows, null));

        //return data (IEnumerable or DataView)
    }

    private void InitializeParameters(DbCommand command, ParameterCollection parameters, IDictionary exclusionList)
    {
        //build exlusions list
        //...
        //Retrieve parameter values (i.e. from C.C1 for the ControlParameter)
        IOrderedDictionary values = parameters.GetValues(this._context, this._owner);

        //build command's Parameters collection using commandParameters and retrieved values
        //...
    }
}

A) So ControlParameter checks whether its ViewState changed...

Refer to the UpdateValue method above to see how it uses ViewState.

B) I assume ControlParameter checks whether its Viewstate changed only so that it can fire OnParameterChanged event. But why is handling that event so important?

I don't know that it is important. I suppose, like any other event, it allows you to track changes in parameter's properties and act accordingly to your needs. It gets fired in many places, but I don't see where anyone subscribes to it. So...

By property evaluation you mean ControlParameter checking its own ViewState? Thus you don’t mean ControlParameter evaluating C.C1 ( which I assume happens after C has been bound )

It means that the ControlParameter.UpdateValue gets called, which checks ViewState for stated reasons, then calls ControlParameter.Evalue, which then finds a control and retrieves data using reflection (Eval). See above.

Third Edit

I presume that by Update you mean UpdateValue.

So if Update() is called when data binding takes place, then what that means is that when on next postback UpDate() is called in OnLoadComplete, C.C1 and ControlParameter will already have same values...

Not necessary. You are forgetting that the view state is loaded on LoadAllState and between it and the OnLoadComplete there are six more steps (see page life-cycle above). Each of those may modify the source control's (C.C1) value.

Say you have C.C1 = "x" and did a post back. Now, the view state for all controls is loaded (LoadAllState). If C.C1 stored it's value in the view state, it will load "x". On Page_Load (LoadRecursive) you decide to set C.C1 = "y". Here C.C1 may decide to store "y" in its view state or not -- it's irrelevant. Then other events follow. Next comes OnLoadComplete. Since SqlDataSource subscribes to this event, it will evaluate all associated parameters (LoadCompleteEventHandler) and, since you did change C.C1 but ControlParameter's view state did not, the

if ((actualValue == null && storedValue != null)
 || (actualValue != null && actualValue != storedValue))
    this.OnParameterChanged();

will return true and OnParameterChanged will be fired. By the way, there is at least ten other places where this event gets triggered. It doesn't play big role (if any) in data binding and property retrieval process.