Thijs Vonk wrote:
I've started on implementing the portlet 2.0 specifications. I've opened
https://issues.apache.org/jira/browse/WICKET-1620 to apply patches to
when I get something useful.
But I have some questions before I can go any further.
First of all, do we drop portlet 1.0 in favor of portlet 2.0? I suppose
we do because we need java 5 to support 2.0 but portlet 1.0 doesn't
support java 5.
Portlet 1.0 doesn't require Java 5, that's not the same.
I don't want to drop support for portlet 1.0 yet, certainly not until Jetspeed
2 provides portlet 2.0 support :)
My proposal is adding a new WicketPortlet2 class (or something, I don't like the name but haven't come up with something
better yet). This class should set a clear marker (like a new request or portlet context attribute or something) to
indicate to the other supportive classes within Wicket which environment the current request is dealing with, and use
the native Portlet API 2.0 methods if in context of the current request.
If I understand correctly I can drop de ResourceUrlFactory because this
is provided by the portal. I should then also be able to drop the wicket
WicketPortlet.PORTLET_RESOURCE_URL_PARAMETER and
PORTLET_RESOURCE_URL_ATTR. Because the lifecycle of the request tells if
the request is a resource request or not.
Correct.
What I'm not sure about is the ServletContextProvider. (from apache
portal bridges) I can't really determine if I can drop this as well. For
now I've left it in and it seems to work (on Liferay) but I could be
doing some hybrid crossover now :)
That one isn't needed anymore either for portlet 2.0. The
PortletRequestDispatcher now supports all request types.
And now I'm a bit stuck :) Liferay seems to have a problem with adding
http headers in a portlet response. Preventing some ajax stuff from
working. It looks like the PortletResponse.addProperty(etc) is not
implemented. So I've setup glassfisch with openportal-container 2.0 rc2,
but that's not helping either I haven't been able to get Wicket running
properly yet. The portlet bridge i've written seems to work, but when I
click a link in the portletm, wicketfilterportletcontext.setupfilter()
isn't able to find any of the set values in the request (not the
RESPONSE_STATE_ATTR nor the REQUEST_TYPE_ATTR)
Well, that is something we need to look into, but in general add/setProperty
better be supported on those containers :)
Ate, how is Jetspeed doing with portlet 2.0? If I download trunk, will
Wicket work and what is the status of jsr-286?
No, not yet.
Jetspeed-2 trunk hasn't been upgraded to Pluto 2.0 yet so is still based on
portlet 1.0.
I've started some preliminary work on getting Wicket working with the Pluto 2.0
(trunk) Portal Driver myself.
Doesn't work yet as I haven't had enough time to dive really deep into it, but I'm definitely interested in the changes
you've made so far and see how we can join our effort on this.
It would be great if you could attach a patch file of your changes to the new
JIRA issue for example.
BTW: I won't be able to do much on this issue this week as I have to go to
Dublin for a client.
Ate
Thijs
