Version 3

    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