Hi Jason, I do the same thing. I have portlet that allows me to generate other portlets. I'm sure, at least from a Jetspeed stand point, we will retain this functionality.
Through jetspeed, you will still have access to the registry info, either directly through the registry service or through JMX MBeans. *===================================* * Scott T Weaver������������������� * * Jakarta Jetspeed Portal Project�� * * [EMAIL PROTECTED] * *===================================* � -----Original Message----- From: Jason Weiss [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2003 4:17 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: JSR 168 and Jetspeed Registry APIs 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. � With JSR 168 moving to a deployment descriptor metaphor, will this capability of dynamically adding portlets to an existing application be lost?� � There is no API in J2EE that formally modifies existing deployment descriptors.� For example, if I dynamically add a new portlet, there is no formal API for updating the portlet.xml to reflect the addition of that new portlet.� Bear in mind I'm talking about referencing existing portlet classes, e.g. IFramePortlet, where today I can declare new portlets dynamically via the Jetspeed Registry APIs and simply pass in my parameters like source, height, etc.� There are no requirements to deploy a new Java class that represents that portlet.� In Jetspeet .xreg terms, the net-net is that the Registry API's set their attributes to something like � <portlet-entry name="My Dynamic Portlet" type="ref" parent="IFramePortlet"> ... </portlet-entry> � and a new entry is created and shows up in the appropriate .xreg file.� While this continue to be the case even after JSR 168 is incorporated?� I'm just confused about where the portlet.xml file will fit into the process.� � It would be a travesty to lose dynamic portlet creation in the name of a deployment descriptor architecture!! � � -- Jason R. Weiss [EMAIL PROTECTED] Cell Phone: 832.443.7161 �
