portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shinsuke SUGAYA <shins...@yahoo.co.jp>
Subject Re: Proposal to extend the Portlet API to include doHeader()
Date Tue, 07 Mar 2006 22:46:04 GMT
Hi Randy,

I think it's interesting solution. I hope that JSR 286 has it or the

My question is, if user deploy JetspeedGenericPortlet to other portal,
does it work? On Portal other than J2, I expect that JetspeedGenericPortlet
can work though doHeader() do nothing.

Since this change affects my portlets, it would be great if you can
provide me the interface info for doHeader() you are thinking.


Randy Watler wrote:
> Gang,
> As we delve into richer client side applications, the need to manage 
> header content for portlets becomes more pronounce. We currently have 
> the header-resource component and it does a good job at what it can do 
> from the jetspeed context. However,  we now we have a requirement  to 
> generate header content from velocity templates as we do for view, edit, 
> help, etc. modes using the velocity bridges portlets.
> I attempted to extend the existing header resource component by setting 
> up its own velocity engines, but ran into a brick wall when I tried to 
> execute templates/toolboxes in the portlet app context. There still may 
> be a way to make this approach work, but it was getting ugly and I 
> started looking for another way. After speaking with David, he suggested 
> extending the Portlet API by adding a doHeader() API. After thinking 
> about it overnight, it does seem very attractive.
> Apparently, there was some discussion concerning adding doHeader to the 
> Portlet API for JSR-286. I am not sure what the status of that proposal 
> is. If we add doHeader() to JetspeedGenericPortlet, we no doubt will be 
> departing from the standard API. The use of the header-resource 
> component creates an identical portability problem, so I dont feel that 
> doHeader() should be viewed as somehow worse from an API pollution 
> perspective.
> The purpose of this API is to allow portlets to contribute header 
> content into page. However, there are many more restrictions on what 
> individual portlets should be allowed to insert in this shared scope. 
> One of the biggest constraints: duplicate tags and javascript 
> declarations/invocations should be stripped so that only one minimal set 
> of header content elements and scripts is added to the header. The 
> current header-resource component limits what can be inserted in the 
> header to enforce these restrictions; arbitrary text cannot be inserted.
> It is not clear that we can support arbitrary text inclusion from 
> velocity templates and yet maintain the constraints above. This is still 
> being kicked around: velocity templates and doHeader() seem to offer a 
> powerful implementation paradigm, but a limited java API based approach 
> can avoid parsing header content in an attempt to create a minimal 
> header. Any ideas here are welcome! Early middle ground approaches might 
> include HTML tags with well known ids or using an import like API that 
> includes templates inline during later aggregation.
> Comments, ideas, or other input welcome... just wanted to get the 
> discussions started here on the email list.
> Randy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message