What about trinidad skinning in a portlet environment? Is there a solution for adding the necessary link element to the html header?
Thomas On 6/11/07, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
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 >>> >>> >> >> > >
-- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
