portals-pluto-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Hepper <sthep...@apache.org>
Subject Re: Adding JSR-286 API jar to a Maven repository
Date Wed, 18 Apr 2007 15:56:00 GMT
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.
> 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.
> 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?
> 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 


> Ralph
> Stefan Hepper wrote:
>> JSR 286 is in feature lock-down mode now. What use cases are you 
>> referring too that cannot be done with JSR 286 involving several 
>> portlets?
>> Stefan

View raw message