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.
