On Monday, July 21, 2003, at 01:16 PM, Jason Weiss wrote:
Upon review of JSR 168, it is clear that the spec requires the use of a deployment descriptor (portlet.xml) to formally define all known portlets in a portlet application. On my project we have exposed the Jetspeed Registry APIs via a Servlet to dynamically define new portlets. For example, we can provide a couple of parameters to our custom servlet which in turn translates the query args into registry API calls, and <poof> we have a new Portlet defined that shows up in the pick list, <poof> we can delete an existing portlet, etc. In many ways, its a non-visual interface into the admin pages of > Jetspeed.The deployment descriptor is a "standard way" of deploying portlets in portlet applications.
With JSR 168 moving to a deployment descriptor metaphor, will this capability of dynamically adding portlets to an existing application be lost?
The descriptor is not the backend storage, it is not the portlet registry.
The capability to dynamically add portlets will not go away because of the descriptor.
Each portal implementation can provide other (non-standard) means of manipulating the registry
One of the thinks that we will win with the PortletAPI is that Jetspeed will be much more modular:
- a small core -- container -- aggregator -- common services
All the rest can be implemented as portlet Applications (nipples did not caught on, dit it?)
- admin portletApplication (non standard, special APIs for deployment, Registry API, PSML management, etc.)
- syndication portletApp
- webmail/news portletApp
- yourPortletApp, with your business portlets
...
And don't forget that the deployment of a WAR is dynamic. WARs can be deployed or reloaded during runtime.
If we write the Admin as a PortletApplication (and there is a rough consensus on this), we will need to clearly specify the different APIs it would need to acess the Registry, the PSML repository, even the User DBs.
Regards
-- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] +01 707 773-4646
Regards -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
