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
