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... > > > > > > > > > > Impact > > > > ------ > > > > As is, this proposal will mainly impact 3 areas of the Jetspeed: > > > > - registry markup: to be coherent with the <tool>, it would > > > be appropriate > > > > to > > > > "upgrade" the current "action" and "template" parameters > > > as standalone > > > > tags. > > > > This will impact all current entry defintions relying on these > > > > parameters > > > > - customization: since tools will have their own parameters, the > > > > customizer > > > > must > > > > be modified to allow customization of all parameters of > > > user or request > > > > scope. > > > > However, it must *not* allow customization of "global" tools > > > > which can be > > > > shared > > > > by several users > > > > - configuration: admin configuration of the Registry > entries need to > > > > recognize the > > > > new tags <tool>, <action> and <template>. > > > > > > > > Of all these impacts, only the first creates backward > > > > compatibility issues. > > > > > > -1 > > > IMO, No backward compatibility issues should be introduced at > > > this time > > > Couldn't you achieve the same goal by not invalidating > the old format? > > > > > > > Yes you can, see the end of my original mail but it would a > very awkward > > markup with no clear separation of what are the building > blocks of the > > portlet and what are runtime parameters. > > Again, you can mitigate the issue a lot by simply adding a > version id in > > the base registry tag. Upon loading a fragment, the registry > > implementation > > can check if it's using the latest version and if not > convert it before > > unmarshalling using the lastest markup. > > Upon saving, these fragments would be automatically > converted to the new > > markup... > > +1 on versioning which would leave backward compatibility in place > If there is no version, the old format is assumed > > > > > 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. > > However, I'm concerned that Jetspeed currently does not > offer any properly > > lifecycled "portlet" component which is going to become a > glaring omission > > when the JSR API will be released and the portlet tools > exactly fullfill > > these > > needs by becoming *the* way to implement porlet logic, > relegating the > > Portlet > > itself to a simple lightweight facade object, as it was > designed to do. > > Yes, agreed there is no proper lifecycle, and it seems that > Tools do have a > good lifecycle model. > I didn't realize that pull tools were based on Avalon life > cycle model, > which I think is very good. > > The standard concentrates more on extending the servlet api > metaphor of > Session objects, with Portlet and Portlet Application scoping. > I like the idea of tools as an added-value feature that will be > automatically populated in the standard session scoped objects. > As for implementing user logic, thats the role of Portlet Actions. > So then the migration plan is for the actions to wrapper tools.... > 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. > > > > > Additionally, I see the introduction of portlet tools as an > evolutionary > > path for Jetspeed 1 users towards the JSR API: > > - if the tools become the main way to create > functionalities, developers > > need > > not concern themselves anymore about the current Portlet API > > thus will not > > tie > > their main code to an API that is going to be deprecated > as soon as the > > standard is out. However it should be pretty easy to write a > > standard JSR > > compliant portlet facade that can reuse existing > tools/templates and > > actions. > > - once the toolmanager is in the tree, we can start to actively > > clean up the > > > > Jetspeed code from legacy stuff. Especially, we can convert all > > standard > > portlets to the Velcoity+tool pattern. > > Doing this with RSSPortlet and FileServerPortlet will mostly > > decoupled the > > main > > portal engine from the legacy diskcache, portlet cache > and syndication > > implementation > > since only the corresponding tools will have these dependencies > > Doing this with the XML and XSL portlet will enable us to > decouple the > > engine from > > the XML and XSL transform engine, which are not used by the > > engine itself, > > etc... > > > > Thus I see the tools as a mandatody feature to move forward and > > clean up the > > JS 1.4 > > codebase while working on implementing the JSR API in a brand new > > engine (I > > don't > > think the 1.4 codebase will ever be able to support the JSR > requirement > > without a > > drastic rewrite). > > Additionnally this will provide the 1.4 users a smooth upgrade > > path the the > > JSR API. > > Agreed that we need a smooth upgrade plan, and no way would I try to > implement the JSR API in the existing. > But I just want to make sure that I get the full picture. > Facts are that there are a lot of portlets already written, for me > personally, as VelocityPortlets. > What about Velocity portlets where all the user logic is > embedded in the > Velocity actions. > 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): VelocityPortlet + VelocityPortletAction = VelocityPortlet + VelocityPortletAction + 0 PortletTools It's just a simplified situation :) > > > > 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. -- To unsubscribe, e-mail: <mailto:jetspeed-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:jetspeed-dev-help@;jakarta.apache.org>
