You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Todd Kuebler <tk...@cisco.com> on 2003/10/24 00:27:55 UTC

Jetspeed2 Portal (not portlet) event model

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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Jetspeed2 - User .vs. Integrator .vs. Core API/jars

Posted by Todd Kuebler <tk...@cisco.com>.
IMHO one of the greatest barriers to entry to Jetspeed 1.x was the mixing 
of the core API with the end user API.

Is Jetspeed 2 going to address that by separating out the user api 
(events/action, etc), the integrator api (security interfaces, etc) and the 
core api (all the guts you can't/shouldn't change) into separate 
jars/javadocs, or will there be pages and pages of javadoc to plow through 
including pipelines and valves and other non-user configurable stuff just 
to get a portlet to display Hello World?


-tk


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org