As this is something I need to work out, I'm continuing to investigate this.
My current line of exploration is around using Turbine actions.  I'm trying
to see if I can use a base Turbine action to set session level information
prior to any portlet being rendered.  (I also need to see if I can chain
Jetspeed actions behind Turbine actions.)

My second line of exploration will be to see how much work it would be to
use a custom portlet set control, especially with respect to jetspeed
upgrades and long-term maintenance (i.e. can I just inherit and
automatically get all upgrades or will I have to patch my custom class
manually).

If anyone has any comments, please feel free to either respond to the list
or to me directly.

I will post a summary of these two approaches to the list once I finish
exploring.

-- Michael

On 2/10/03 6:45 AM, "Dr. Lothar Simon" <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> we just started to apply Jetspeed. We try to solve a very very similar
> problem: We have a couple of portlets per page. Events in one portlet shall
> change user temp attributes which in turn shall influence the rendering of
> other portlets. As this is true for almost every portlet, we cannot (and
> should not, I understand) rely on any portlet execution order.
> 
> However, our only idea so far to solve this problem was: Create an invisible
> "first" portlet in the top left corner, that somehow (how???) intercepts
> action events and sends all events that finally influence other portlets
> (than the one the event goes to) to some central class for processing.
> Finally the result of the processing is put in the user temp attributes.
> 
> I could understand that there is not (yet) a mechanism for that kind of
> inter-portlet communication as this use may not have been in the minds of
> JetSpeed designers in the beginning.
> 
> QUESTIONS:
> 1. Is there really no standard mechanism for this kind of inter-portlet
> communication?
> 2. Is the "custom portlet set control" idea the only practical way (hack?)
> to solve the problem? (Are there other ways? Could ours work as well?)
> 3. If the "custom portlet set control" idea is the only/best... idea, what
> is the mechanism behind that and how should one do this? (some background
> information for the "custom portlet set control" idea appreciated)
> 
> Best regards,
> Lothar Simon
> 
> 
> -----Original Message-----
> From: Mark Orciuch [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 07, 2003 11:07 PM
> To: Jetspeed Users List
> Subject: RE: Portlet render/action execution order
> 
> 
>> Armed with my newly acquired JSP Action skills, I now suddenly
>> have another
>> question:
>> 
>> What is the execution order of actions and portlet rendering?  Are all
>> portlets with actions executed first?  Can I guarantee order of execution?
> 
> AFAIK, you cannot guarantee the order or execution.
> 
>> 
>> In looking over the debug log, it appears that portlets are
>> rendered in the
>> order they appear on the page, regardless of actions.
> 
> That is correct.
> 
>> 
>> My design goal is to track user clicks in one portlet, placing attributes
>> about the click into user temp storage, and allowing all other portlets to
>> render themselves based on those attributes.  This, of course,
>> assumes that
>> the "click handler" is executed first.
>> 
> 
> Perhaps a custom portlet set control would do the trick. But that opens up
> all kinds of interesting challenges and issues.
> 
> Best regards,
> 
> Mark Orciuch - [EMAIL PROTECTED]
> Jakarta Jetspeed - Enterprise Portal in Java
> http://jakarta.apache.org/jetspeed/
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to