Ralph Goers wrote:
Stefan Hepper wrote:
Ralph Goers wrote:
We also have a requirement to have our theme process some portlets
differently than others. Ideally, a portlet (and pages for that
matter) should be able to have attributes associated with them in
the portlet.xml that the theme can interrogate.
The portlet can do this today: it can set things as init params in
the portlet.xml or as response properties at runtime.
I don't recall reading how those are made available to the theme.
Given that themes are not part of JSR 286 this will be vendor specific.
We also have to share attributes between portlets and several
servlets. Our current vendor supports this including in servlet
filters in front of the portal. I haven't read the spec in a draft
or two, but I assume sharing is still limited to shared render
parameters. I have no idea why this limitation exists. I heard
something about it being not implementable in all containers, but
that doesn't make sense since the portal we are using runs in
virtually every container.
No, the spec does not limit the sharing of parameters to only
portlets, but on the other side, how would a portal implementation
know that a URL targeted to a servlet should contain the current
shared render parameters?
Our portal requires that shared parameters be namespaced and the
portal be configured with the namespaces to share. They are available
to everything (including action requests). This may not be ideal but
it is better than nothing. We end up having to leverage our vendor's
post login hook and then store our data in the servlet session.
In short, the spec allows me to build fairly simple portlets but is
completely deficient in when it comes to building applications made
up of groups of related portlets.
I completely disagree with that assessment. If you have a loosely
coupled portlet component model in your mind JSR 286 will provide you
with many things to create really complex applications based on
different portlets in different portlet apps.
If you expect that JSR 286 will provide you a model where you can
create larger, pre-packaged apps that consists of pages, portlets on
the pages, wires between these portlets, and themes for these pages,
I agree that JSR 286 will not help you here and you need vendor
extensions for now. On the other hand you get this JSR by end of this
year instead of end of 2009....
To give you a perspective, the application is for online banking. Each
of the portlets provides different functionality. However, many of the
portlets share the user's account information, etc. Some information,
such as the list of accounts, current balance, etc. needs to be
retrieved during login and then shared across all the portlets. From a
portal perspective it isn't an extraordinarily complex application. We
have several portlets on one page that all need access to an account's
history for some number of days so they can do various things with it.
This kind of stuff is very messy to do with the current portlet spec
and 286 doesn't seem to help much. Having to be tied to one vendor is
a problem as it makes it difficult to sell the product to larger
banks, which presumably would prefer to use the portal of their choosing.
One implementation that works with JSR 286 is that you register for the
navigationalContextChange event, trigger that event when the page is
loaded the first time, set the customer id as a shared render parameter.
For providing the account history to different portlets you would create
a service that would retrieve this once and cache it and this service
can be called by different portlets.
Obviously, I don't want to wait until 2009 - but it sure sounds like
I'm going to have to wait anyway. Frankly, there are only a few items
in 286 that are of interest to me, such as support for fragments. For
example, I already have portlet filters using Spring. So I'd gladly
wait 6 more months to get some of these larger issues dealt with.
What you are asking for takes at least two more years of discussion, not
just 6 month.
Stefan
Ralph
