At 02:09 PM 3/31/2003 -0500, Weaver, Scott wrote:
I think there is obvious need for some type inter-portlet messaging service. However, as Todd said, the current portlet life cycle would need to be re-implemented to be aware of such a thing.
<snip> .... </snip>
I still see blocking issues though. If I am Portlet B and I require information from Portlet A, what do I do if Portlet A has not be materialized yet? However, if you notice that the Fulcrum services within Turbine can fall prey to the same "has my dependency been initialized yet?" issue. The solution is that your dependent service must immediately initialize the required service(s) at that point.
I haven't thought this through fully yet, but here are some more concrete ideas.
This is where scoped actions/context come into play. I think the action/context scope tree with chained context processing I described earlier is the only way you could implement it cleanly.
There would be a (Context) / (Action Handler) pair for each of the scopes [session|portal|portlet set|portlet|portlet instance], with the current action handling in the GenericMVCPortlet being the portlet instance handling and the last link in the chain. The context object would originate in the session scoped handler and be passed down/cloned to each of the scope handlers until it arrived in the portlet instance. Each of the handlers would deal with their scope only. This would solve the dependency issues because if you wanted data in the context at one of the higher scopes, you would just write an action to handle the context at that scope level. By the time it got down to the individual portlet level the data would already be in each of the contexts because it got populated at a higher level.
Now to figure out where each of the action/context scopes would be processed and how to add in the idea of scope to the action idea.
[OT]
Todd,
I have been playing with the guts of the PortletAction and GenericMVCPortlet. I created a init(RunData, Context, Portlet) method within the PortletAction class that is invoked prior to action execution. This method populates protected instance variables within the PortletAction like Portlet and PortletInstance. This allows sub-classes easy access to this type information as opposed to always having to look through the context for it. The PortletAction ends up having a life cycle much like that of request-based pull tools. What do you think?
Sounds exactly like what I was thinking. :) Although this new context scoping and lifecycle discussion could change it a bit. Still thinking about that....
*===================================* * Scott T Weaver * * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===================================*
> -----Original Message----- > From: Todd Kuebler [mailto:[EMAIL PROTECTED] > Sent: Monday, March 31, 2003 1:32 PM > To: Jetspeed Developers List; [EMAIL PROTECTED] > Subject: Re: Jsp Portlet Problem. > > Do you want _another_ portlet to get the string, or are you talking about > having an action put something in the context and the jsp picking it > up? The second case is handled by the GenericMVCPortlet. The first case > is a little tricker. > > If you are needing 'inter-portlet communication' you could use the session > object (via org.apache.jetspeed.util.PortletSessionState > ), write a turbine service or use an intermediary like an ejb to manage > your shared data for you. The obvious drawback to this approach is that > other portlets may not have access to this new information until the next > request ( depending on were they are in the page rendering cycle relative > to the portlet action that is placing the information in the data 'cart' > ). > > There really isn't a good solution for this that I have discovered, please > correct me if I'm wrong. The best hackish way I've found to 'send data' > to > another portlet immediately is by calling an action directly on that > portlet via org.apache.turbine.modules.ActionLoader in your action or > setting the portlet id (js_peid) and 'action' variales in the template > form > to the other portlet id etc. > > Anyone else have better ideas? A scoped context object/ scoped actions > would be cool, but I think to implement this with our current portlet > lifecycle you would have to add an action handling phase for each of the > scopes to the page rendering or whatever, ie 'handleGlobalActions()' etc, > with the portlet handling only the portlet scoped actions and the > GenericMVCContext being passed along to each of the subsequent scope > stages > for additional processing. This seems like a lot of work to me, but > probably doable. Has there been any talk of such? I imagine there would > be a 'session', 'portal', 'portlet set' and the current 'portal' context > scopes, and that the starting context object for each request would be > cloned from the session object and passed down through the differet > scopes, > ending up as a parameter to getContent(). > > Then again I could be 'missing the boat' entirely. :) > > > -tk > > > At 07:58 PM 3/29/2003 +0200, nick the mytilian wrote: > >Hi, > > > >I am facing the following problem: > >I use the JspPortlet to present the output of a JSP in a portlet. > >I want to "put" a String in the context, so that another portlet > >can get it. > >Unfortunately, i see that the only way to use something like: > >String lala = (String) rundata.getSession().getAttribute("Testing"); > >context.put("testing",lala); > > > >is to implement a portlet with action that extends the > >VelocityPortletAction. > > > >BUT: I do not want to use Velocity! (I have already written the code in > >JSP) > > > >How can i put something in the Context, using the JspPortlet and not the > >VelocityPortlet? > > > >Thanks in advance! > > > >Nikos. > > > > > >--------------------------------------------------------------------- > >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]
