Ate Douma wrote:
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
-1
My vote, and I think Ate agrees is to go with option 1 - leave 1.0
support
behind.
Yes, see above.
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)
Not something we (or at least: me) can "plan" for upfront.
That really will depend on the progress and the amount of impact the
new implementation would have.
As far as I understood, 1.4 is targeted as a compatibility release,
e.g. no major API changes.
If true, the portlet 2.0 support really will have to wait for the 1.5
release I think.
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
1. Portal 2.0 event abstraction
+1
Jonathan Locke's response seems interesting, need much more discussion
though.
2. Public render parameter abstraction
Rather straight forward and already possible today *if* you are
willing to use portlet api methods directly.
The question here would be: is there a use-case from Wicket framework
POV to "share" state with other Wicket applications?
In plain "web" mode, Wicket really is dealing with only one
application at the time, which makes it unclear to me where the
benefit (from generic Wicket framework POV) is to provide "native"
Wicket support for this feature.
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.
+100
I already discussed this in the past with Jonathan and I think the
Portlet Preferences feature definitely qualifies as something what
could be of general usage for plain "web" Wicket applications too.
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
-0, haven't given this enough thought but this doesn't seem so easy to
implement/use
- 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.
+0, mostly the same as above, I haven't given this enough thought yet
- 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.
+1, this is what, from a portlet developer POV, would most directly
map to the actual use-cases.
However, its not clear to me yet how this could be usefull for plain
web application use-cases, nor how to actually implement this.
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
Portlet 2.0 specified that serveResourceURLs need to be send as a
forward, not an include to portlets.
As Wicket has some specific handling for forwarded urls (don't
remember right now where, but it definitely is tricky code),
I remember I had some problems implementing the required portlet url
handling for that.
So, as this is now going to be the standard/required interaction for
serveResourceURLs, this is some area in the code to review again and
see if/when/why it might break because of that. AFAIK, Thijs already
encountered this with Liferay, right?
That's very interesting, we're in discussion for a while with Liferay
about this issue but maybe this means that wicket is the bad guy here
:). I'll discuss this with Thijs as he investigated this problem. But
when it's true, we could create a temp fix in Liferay till Wicket
supports this. I'm pretty sure that Thijs also sent you an email about this.
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?)
No, not really, except that that "caching solution" hasn't been
written yet :)
But I think you might confuse this issue with that of the "isolated
servlet session", which is an optional feature of the portlet 2.0 spec
but which Wicket really depends upon. That feature *is* available from
Portal Bridges and used already.
For Pluto/Jetspeed we'll provide the same of course, but as an
optional feature one cannot rely on the container to provide this so
Wicket might just as well keep using the Bridges solution just as well
to be ensured of this feature.
Need to maintain the current support for containers which have no header
contribution support by using inline javascript
Yes, there is alternative there.
However, in practice I expect this to be of a lesser problem as
most/all containers would want to provide this feature because of its
obvious benefit.
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/
Like already commented before by others, I'm also not very fond of
using another and *external* (to the ASF) version control system.
While I have no problem with you using that for your own benefit (I do
understand why), I'm of the opinion (and I think many ASF
committers/members with me) that we must stick to the ASF way of
collaboration: fully in the open and with anyone having a chance to join.
So, for me, you can keep using the Git solution, but to discuss and
review changes and patches I insist on that only to be done here on
the dev mailing list and through JIRA issues and (patch) attachments.
Thanks for taking the initiative here Antony.
It was good meeting with you and I hope I can contribute as much as I
can.
But the next few weeks, definitely until the ApacheCon for which we
(Apache Portals team) are planning to have Pluto 2.0 and Jetspeed 2.2
released, my time will be extremely limited.
Regards,
Ate
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.
