I noticed there has been some questions and discussions regarding portlet support in SAF 2, so I figured I should give you all a brief introduction to how the portlet support from WW 2.2.2 works:
The core is of course the Jsr168Dispatcher, a portlet that acts as the dispatcher (hence the name....). This portlet implements the processAction and render methods. By default, any form submit will be mapped to an "action event", and any other "clicks" in the portlet will be a "render". This can be customized with attributes in the JSP tags. If a portlet is the target of an action event, it will execute two actions in a "round trip". Between the processAction and the render invocations, some state will be stored in the portlet session to maintain validation- and other messages that were generated during the event phase. During the render phase, this action will be pushed onto the stack (but not executed) with it's properties and messages, and will be available during the render phase. The action on the session will be cleared when a new event or render is targeting the current portlet. If a render or event orignates from a different portlet, the state for any other portlet will not change, and any messages and properties will still be available (and visible), kind of like a "flash" scope. This has some implications if you're relying on session persistence and replication, namely that your actions would have to be serializable. Typically, in the configuration file, you would make sure that actions that will be executed in the event phase will have a result that dispathes to an action that will be executed in the render phase. This is supported through the default PortletResult. Note that you can still configure an action that is a target of an event with a "view" result (JSP or a template), but it will still be two action executions, as the framework will prepare a special render action with the sole purpose of dispatching to the view. The PortletActionContext can be used to obtain direct references to the Portlet API objects, and the Request, Session and Application maps are identical to their servlet twins. You may notice a missing "Application Scope" session map (a scope where session attributes can be shared with other portlets or servlets in the same application). There is currently no map of this scope. You would have to obtain the PortletSession object through the PortletActionContext to retrieve attributes from this scope. Another feature is that portlet modes can be mapped to namespaces in the action configuration. Typically, you would group actions for each mode in a package with it's own namespace, e.g. "edit" mode actions will be mapped to a "/edit" namespace, and so on. In addition, you can have multiple portlets sharing the same config by having a different "root" namespace for each portlet. When you switch between the different portlet modes, the dispatcher will automatically switch the namespace context. For instance, if you have a portlet "Portlet A", which is mapped to the namespace "/portletA", and you decide to map the "view" portlet mode to the "/view" namespace, the dispatcher will look for actions in the "/portletA/view/" namespace when executing in the view mode. It should be easy to extend this to also take into consideration window states, if needed. One flaw that still has not been addressed, is the namespacing of javascript. In theory, all javascript that is generated needs to be prefixed with a portlet container generated namespace to ensure uniqueness through out the generated portal page. This will be important to ensure a fully functional ajax support. Any comments or questions? Regards, Nils-Helge Garli --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
