You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Scott O'Bryan <da...@gmail.com> on 2007/06/11 19:05:54 UTC
Re: Trinidad and Portlets
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 <da...@gmail.com> 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
>>
>>
>
>
Re: [Trinidad] Portlet Skinning
Posted by Scott O'Bryan <da...@gmail.com>.
Have we tried logging a bug against the 1.2 ref impl that simply says
clientId's are not namespaced and see where that gets us? :)
Scott O'Bryan wrote:
> Thomas,
>
> Jeanne is probably better to answer this question but I'll take a
> quick stab at it. Right now we have a portlet skin in Trinidad. It
> defers to the JSR-168 style classes where appropriate and then adds
> the additional styles we need. I believe it's based off the simple
> skin. It does okay, but there is certainly potential for things to
> look wierd.
>
> Trinidad is also working to support a mechanism whereby the Portal
> could optionally define or provide a skin for the Trinidad portlet to
> use. We're still working out the details on this though at this time
> it has some issues. A portal would be expected to implement these
> extensions if they wanted to support this behavior. Here is what the
> idea is though... A portal "written" using Trinidad and all of it's
> Trinidad Portlets would use the same skin. Or, a portal developer
> could develop a trinidad skin that correctly merges into their portal
> styling but with more "eye-candy".
>
> The pieces are starting to come together, but they are not quite there
> yet.
>
> Scott
>
>
> Thomas Spiegl wrote:
>> 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 <da...@gmail.com> 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 <da...@gmail.com> 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
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>
>>
>
>
[Trinidad] Portlet Skinning (was: Trinidad and Portlets)
Posted by Scott O'Bryan <da...@gmail.com>.
Thomas,
Jeanne is probably better to answer this question but I'll take a quick
stab at it. Right now we have a portlet skin in Trinidad. It defers to
the JSR-168 style classes where appropriate and then adds the additional
styles we need. I believe it's based off the simple skin. It does
okay, but there is certainly potential for things to look wierd.
Trinidad is also working to support a mechanism whereby the Portal could
optionally define or provide a skin for the Trinidad portlet to use.
We're still working out the details on this though at this time it has
some issues. A portal would be expected to implement these extensions
if they wanted to support this behavior. Here is what the idea is
though... A portal "written" using Trinidad and all of it's Trinidad
Portlets would use the same skin. Or, a portal developer could develop
a trinidad skin that correctly merges into their portal styling but with
more "eye-candy".
The pieces are starting to come together, but they are not quite there yet.
Scott
Thomas Spiegl wrote:
> 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 <da...@gmail.com> 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 <da...@gmail.com> 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
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>
>
Re: Trinidad and Portlets
Posted by Thomas Spiegl <th...@gmail.com>.
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 <da...@gmail.com> 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 <da...@gmail.com> 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
Re: Trinidad and Portlets
Posted by Scott O'Bryan <da...@gmail.com>.
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 <da...@gmail.com> 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
>>>
>>>
>>
>>
>
>