Some more progress
I think I fixed point 2. (see the jira)
I've raised an issue at Liferay regarding point 1 (after re-reading the
portlet 2.0 specs)
I've also raissed an question on the mailing list of OpenPortal
portlet-container about point 3. Because it turned out that no
properties/headers are being set on the http-response when it is a
resource response. It works for a render response. So probably just a bug.
Some extra clarification on point 4: This is some lines of code in
WicketPortlet.processRequest. After you patch wicket it's on line 423.
The rest is still open.
Thijs
Thijs schreef:
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
