Great! 1 - yes, that's right, what I was asking was for a decision on whether we wanted to abstract it at all making it nicer to use. 2 - yeah, about that - i didn't note down enough during our conversation and now I'm not sure what that means anymore either, as WicketPortlet always delegates to the WicketFilter using RequestDispatcher#include and not forward. Hopefully Ate will chime in on this and clarify as he definitely had a point, and I thought I understood it at the time ;)
2008/10/10 Rob Sonke <[EMAIL PROTECTED]> > Hi, I'm colleague of Thijs (he's on holiday now) and we really encourage > this! We're using Liferay now with our custom wicket portlets which works > great (till version 5.1.x where they changed some core things which breaks > ajax requests, resource serving). > > I can promise you now at least our testing support at Liferay portals but > maybe even more (have to discuss that with Thijs first). > > I'm having a few questions about your plans: > 1. "Public render parameter support" > Forgive me if I say something stupid but what is not supported yet? I'm > using them now with the current 1.3 wicket trunk and works fine. > 2. Ate says "Dealing with portlet requests through forwarded requests as > opposed to includes" > What exactly does that mean, could you elaborate that a bit more? > > Good luck, can't wait to test new features. > > Regards, > Rob > > > > Antony Stubbs wrote: > >> Morning guys, >> >> This is msg is of course regarding the continuation and the finishing of >> the >> Portal 2.0 wicket support. I plan on continuing from Thijs' work done on >> WICKET-1620 here: >> >> Here are the two historical conversations regarding the topic >> -Portal 2 implementation: >> http://www.nabble.com/Portlet-2.0-implementation-in-Wicket-td17187909.html >> -original portal 1 implementation: >> >> http://www.nabble.com/A-new-proposal-for-Wicket-Portlet-support-td10863022.html >> >> I met with Ate the other day in Utrecht, Netherlands and we discused >> various >> things, some of which was the strategy we would adopt going forward with >> the >> P2 development. >> >> First thing is that we must come to a consensus with the Wicket team about >> the direction we will head. >> There are, as we see it, two options: >> >> 1) leave 1.0 support behind on 1.3 branch and move forward with 2.0 >> support >> on 1.4 branch >> >> 2) try to support both at once in 1.4 - isolate portal 2.0 support to it's >> own package >> >> My vote, and I think Ate agrees is to go with option 1 - leave 1.0 support >> behind. >> >> We also need to have release goals for all this. I.e. release target for >> portlet javadoc (1.4?) target for 2.0 implementation (1.4? 1.4.1? or 1.5) >> >> The most bbvious things left to be done are: >> 0. Documentation - there is lots of javadoc to be written about the >> current >> Portal support >> 1. Portal 2.0 event abstraction >> 2. Public render parameter abstraction >> 3. testing of the implementation on a couple of containers (e.g. Pluto, >> Jetspeed and Liferay) >> 4. writing some demo apps that use 2.0 features >> 5. potentially writing a module to support a portlet preferences container >> in web app mode, in order to have a complete wicket abstraction for user >> prefs. This would of course use the Portlet API support when running in a >> portlet context. >> >> Regarding 2 - the event abstraction, we saw there being 3 different stages >> of this, the first stage being the target for 1.4, as lvl 2+ require large >> wicket refactoring. >> - level 1 - event listener registration, similar to Swing - lots of manual >> interpretation of events etc >> - level 2 - built in to Wicket event system with pre defined events on >> components - with portal specific events. So Wicket would have standard >> portlet types of events which it interprets and calls predefined >> interfaces >> in your code for. What those standard events would be, requires some more >> conceptualising. >> - level 3 - wicket specific events - extend the concept of events into >> wicket as a whole. e.g. inter component / panel event system. These events >> of a general broadcast type nature, could in a portlet environment, be >> made >> to cross the portlet boundaries in a fashion transparent to the user. >> >> Regarding 2, there's not much work here to be done, except to decide on a >> nice way of abstracting the portal 2 api calls >> >> if anyone is aware of any other issues that need to be chased up regarding >> 2.0 support, please raise them now or attach them to WICKET-1620. >> >> Other issues Ate pointed out were: >> Dealing with portlet requests through forwarded requests as opposed to >> includes >> Dealing with streaming servers which don't support the option >> javax.portlet.renderHeaders option - using caching solution from Apache >> Bridges. (but there was some other gotcha wasn't there Ate?) >> Need to maintain the current support for containers which have no header >> contribution support by using inline javascript >> >> >> Regarding collaboration on this, well if I wasn't fully convinced with Git >> before, I certainly am now! >> >> I have setup a fork of Wicket 1.4 trunk on GitHub, which I can track with >> Git, where I have created three branches. This was done off of the new >> Apache git mirrors available here: >> http://jukka.zitting.name/git/ >> >> 1. a javadoc improvement branch for things Portletish (strictly method and >> class level javadoc only, maybe some fields) >> 2. a portlet 2.0 development branch (this already had Thijs patch applied, >> and a couple of comments, refactors from me) >> 3. a merge branch of the two >> >> Unless we decide that the javadoc can wait for the 2.0 implementation - >> which would be easier ;) >> >> I plan on keeping the javadoc branch separate so that I can easily create >> a >> patch/push against the 1.4 trunk, as Ate and I thought it would be good to >> get the Javadoc we write into the code base as soon as possible, while the >> actual Portal 2.0 implementation can continue on. >> >> The public github project is here: >> http://github.com/astubbs/wicket.get-portals2/tree/portal-javadoc >> >> Install Git (if you're on Windows, I recommend Cygwin/Git) and then you >> can >> clone the repository using: >> git clone git://github.com/astubbs/wicket.get-portals2.git >> nb, you won't be able to push to it though unless you make a github >> account >> >> and you can switch to the javadoc branch for example using: >> git checkout origin/portal-javadoc >> >> Here is some good Git information: >> http://github.com/guides/home >> >> Cheers, >> looking forward to hearing your thoughts. >> >> >> > -- ___________________________ http://stubbisms.wordpress.com/
