portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weaver, Scott" <Swea...@rippe.com>
Subject RE: Ideas for 1.4 Event Model addition
Date Thu, 10 Apr 2003 18:49:37 GMT
> 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.

Peter Coad rocks as does his Java Design book! I have read it twice ;)


*===================================*
* Scott T Weaver                    *
* Jakarta Jetspeed Portal Project   *
* weaver@apache.org                 *
*===================================*
  


> -----Original Message-----
> From: Todd Kuebler [mailto:tkuebler@cisco.com]
> Sent: Wednesday, April 09, 2003 5:07 PM
> To: Jetspeed Developers List
> Subject: Re: Ideas for 1.4 Event Model addition
> 
> 
> 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