Weaver, Scott wrote:
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.
True, but I do filter the <html>, <head> and <body> tags out of the response,
see PortletInvalidMarkupFilter.java.
So, if correct, you should not get those in the portal page response markup.
See also: https://issues.apache.org/jira/browse/WICKET-651
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
When in a portlet context, the header output is already trapped by the portlet
support, see EmbeddedPortletHeaderResponse.java
PortletRequestContext has a protected newPortletHeaderResponse(Response) factory method which I put into place exactly to allow solutions as you describe below,
or, when portlet api 2.0 becomes available, to make use of the new (optionally supported) Setting Markup Head Elements feature.
See: http://hnsp.inf-bb.uni-jena.de/spec/JSR%202.0%20Spec/PortletSpec_20.pdf,
PLT.12.5.4.
Now, who got that into the spec ;)
I even already planned to provide a Jetspeed specific PortletHeaderResponse
(factory) for this and hook it into the HeaderAggregatorImpl.
And I think I would like to provide a transparent solution to "plug" such a
(portal specific) custom PortletHeaderResponse factory into the framework.
We can use the same solution as I used for the ResourceURLFactory, e.g. through an optional WicketPortlet init parameter (or even better:
WicketPortlet.properties) and set it as request attribute before dispatching to Wicket. Then, with a little refactoring of the PortletRequestContext class,
there will be no need anymore to extend the newPortletHeaderResponse(Response) method: it should check this request attribute first and use the provided factory
class instead if found.
But, I haven't had the time yet to do this, nor do I at this moment.
If you would be interested in providing such an improvements, I'd be happy to
help out/commit it to the Wicket trunk.
And, as we then could provide this "natively" with Jetspeed (using the WicketPortlet.properties), it would be even greater if we can get this available before
the Jetspeed 2.1.3 release cutoff (planned within just a few weeks time).
WDYT?
:)
Ate
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
