Proposal:
I know the portlet spec specifies only one event per request (in regards to individual portlets), but if you look at a portal in whole as a windowing/component environment with user driven events an AWT style event model comes to mind as the logical choice for portal wide event handling. I would really like to see the AWT style model of event handling to come into play with the different phases of portal lifecycle and page rendering (session/request/page/layout/screen) treated as 'components' that can 'register' and 'listen' for 'events' generated by the 'user input(request)' or each other.
For example, I could write an event handler that registers for an event trigger when any user session begins. When it gets the trigger it performs a ldap query for the user and populates the data into a context available to all the view processors. I know that you are following the pipeline model, but this could sit lightly on top of that for session/request/etc and provide the users with a single, coherent, easily visualized and familiar view of user interaction mapping to event handling.
You can find a diagram for a similar but critically different (no turbine) proposal for J1 in bugzilla that might help visualize this at:
http://issues.apache.org/bugzilla/showattachment.cgi?attach_id=7339
Thoughts?
%regards -tk
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
