De : David Sean Taylor [mailto:david@;bluesunrise.com] > > From: Luta, Raphael (VUN) [mailto:Raphael.Luta@;groupvu.Com] > > Sent: Monday, November 04, 2002 11:01 AM > > To: '[EMAIL PROTECTED]' > > Cc: '[EMAIL PROTECTED]' > > Subject: [Proposal] PortletTool and changes in Registry format. > > > > > > A PortletTool has a life scope similar to the Turbine and > have the same > > additionnal constraints based on these scope, ie: > > - request -> no constraints > > - session/persistent -> should be thread safe, must be serializable > > - global -> must be thread safe > > > > A PortletTool may only access parameters that are tied to > this tool and > > *may not* access portlet parameters if any. > > Why is that? > From VelocityPortlets, as we know the wall between actions > and portlets > creates great difficulties for developers. > Are we going to create the same kind of problem here? >
The main reason is that if you allow tools to access portlet wide parameters for their own configuration purposes, you're going to have a real mess to handle if you want to share a tool between several portlets. My statement was actually only referring to the configuration step (ie a ToolConfig would not include Portlet global parameters) and not the runtime where the tool can retrieve a reference to the live portlet from the context and then access its Config to retrieve all parameters). 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... > > > > 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... > > PortletApplication > > ------------------ > > To be really effective, the tools should be shared among > portlets working > > together > > to provide a versatile base of functionality, but Jetspeed > currently does > > not define > > any association of portlet behaving together as a "portlet > application". > > Such an application is only a placeholder providing a name > and a set of > > tools to share > > between all the portlets belonging to this application. > > > > To define such an application, it would be possible to > extend the registry > > markup so > > that a portlet entry may be contained within a portlet > application. All > > portlets that are > > not defined within a named application are considered to be > implicitely > > within their > > own applications, thus sharing no information with other portlets. > > > > ex > > > > <registry> > > <portlet-application name="myapp"> > > <!-- Tools shared by all portlets of application --> > > <tool/> > > <tool/> > > <portlet-entry> > > <template/> > > <action/> > > <tool/> > > </portlet-entry> > > </portlet-application> > > </registry> > > > > Any feedback appreciated. > > > > I guess the first question that comes to mind is will this impact the > release schedule. > Do you plan on getting these features in by Nov.11? > If existing registries will be invalidating, -1 on including > this in the > next release. > Otherwise, it seems like a lot of work and possible destablilization. > I would like to hear more about how this fits into the > release schedule. > Mark has contributed a lot feature work in this last > iteration. I think we > should put out a stable release concentrating on his > contributions, the > migration to Torque and Turbine releases, bug fixes, better > docs and as you > mentioned, a better out-of-the-box website. > 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. 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. 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. 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 ? > Portlet Applications and sharable Portlet Tools are very much needed > additions. I could see how this would make Database > browsers/edit forms a > lot easier. > Do you think these features should go into the next release? > What do others think, do we need a release by next week or do > we want to > push back the release to give Raphael time to finish the > Portlet Tool and > Portlet Application features.... > Yes, I'd definitely like to hear from Mark, Glenn, Paul and Santiago at least... it sometimes look like a dialogue around here :/ -- To unsubscribe, e-mail: <mailto:jetspeed-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:jetspeed-dev-help@;jakarta.apache.org>
