Page LifeCycle in ASP.NET

acceptableseashoreΑσφάλεια

5 Νοε 2013 (πριν από 3 χρόνια και 11 μήνες)

100 εμφανίσεις

Page LifeCycle in ASP.NET

A Web Form in ASP.NET

<form id="form1" runat="server">


<asp:Label ID="Label1"
runat="server" text="A Label!"/>


<asp:Label ID="TextBox1"
runat="server" text="A TextBox!"/>


<asp:Button ID="Button1"
runat="server"

onClick="Label1.text='Hello'"/>


</form>


After Server
-
side Processing

EG,

TextBox1 produces:

<input type="Text" id="TextBox1"
name="TextBox1" value="A
TextBox!"/>


Typically a page posts back to itself. Clicking
the button causes a form submit event.


A Note about View State


If you click Button1, Label1 will be
changed to show ("Hello"). When the page
reloads Label1 will still say "Hello", even
though it's default value is "A Label!".


ASP.NET inserts a hidden field into the
form (_VIEWSTATE) which holds the
current state of all controls where they
differ from the default values (defined in
the ASPX file).


ASP.NET Lifecycle Phases

1.
Init

2.
Load

3.
Events

4.
Render

5.
Unload

Lifecycle
-

1: Init


Build up a tree of controls from the ASPX file.
(All controls have their ID set at this stage)


Process the View State, giving each control a
chance to update its state. For example
Label1.Text = "Hello". (View State data is keyed
by Control ID).


Anything in the View State that didn't match a
known control ID is placed in an "Unmatched"
list.


Turn on view state tracking. Any changes to
controls will now be recorded in the View State.


Lifecycle
-

1: Init


When the form was submitted some controls (for
example TextBox1) will submit their values as a
{ID, value} pairs. We call this the Post Data.


As before, we match Post Data against control
by ID, giving each control a chance to process
the data. Some controls may decide to trigger an
action based on this, so they get added to a
"Pending Actions" list.


Finally any unmatched Post Data also gets
added to an "Unmatched"

list.

Lifecycle
-

2: Load


This is a chance for controls to access the
database, etc.
[Not all such controls need
to be visible.]
Some dynamically created
controls may be added to the tree at this
stage.

Lifecycle
-

3: Events


We make a second pass of any data saved in
our "Unmatched" list. This is for the benefit of
dynamically created controls.


We process the "Pending Actions" list and raise
appropriate events (things like TextBox1 "On
Changed").


We find the control that caused the post back
event and see if it has any events it needs to
raise
-

(typically things like Button1 "On Click").


Lifecycle
-

4: Render


View state tracking is turned off & View
State serialised into the hidden
_VIEWSTATE field.


Controls generate HTML based on their
current state.

Lifecycle
-

5: Unload


A chance for controls to clean up any
resources they're using like Database
Connections, etc.

Now about KLUCIS request
lifecycle

Definition
: A Spring Controller is a
component/module, which is responsible
for the lifecycle of a single HTTP request.
I.e. it is appropriate to code the
sequence of all major phases in request
processing in a Spring Controller. (And
nothing else!)



KLUCIS Phases

1.
Resource Lookup

2.
Init

3.
Do Action

4.
Execute Event; add Dynamic
Components

5.
Init&Action for dynamic components

6.
Prerender Event

7.
Unload and Render

Lifecycle 1: Resource Lookup


Lookup the servletPath in RDF data. I.e.
extract from the HTTP request the desired
imageName and find in N3 description such
resource r that [r klucis:hasImageName
"imageName"
].


May need special processing, if imageName
does not exist, or is ambiguous, or some error
happens during the processing
-

ideally would
have special "PageNotFound" and
"InternalServerError" resources (i.e. a "404
image" and an "500 image").

Lifecycle
-

2: Init


Create a component for r and all the static
resources referenced by it (all creation is done
by the rdf:type of these resources
-

lookup in
Component Factory)


Load the request state to ComponentManager
and initialize the components accordingly (e.g.
some image subcomponent has been rotated;
some form field has some bookmarked value,
etc.)


Lifecycle
-

3: Do Action


Do the action: In addition to the regular
parameters:

...?compId1=state1&compId2=state2&...

there can be a single pair of special action
parameters:

..._ac=someId&_aa=someAction


If component with the id=someId understands
the action, it is executed (should care about the
idempotence...).


If action not supported, log warning and ignore


(Actions become complicated for rich clients
synchronizing with the server)

Lifecycle 4: Execute event


Interact with the database or with RDF
resource set, or do other things which
components want to do


Events are executed on all components,
which are EventListeners; these can be
done in any order. (ComponentManager
stores a table of all registered listeners
and broadcasts the "execute" event...)

Lifecycle 4: Add Dynamic
components


Upon certain conditions during the "execute"
event (e.g. if the states of the static components
become appropriate, or if the DB/RDF query has
certain response
-

etc.), create and add to the
root CompositeView (or some of its children)
some dynamic components


Dynamic components should also have IDs,
which are generated in a predictable fashion.

Lifecycle 5: Dynamic init&action


If the newly created components have
their state among the HTTP request
parameters, initialize them accordingly.


If there is any remaining action on
dynamic components, execute these
actions.

Lifecycle 6: Prerender Event


All the SVG components calculate and
communicate their width, height, offsets,
etc. to prepare for the drawing.


Facetted browse components compute the
available future states from the existing
states of their neighbors and populate
themselves with labels


...

Lifecycle 7: Unload and Render


Release database connections and similar
resources


Return ModelAndView from the
SpringController


Some small computations and extra
processing of data can be done during the
last moment: in the Velocity templates
during the Render phase, but this is
generally not a good practice