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