portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 21294] - Event Model proposal
Date Wed, 02 Jul 2003 23:04:10 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21294>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21294

Event Model proposal





------- Additional Comments From tkuebler@cisco.com  2003-07-02 23:04 -------
Now for some words to go with the picture...

- Backward compatible, sits beside current turbine based actions. 
- Event handling system similar to awt. 
- ScopeEvent class that holds the event that is being fired (scope, source, etc
contained within) 
- EventListener 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 EventService (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. 
- EventService (turbine service) with a addActionListener method.  EventSources
for each of the scope trigger points will register with the EventService which
also initializes and holds the events/eventlistener map and distributes the
events to the proper eventlistener when the scope event trigger happens.  Also
will manage the context 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 an EventService 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 EventListener, or could register the default action class with the
EventService on init and not actually process the events anymore itself.  It
would however be the final receipient of the context.

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