|
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
Cell Phone: 832.443.7161
|
<<OmniCoders Background.jpg>>
smime.p7s
Description: S/MIME cryptographic signature
