Changes to the existing Theme and Layout feature

Layout Strategy

• replace the current evaluate() method with two new metods for initialization and navigational state update

• introduce the concept of a page navigational state that holds the information about the portlets on a page (region and order)

• after initialization cache the page navigational state until the window navigational state of any of the windows on the page changes (change of portlet mode or window state)

• when a page is loaded for the first time in a session, initialize the page navigational state, and then execute the layout strategy's new init method with the initial page navigational state

• after each change to a window navigational change, fire the layout strategies event() method with the current page navigational state

• both new methods in the strategy should take the current (or initial) page navigational state as argument, and return the modified state

• the page navigational state also holds an attribute for each window to indicate whether the window is visible or not

• the page navigational state is defined in the layout module, and managed in the core module

formalize the contract between the core and the layout

• introduce a Servlet like Layout API with life cycle methods like init and destroy

• individual layout artifacts like the layout, a region, a window, etc. all inherit from a common interface

• the common interface exposes a generic render method that takes a context as argument

• the context contains the markup fragments from the individual portlets with their allowed actions (per family, like 'modes' and 'states')

• this allows for more fine grained rendering of the markup (render only one region, one window,...)

• perhaps create hierarchie in the layout API (page, region, window)

• add resource bundle for layouts

• introduce layout meta data (from the descriptor) and provide it at initialization time as an info object (analogous to getInfo() in servlet)

• think about dynamic layouts (perhaps metadata is not that static ?) ????

• window properties like 'no decoration' as part of the meta data

• architect this new API in such a way that there is no tie to JSPs or Servlets and the request dispatcher (those should only be implementation details of the default layout)

• in the core, add a portal aggregation command to create the final markup (using the new layout API)

Not commited for 2.4: User Dashboard

• TBD