Hi Randy,
I think it's interesting solution. I hope that JSR 286 has it or the
like.
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.
Thanks,
shinsuke
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------
TSUKAME EIKOU! KAGAYAKE EGAO!
Yahoo! JAPAN JPC OFFICIAL PARTNER INTERNET PORTAL SITE
http://pr.mail.yahoo.co.jp/wintergames/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
