> -----Original Message----- > From: Luta, Raphael (VUN) [mailto:Raphael.Luta@;groupvu.Com] > Sent: Tuesday, November 05, 2002 1:41 PM > To: 'Jetspeed Developers List' > Subject: RE: [Proposal] PortletTool and changes in Registry format. > > > De : David Sean Taylor [mailto:david@;bluesunrise.com] > > > From: Luta, Raphael (VUN) [mailto:Raphael.Luta@;groupvu.Com] > > > Sent: Tuesday, November 05, 2002 10:24 AM > > > To: 'Jetspeed Developers List' > > > Subject: RE: [Proposal] PortletTool and changes in Registry format. > > > > > > > > > > > > As for the Action/Portlet issue, maybe it's possible to fix > > the issue > > > by using a default JetspeedPortletAction acting as a proxy to the > > > real PortletAction... > > > > I think the real problem is that the action is kicked in > > potentially before > > the portlet has even been loaded. > > Personally I don't want to go there, prefer working on 2.0 > > > > Actually, for most portlet actions you don't really care when you are > invoked, > hence the use of ProxyAction that would "eat" the event before the page is > loaded > and transfer it to PortletAction during the portal layout process when you > can > get access to the portlet...
It wasnt clear to me that the action was actually executing later, during the layout phase. All VelocityPortlet actions would be intercepted, and then called again during the layout phase, when the portlet instance is available. > > > > > > About the target date, if there's a consensus by tomorrow, I can > > > probably > > > integrate this feature without issue for the release, but I > > agree it would > > > be a risk. > > > > > > > Sounds like you've been busy. I was under the impression it > > hadn't yet been > > implemented. > > > > PortletTool is partially implemented in my dev version, PortletApplication > is not started yet and once everything is done, you may need to > account for > some serious testing to account for all the possible side effects. > Like I wrote, implementing the base PortletTool feature should be ok, but > may > have usability risks has there will be little time for extensive tests. > Have you written any tests... > > I tend to use Actions only for user interactions and encapsulate > all the real logic into stand-alone components (beans, tools, ejbs, > whatever...) I think Tools do not inavlidate Actions they just complement > it. The action is the entry point where the user control logic should be executed. Agree with the best practices, but how it is implemented is up to the user > > I was hoping that Velocity portlets would port to the new API > > by merging the > > VelocityActions into the main portlet itself, as the spec. leads to. > > > > I think everything based on the standard VelocityPortlet should be > portable whether you use tools or not (if you don't have tools you > just don't have any portal mechanism for efficient handling of > expensive resources): You have session scoping as described in the portlet api. But I agree that the session is way overused, esp. by Jetspeed. We could make use of other resource management techniques, and we've barely touched the surface of interacting with enterprise objects (ejbs) > > VelocityPortlet + VelocityPortletAction > = VelocityPortlet + VelocityPortletAction + 0 PortletTools > > It's just a simplified situation :) > Hey, don't start with those complex mathematical equations! > > > > > > The main question is: do we release first and then > > implement tools for the > > > next > > > release or first implement and then release, which may negatively > > > impact the > > > > > > release target date ? > > > > > > > I have no need to release now. I can wait. > > Others who have put in a lot of effort in the last few months may have > > different needs. > > Trying to be open minded: > > > > One argument is that this is a major change, and it can come > > out as the > > central theme of the next release, maybe even another rev such as 1.5. > > > > Why not get this lifecycle problem fixed asap so that users > > can plan for > > migration, and possibly push back the release to get it done right. > > (I also want to discuss (on another thread) what is planned > > for the next > > release, and what is still outstanding) > > > > My vote is the latter if Raphael can reassure on the stability issue > > > > Given the current feedback and the fact that I *can't* guarantee the > feature stability within let's say 2 weeks, I propose that we postpone > this to the next release, with a major focus on migrating all the > legacy code to Velocity or JSP portlets and provide a migration > roadmap to the new JSR API. > So you *can't* guarantee us anything, man, whats up with that... :) +1 on delaying this feature until next release. Are we still on for a release Nov. 11 and are you still considering reworking the out-of-the-box experience? I was hoping to clean up the tutorial for the release. -- To unsubscribe, e-mail: <mailto:jetspeed-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:jetspeed-dev-help@;jakarta.apache.org>
