portals-pluto-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: Adding JSR-286 API jar to a Maven repository
Date Thu, 19 Apr 2007 06:31:38 GMT
Stefan Hepper wrote:
> Ralph Goers wrote:
>> The discussion we had some months ago. I have application logic that 
>> needs to be exercised upon login. Currently I can do this through my 
>> portal vendors extensions. I also have several portlets on a page 
>> that need to use the same initialization. The only way to do this now 
>> is extremely clumsy as each portlet has to do it and check that it 
>> hasn't already been completed.  A better mechanism would have been to 
>> provide a way to invoke a method when a page is accessed.
> As explained such page behavior is beyond the JSR 286 scope and would 
> need to be addressed in a future version and then define a more 
> complete page model.
I know. But I think that was my point. It is a feature that is missing 
that I need today.
>> 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.
>> 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.

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.


View raw message