yeah, portlet events is one thing. another is to create an application / requestcycle / request / response abstraction for portlets. i think this may be a better and more maintainable structure.
i think ate is busy for a few days. i'd like to wait to talk to him before i proceed. it seems like one obvious way to do this would be to let the existing code support 1.0 and to create a new package with improvements and abstractions for 2.0. i think people will not have much desire for 1.0 support in the long term. it has some pretty serious limitations and i doubt we want to design for that as a lowest common denominator. Thijs wrote: > > Hi Jonathan, >> It looks like I may have a significant amount of time to devote in the >> next >> couple of weeks to portlet support in Wicket. > > That would be great. > >> 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 > > What kinds of wishes are you talking about? > Things like portlet event handling, etc? > >> as >> well as documentation of the existing implementation (particularly in >> tricky >> areas in the code). >> > > Unfortunately I can't really help you with the documentation part, as I > don't have it. My current knowledge is purely based on the use cases > I've encountered with our project and where I've been stepping/debugging > through the code. I hope to get enough knowledge so that I can actually > document some of it in the code base, but I'm not there yet. > > Probably Ate can help you with some documentation/explanation, as he's > the original designer. > > I'm looking forward to hearing your suggestions > > Thijs >> >> 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-tp17187909p17327505.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
