Hi Ate,
I've done some work, I've attached an initial patch to the Jira issue.
It has the following basic modifications.
I've completely removed the servletContextProvider and
ResourceUrlFactory. I've added a PortletMimeServletResponseWrapper that
is extended by PortletResourceServletResponseWrapper and
PortletRenderServletResponseWrapper, and I've implemented serveResource.
Also some other things, but you'll be able to see that in the patch.
The patch is based on the assumption that portlet 2.0 implementation
will replace the 1.0, but that's just because I started out that way, I
haven't looked at the 'side by side' option.
There are some things;
1. Calling resourceResponse.createRenderUrl: In Liferay this throws an
IllegalStateException. Because, according to them your not allowed to
create a renderUrl from a resourceresponse. This is a problem when we
want to do a setResponsePage(new WebPage()) in a ajax call.
In openportal, I am allowed to create a renderUrl because they check if
the CacheLevel is equal to type PAGE (which it is) and so I get a
RenderURL back. Is the way OpenPortal does it correct? Because then I'll
open a jira issue for Liferay to handle that properly.
2. When in a ajax call (ResourceRequest) and we do
setResponsePage(WebPage.class), and WebPage.class is mounted, the
current implementation doesn't break out of the ResourceRequest, it just
creates a new ResourceURL. When this happens, I only get the Markup of
the portlet back, not the whole portal page.
3. The add/set property for a resourceresponse in openportal only
accepts cache-contol and similar headers. So the Ajax-Location header
does not work on this portal (jet)... So I can't test the ajax redirect
on it. I'll see if I can open an issue for it...
Can't we change the Ajax-Location to be inside the xml response? Then we
never have any trouble with that http header. (Because doesn't it say in
the portletspec somewhere that a portlet can't depend on the headers
being set?)
4. I have some open TODO's in the patch for some small issues, one is
the request.setCharacterEncoding which is allowed when not in an
actionrequest or resourcerequest. For now it doesn't do anything. But
there should be a check in what PHASE we are. (or add extra sub-classes
for every request, like we have for the response types)
Then there is the sendRedirect in a non ActionRequest, I've commented
that bit, but it needs to be fixed.
5. Do we want to do something with the Portlet.doHeader call? If I
understand the documentation correctly it should be possible to set add
markup to the <head> in that call if the portal supports it. Liferay &
OpenPortal don't at the moment. But if we do then we might have to move
all the processing logic to the doHeader call, and store the rest of the
response for the doView/etc calls?!
6. I have not yet thought about the processEvent.
I hope with this patch you can run Wicket on Pluto also, at least parts
of it :)
Thijs
