It looks like I may have a significant amount of time to devote in the next couple of weeks to portlet support in Wicket. I have read about half of the specification (will finish it soon) and have some ideas for how to improve abstractions already, but could use input in terms of people's wishes as well as documentation of the existing implementation (particularly in tricky areas in the code).
Thijs wrote: > > 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 >> > > > -- View this message in context: http://www.nabble.com/Portlet-2.0-implementation-in-Wicket-tp17187909p17308612.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
