A LWAS screen must be attached to at an ASP.NET webform to function. For that matter an entire LWAS application can run with a single webform ... or maybe more than one application (this scenario might be practical when individual applications are modules to a bigger system).

ASP.NET Page model

Let's see how the well known Page model of ASP.NET has some important characteristics that impact the LWAS design.

Page lifecycle
The ASP.NET Page lifecycle from the perspective of a dynamic system such as LWAS is a so-so architectural choice presenting both benefits and drawbacks. Because of this lifecycle we have a properly established point in time to dynamically alter the webform but consequently the model greatly impacts the data recovery, been necessary to create any dynamic control twice. First to retrieve the data posted back and second to re-render properly based on data posted.

What's important about postback regarding LWAS is that it can be configured to post data from read-only controls which makes possible the data retrieval solely from the post. This way a LWAS webpart is self contained and can truly act like an asynchronous part of the page. You know, avoids complications like "which query I executed to populate this dynamic control and what were its parameters values the last time".

Controls and viewstate
LWAS can use any control from the ASP.NET class library but it has a hard time with those relying on viewstate or control state. Due to the prone problems presented by the state bags with dynamic controls LWAS avoids the use of that feature. It's recommended to have viewstate disabled in a LWAS powered webform. Because some of those controls are really useful LWAS provides an overriden safe version of them in the namespace LWAS.CustomControls .

LWAS extends webparts framework

The ASP.NET webparts class library is a powerful framework with tons of features that LWAS benefits from. LWAS extends this framework to do something that is well capable of doing but was just not meant to do.

The main difference LWAS mades to the framework is that webparts are created by same people that use them and not by programmers. Technically speaking the webparts exist in a basic state and have the content added and configured at run-time by users. That's the real behavior of a CMS. And since data controls (textbox, dropdownlist, datepicker etc.) are content for LWAS webparts you get a DB CMS (database content management system) and that's what LWAS is all about.

LWAS screens are actually webparts personalization serialized and saved into xml files. In the context of a single webform, having content added to webparts at runtime makes the screens different one another. And not just the content is dynamic, the webparts are dynamic as well. Add a handy feature to save this different personalization with a unique name and you're ready to spam LWAS screens!

Features inherited from webforms

Master pages
User controls
Security model

Last edited Oct 8, 2013 at 7:43 PM by t1b1c, version 4