portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Watler <wat...@wispertel.net>
Subject Proposal to extend the Portlet API to include doHeader()
Date Mon, 06 Mar 2006 20:40:05 GMT
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


Mime
View raw message