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 
Jetspeed.

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
>>+1.
>
>
>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
>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
>
>
>
>-tk

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