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
