> -----Original Message-----
> From: Ate Douma [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 26, 2007 4:11 PM
> To: Jetspeed Developers List
> Subject: Re: IHeaderContributor behavior in Wicket Portlets
>
> 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
>
I now see that you are, in fact, stripping out those tags. Don't know
how I missed that :)
> > 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 ;)
Hehehe, so I guess that was your doing. I skimmed the new spec sometime
back, need to look at it again.
>
> 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
I will look into it, and see I can swing some time to implement this
prior to release. I can't guarantee anything since I probably will have
to most of this work at home as I don't get much time to spend on
Jetspeed at work anymore :( Along with that I would love to start
helping out with the new, wicket-based admin portlets.
Thanks again for the Wicket support. It pretty much made my year ;)
-scott
>
> > 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
