On Thu, Oct 9, 2008 at 7:51 PM, Antony Stubbs <[EMAIL PROTECTED]>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. > This definitely sounds like the better option if it can be completed promptly. Ideally wicket portlet support could make it relatively easy to support both incoming and outgoing remote portlets - I read through the (ferociously complex) WSRP spec and it sounds like that to be usable by the mainstream, some simple ways of handling common cases are sorely needed. Is that one of your design goals for this project? > 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. > I agree with Jon here - it sounds like you're talking like a sort of generalized "event bus" system. Certainly those are needed for portlets, but I think trying to come up with a unified model of handling "global" events and handling the on*() type of events that are local to Wicket components are very different things, and trying to make them similar will probably just make both more complicated. Take a look what we did in the Gizmo prototype - specifically, public interface IListener <T extends Event> { void onEvent (T event); } coupled with public <T> void addListener (IListener<T>) {} In other words, have single onEvent() methods which are passed a type makes better use of the Java type system than what Swing does. On that note, since listener leaks are the most potent source of memory leaks in Java desktop applications, it might be worth considering defining the lifecycle of such listeners - for example, that the caller must keep a strong reference to the listener or it can be garbage collected. Your call, but we might as well not recreate the serious problems of the listener pattern as used in Swing. > 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 > I'll leave it to you guys to work out, but it would probably be best to keep your code with the rest of Wicket for social reasons. I can certainly understand not wanting to use SVN, due to its (non) handling of branch history. -Tim
