Hey Martin,
One thing we "could" look at if 286 won't be released for a while is an
extension to Trinidad to support a "plugable" ppr system. This
would be
a lot of work but we could have plugins for various portals that would
allow us to enable PPR. If a plugin was not available for a particular
portal then we fall back to no ppr. Still, we really need a
functioning
bridge before we can test this effectively so I totally agree with your
comment about getting the bridge done first. Who knows, maybe 286 will
be released by the time we get everything put together.
Scott
Scott O'Bryan wrote:
> Moving this to Dev list since it belongs there... :)
>
> Martin Marinschek wrote:
>> Hi Scott,
>>
>> interesting, thanks for the further clarification. I see the
problems
>> very clearly now. Well then - let's start off this portlet
bridge, and
>> see where it brings us to!
>>
>> regards,
>>
>> Martin
>>
>> On 6/11/07, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
>>> 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
>>>
>>>
>>
>>
>
>
