> -----Original Message----- > 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 > > > > > > > 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. > 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.... > > 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. > > 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 David -- To unsubscribe, e-mail: <mailto:jetspeed-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:jetspeed-dev-help@;jakarta.apache.org>
