portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Kuebler <tkueb...@cisco.com>
Subject Re: Ideas for 1.4 Event Model addition
Date Wed, 09 Apr 2003 21:06:35 GMT

Find attached a UML diagram of my 'first pass' at adding event handling to 

The colors are for visual clarity and only roughly based on the design 
archetypes they represent in the Coad/Lefebvre/DeLuca UML color extensions 
and domain-neutral component pattern.  Don't get hung up on that semantic 
hook, the diagram is simple and should be self explanatory.

The differences I identified between awt event model and the problem we are 
trying to solve is that in awt it is an interactive, fully encapsulated 
environment.  The request/response driven http transaction needs some layer 
of abstraction which I called scope to identify the different parts of the 
server/client interaction that might need events triggered.  This scope 
idea roughly replaces the component idea of awt.  I think I picked the 
right scope points, but there probably needs to be some discussion around 
that as well.  There is a potential conflict between portlet set scope and 
portlet group scope which need to also be further explored.

%regards -tk

At 06:01 PM 4/4/2003 -0800, Todd Kuebler wrote:
>At 10:47 AM 4/3/2003 -0600, Mark Orciuch wrote:
>> > 2.  Inter-portlet communication.  This came up on user, and I
>> > think there needs to be a well-defined mechanism for this as
>> > opposed the usual kludgy, hacks we generally suggest ;).  It
>> > needs to be transparent and easy to use.  Todd Kuebler had some
>> > good suggestions, so I'd like to look deeper into that and try to
>> > come up with something.
>> >
>>Sounds good. As long as it's transparent and ready to go by April 14th, I'm
>Here is a strawman, and I undoubtedly have missed the mark widely or 
>altogether in some respects.  I actually think this might be a 1.4b5 thing 
>instead of April 14, but can try to implement and test it in the next week 
>or so and submit the patches if I have time.
>    * Backward compatible, sits beside current turbine based actions.
>    * Event handling system similar to awt.
>    * ActionEvent class that holds the event that is being fired (scope, 
> source, etc contained within)
>    * ActionListener interface with actionPerformed method to be 
> implemented by action classes who want to fit into this model.
>    * ActionSource interface that provides the addActionSource method to 
> register with ActionService (proxy that manages action registration, 
> processes events on triggers, etc.  see below).
>    * Event triggers inserted at key points along the request/response 
> path to evoke the actions for different scopes.
>    * ActionService (turbine service) with a addActionListener 
> method.  ActionSources for each of the scope trigger points will register 
> with the ActionService which also initializes and holds the 
> actions/actionlistener map and distributes the events to the proper 
> actions when the scope event trigger happens.  Also will manage the 
> contexts being passed down though the action scope chain.
>    * Scopes: Session, Request, Portal, Portlet Set, Portlet Group (for 
> interportlet communication between arbitrary groups of portlets), 
> Portlet, Portlet Instance.
>The general idea here is that you could create actions to act on the 
>context for each scope in question + the current action handling at the 
>portlet level.  The parent context for each request would come from the 
>session scoped context and be passed down to the request scope actions, 
>resulting in a modified context which would be passed down to the portal 
>scoped actions, etc.
>There would be a ActionService that would act as a proxy to receive 
>events, load up the action map at init, and hold the context(s) as it 
>cascades down through the action process.  Actions outside of the portlet 
>would be placed in a config file (xreg probably) that would describe the 
>scope and the action class like in the current portlet entries.
>Imagine many of the context creation things like loading in the pull 
>tools, etc moving out of the portlet and into a different scope.  The 
>portlet itself could either be an ActionListener, or could register the 
>default action class with the ActionService on init and not actually 
>process the events anymore itself.
>Proposal touch points organized by scope (incomplete):
>Session Scope, Request Scope, Portal Scope, Portlet Group Scope:
>         ?
>Portlet Set Scope:
>    * modify AbstractPortletSet or create a new BasePortletController to 
> be an ActionHandler and register it during init
>    * Write a default action handler to handle the
>Portlet Scope:
>    * modify GenericMVCPortlet to fire a action event during it's current 
> processing phase
>    * Write a default action handler to handle the doEventSubmit actions 
> that it currently handles

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message