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:26:26 GMT

Hmnn, attachment getting filtered, here is a URL it can be viewed at....


http://www.kuebler.org/EventService/jetspeed-event.gif


-tk



At 02:06 PM 4/9/2003 -0700, Todd Kuebler wrote:

>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


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


Mime
View raw message