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.
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/
