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/13 20:57:05 UTC

Re: [Trinidad] Portlet Skinning

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
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>
>>
>
>