portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weaver, Scott" <weav...@ugs.com>
Subject IHeaderContributor behavior in Wicket Portlets
Date Wed, 26 Sep 2007 14:28:41 GMT
Ate,

 

I noticed Wicket portlets need to have a <head> section in them for
header contributions to work.  This works fine, however afaik, it is not
considered valid (x)html and could possibly introduce unexpected bugs
into the front-end.  Any thoughts on adding header contributions to the
layout/themes <head> section?  I think we could accomplish this quite
easily.  In Wicket, we could check to see we are in portlet mode (easy
check
getWebRequestCycle().getWebRequest().getHttpServletRequest().getAttribut
e("javax.portlet.request") != null) and instead of writing header
contribution to the markup output stream we put all the pre-rendered
header markup in a List in a PortletRequest attribute, say,
org.apache.jetspeed.wicket.headers.  For rendering the header
contributors, we have two possible options:

 

The Jetspeed-specific approach would be to check for/render header
contributions inside the HeaderAggregatorImpl.  I am just guessing at
this, but from looking at the code, this appears to be the proper place
for the logic.

 

The Jetspeed-agnostic approach would be to add a servlet filter to the
portal's (in this case, Jetspeed's), web.xml that checks for the
"org.apache.jetspeed.wicket.headers" attribute and re-writes the
header-portion of the markup stream accordingly.

 

As a fallback, a switch could be to the application settings in Wicket
to revert to the currently implemented approach if there are issues
implementing the above approach in other portals.

 

WDYT?

-scott


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message