portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: [Bug 18865] - [Enhancement] MVC Portlet Action Life Cycle
Date Tue, 15 Apr 2003 15:09:40 GMT

On Monday, April 14, 2003, at 11:24  PM, Todd Kuebler wrote:

> The event model I was refering to is not in the MVCPortlet and is in a 
> post I sent out last week.  It is intended to add scoped event/action 
> handling completely decoupled from turbine and at different points 
> outside the portlet getContent method , but it is still in proposal 
> form.  I have had no feed back to date on it.  I will be implementing 
> it over the next couple of weeks and had planned to post my progress 
> here.
> For the MVCPortlet I just copied verbatim what was in the Velocity 
> portlet regarding action handling except that the GMVCP Action class 
> is provided that decouples the context,etc from velocity.  As far as I 
> know the old velocity actions should also work.

Is this it?
I was 'away' from Jetspeed for a few weeks. I most have missed this one:

<from Todd Kuebler on April 4, 2003>
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 

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

Also found this


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

View raw message