This project is read-only.

About lifecycle

LWAS screens are created by users and consequently some screen components are ASP.NET dynamic controls. Because ASP.NET maps the controls tree at postback with the posted data, the Page has to be rebuilt each time is requested to provide a flowing experience to the user. That's why there's a lifecycle for screen components built into LWAS.

The lifecycle is managed by the system Manager which is a must-have component in LWAS powered ASP.NET Page (see the plugins model article). The LWAS Manager, a derived class from WebPartManager tracks all the screen components, which are actual WebParts and thus can pass all the components through the same steps during a Page request. In ASP.NET the same function is performed by the Page but we need additional functionality (i.e. setup dynamically created WebParts) and we need it only on LWAS components in a Page. This way we can have ASP.NET, LWAS and any other framework side by side without much interference.

Components lifetime

During a Page request the LWAS components pass thru 4 phases that compose the lifetime:
  1. initialization phase is when the components are initialized by the driver, been assigned the necessary providers. Usually the component prepares itself during this phase, e.g. has the parser applying the configuration. This phase is a system phase available to LWAS extensions only
  2. creation phase is the first phase available to LWAS developers to interact with the system. Typically in this phase the component will load it's content, e.g. the forms will load their controls, the workflow manager will load the flows etc.
  3. in the change phase is the recommended time to execute flows upon user actions or automated. This is the best point in the lifecycle to do it as all the components will be ready to interact. The user actions performed in the browser will be performed server-side during this phase and this is when the system knows about them
  4. the completion phase is the shutdown period during which the components should perform housekeeping tasks like writing their private files, closing database connections etc. During this phase the webparts personalization is serialized and no further changes will be recorded
Sometimes it's important to have the screen components pass the lifecycle into e specific order. By default the ASP.NET does it in the order of their creation and that might not be the most useful way. E.g. you could have 3 cascading forms in a screen that need to save data one after the other in a pre-determined sequence. For this kind of situation most LWAS components (like forms) can have an lifetime execution order assigned by the developer.


Milestones are signals sent by LWAS components. From programming perspective these are events with empty arguments, following the simple flow convention and are raised at moments in the lifetime or when the sending component executes a specific action or when the user performs an action. Thus we have system built-in milestones and user-defined milestones.

LWAS components will announce when they pass every lifecycle phases and each of them will send "create" , "change" and "complete" milestones. The order in which the components in a screen send these milestones is their lifetime order and can be set by the developer.

Each component has specific milestones. Most of the time any component that has a Command property will also send a milestone with the command it receives.

The built-in milestones are workflow hooks into the components lifetime and actions. Developers can build powerful flows upon this hooks and can chain together these flows by sending custom milestones which can trigger flows the same way as the built-in milestones do.

Last edited Oct 15, 2013 at 11:38 PM by t1b1c, version 5