Displaying datasources modified by postback events without server.transfer or response.redirect

[RAJ]

In our multi-tier application, we have several ASP.NET user controls which
will update the same data source provided by middle tier logic.

In this particular scenario we have one user control displaying the contents
of the data source, whilst another control updates the datasource via a
command buttons implementation of 'Click', an event raised in the 'Handle
Postback Events' stage of the control execution life cycle (via the
RaisePostBackEvent method).

These user controls are structured at present, in the Page_Load event,
including the control which is concerned only with displaying the datasource
contents. The problem therefore is that if the control has already been
structured for rendering, and the datasource is updated afterwards, then the
changes to the datasource are not present in the displaying control, but are
present in the updating control.

Now seeing as though the command button constituent controls (which
implement the IPostBackDataHandler marker interface) are instantiated
straight from Page_Init (regardless to their presence in the designer or
created manually for composition), then even if the rest of the control
isn't structured in Page_Load, during the 'Handle Postback Events' stage of
the control execution life cycle, this control would still perform its
'Click' event?

Please also consider the following factors:

.. Either control is capable of updating the data source (so one may be the
updater, the other the displayer, and vice versa)

.. The 'Load' phase of the controls execution life cycle states: 'At this
point, server controls in the tree are created and initialized, the state is
restored, and form controls reflect client-side data.'.

.. The controls execution life cycle also states: 'The CreateChildControls
method is not listed in the table because it is called whenever the ASP.NET
page framework needs to create the controls tree and this method call is not
limited to a specific phase in a control's lifecycle. For example,
CreateChildControls can be invoked when loading a page, during data binding
or during rendering.'.

Is it therefore possible to 'EnsureChildControls' from the 'Click' event of
the updating controls command button, create the input controls which had
taken part in the post-back process, obtain the postback data from these
input controls (Note that at this point, the 'Load' phase has already run!
Have these controls missed out their viewstate and postback processing
stage?!?) and update the datasource?

Likewise if this control is not updating the datasource, is it safe to
assume that it would be possible to render the displaying control in
CreateChildControls, which is ensured (EnsureChildControls) from the
PreRender event?

This would remove the requirement for either a Server.Transfer or
Response.Redirect from the command buttons 'Click' event, of which the
former is difficult to cater for (because it retains the original
HTTPRequest, disabling different user controls ability to structure URLs
correctly), and the latter which causes an additional round trip to client
and server.

Any insight into this perplexing problem would be greatly appreciated!

Thanks

RAJ

 

[bruce barker]

this is way there are prerender and render events. your bound controls
should use the value of the datasource at render time, not load. this allows
init, load and postback events to change the value and still have it render
correctly.

-- bruce (sqlwork.com)

 

[RAJ]

Thanks for your reply.
Apologies for length!

Its my understanding that the control hierarchy has to be reconstructed in
Load so that the controls which formed part of the previous response are
populated with the postback data.

From what I've read in MSDN, the controls have their viewstate restored
based on their position in the control hierarchy, and viewstate is just a
dictionary indexed by the individual control's Unique ID. The same, as far
as I know; applies to postback data.

As a consequence, the control modifying the datasource has to be rebuilt
once for restoring viewstate and capturing postback data, and a second time
for displaying the updated data source changed as a result of postback data
modifications.

MSDN also states in the Control Execution Lifecycle that
'CreateChildControls' is not called at any specific stage. It can be
guaranteed however, to run when an internal call to FindControl is invoked,
the related instance of which probes the 'Controls' collection property, all
of which is part of the viewstate restoration process!

Interestingly, the 'ChildControlsCreated' property is not readonly, so this
can be set to false at any point to allow 'EnsureChildControls' to re-render
the composite controls. As a consequence of running 'CreateChildControls'
twice, the Controls collection has to be cleared.

Unfortunately, after clearing the controls collection, controls which have a
half-half implementation in design and composition in code behind will not
restore controls loaded from the designer, even if the base
'CreateChildControls' method is called.

This is because the designer control structure is built from the
automatically generated FrameworkInitialize function which invokes the
__BuildControlTree method, declared in the 'controlname_ascx' class, which
inherits from the class definition declared in the related code behind file!

Thankfully due to the inheritance hierarchy, FrameworkInitialize is
overridden by the 'controlname_ascx' subclass which in turn re-parses the
ascx layout, allowing it to be invoked from CreateChildControls. But this
doesn't appear to be a supported method, and isn't documented in MSDN.

Is it wise to perform FrameworkInitialize from the CreateChildControls
function?

This is what I plan to implement:

1) Load View State stage automatically invokes CreateChildControls
(FrameworkInitialize is called twice at this point already), building the
control structure which is a replica of the previous response
2) Controls are populated with postback data
3) Load is invoked where pretty much nothing happens
4) The control which handles the post back fires the appropriate event
5) The datasource is updated as a result of postback data
6) ChildControlsCreated is set to false
7) PreRender calls EnsureChildControls
8) CreateChildControls is run a second time re-structuring the entire
control
9) Tear-down and dispose

RAJ