On Oct 9, 2008, at 4:51 PM, 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 +1 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 +1000 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 i dislike swing's event listener style. an interface per event is ugly and tedious to maintain. a better system is to parameterize a single event listener interface on the event type. i've done this before and it works out quite elegantly (you can even listen to classes of events using the event class hierarchy). the only real downside is that you need to use anonymous classes to listen to more than one event, but i don't personally care about that at all as i think that is the preferred style anyway. so i would prefer this style of listener and happy to discuss when we get to this. i think 1.5 (or some version of wicket soon) should include wicket broadcaster/listener events. however, it would be best not to refactor any aspect of existing wicket code to accomplish this. rather than replacing existing "event" methods (onXXX etc), events should be a parallel system. in my opinion, it is not desirable to unify these two systems and it is actually a better design to continue using onXXX in core wicket for a number of reasons (efficiency, discoverability, simplicity, compatibility, etc). 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! -1 i'm sick of new version control systems. i want simple eclipse integration and since SVN finally works for me i wish people would stick with it. -- View this message in context: http://www.nabble.com/Finishing-Portal-2.0-development-tp19909563p19920678.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
