Martin,
PPR in Portlets CAN be implemented using certain portlet
implementations. But it cannot be done with generic JSR-168. Here are
a number of problems although I'm sure there are more:
1. Action Requests have portal artifacts. This means that a portal can
append content to a response (and typically will) making it insufficient
to use in an XMLHttpRequest and/or an iframe with ppr data and JS.
2. Resource Requests are not in-protocol. This means that if we decide
to retrieve the PPR segment as a resource, we are not guaranteed to have
the same session.. Especially in remote WSRP type environments. Even
if we "could", portlet-scoped properties on the session are prefixed
with javax.portlet.[PORTLET_ID] and there is no way in JSR-168 to obtain
the portlet id for the portlet instance. In MANY implementations this
is the same as the namespace, but this is in no way guaranteed by
JSR-168. This makes it impossible for all JSR-168 containers to support
a "servlet" type fallback.
That being said, I have successfully used the "servlet" technique on
Pluto and WebSphere (when not running through WSRP) by using the
namespace as the portlet id, but I would rather wait for JSR-286 to come
out (which is looking like it will support BOTH an in-protocol resource
requests AND a special XMLHttpRequest handler) in order to enable AJAX
in a container agnostic fashion.
Do you agree?
Scott
Martin Marinschek wrote:
Hi Scott,
sorry for the late response - I've been on vacation the last week.
Yeah, your proposal seems definitely interesting. The bridge could
certainly be a sub-project of MyFaces.
I was thinking about why PPR wouldn't be supported in a portlet
environment - is that due to the fact that the portlet server itself
would need to know about PPR, and so it is entirely impossible to do
this in portlet servers?
I envision it might be possible to have the client-side AJAX library
post back to a servlet instead of the portlet - would that be possible
or not, wdyt?
regards,
Martin
