This project is read-only.
Some LWAS webparts have dynamic content and some not. The content is dynamic from programming point of view as developers can build upon the webpart (e.g. forms, flows, views etc.). The dynamic part of a webpart is stored in configurations using the webpart framework personalization service.

Those webparts that are configurable have a loose coupling way to be configured. In a typical scenario a webpart will be assigned a configuration provider and a parser by the system Driver. The parser will be called by the system Manager at initialization time (see the lifecycle article). At that point the configuration provider would have finished deserializing the configuration. The parser is well aware of the the webpart properties and behavior and will do the actual job of applying the configuration to the webpart.

This concept presents significant benefits such as:
  1. The webpart can be manipulated after has been initialized and the changes can be preserved. E.g. a textbox can be added to a webpart, permanently.
  2. The configuration model is consistent across different webparts types which allows traversing it with simple access (point separated paths)
  3. The configuration provider does not have to be specialized for the webpart it serve, thus any new webpart type can be plugged in and have out of the box storage of its configuration
  4. The parsers can be polymorphic i.e. new versions of configuration can exists side by side with old ones without touching the webpart code
  5. The configuration is actually the content serialized while the webparts and the rest of the system execute it. So to build or change upon LWAS system all you have to do is to edit the configurations. And having the configuration serialized into xml files makes it possible with only a text editor
  6. The configuration provider can be changed to act differently, e.g. compress the serialization or make it less/more verbose

Last edited Oct 15, 2013 at 7:47 PM by t1b1c, version 2