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 2009/04/21 10:23:10 UTC
[TRINIDAD] Portlet 2.0 compatibility
Hey everyone,
I completed a migration to Trinidad to allow it to work with either
Portlet 1.0 or Portlet 2.0. Portlet 2.0 containers will support AJAX.
So here is my problem. In order to support extra functionality of
Portlet 2.0, I need to compile against a Portlet 2.0 container. Most of
the code does a graceful fallback at runtime, but Trinidad has a number
of custom wrapper objects that we were using for Portlet 1.0 which
implement the Portlet Request/Response objects. Portlet 2.0 extends
these objects and on some methods returns a ResourceURL which is a class
that didn't exist in Portlet 1.0.
To make a long story short, in order for us to support both Portal
containers we'll need these wrappers to be compiled using Portlet 1.0
while the rest of the code in Trinidad needs to be compiled using
Portlet 2.0.
As such I think we have several options for handling this:
1. Force someone to add an extra jar as a "portlet compatibility
layer". We would have 1 jar for portlet 1.0 compatibility and another
for portlet 2.0 compatibility. Then, you just include the proper
portlet compatibility jar and you're off.
2. We could support portlet 2.0 out of the box and force portlet 1.0
compatibility to use a special jar. This would mean that only 1.0
containers would need the extra jar to be added to their web-inf.lib.
It is a LOT harder to support portlet 1.0 by default and add a jar for
portlet 2.0 because of the way the architecture works. Possible, but hard.
Please let me know if either of these options sounds acceptable for
Trinidad...
Scott
Re: [TRINIDAD] Portlet 2.0 compatibility
Posted by michael freedman <mi...@oracle.com>.
The TrinidadDemo that is included in TrinidadExample distribution
download on the MyFaces/Trinidad site runs against the current version
of the Portlet 2.0 bridge. There are some problems -- mostly related to
lack of Trinidad pop-up support in the portlet environment which the
example relies on a bit and seemingly some issue related to the use of a
simple portlet standard set of stylesheet classes but in all you should
get what you want.
-Mike-
Hiren Sheth wrote:
> Hi
> My name is Hiren Sheth.
> i am new in Trinidad. i used Tomhawk before. i want to use Trinidad in my
> websphere portal6.1 environment. with Portlet 2.0. can you please tell me
> where can i found the simple demo war file?
> or can u send me a simple demo which works in my portal environment.
>
>
> Scott O'Bryan wrote:
>
>> Hey everyone,
>>
>> I completed a migration to Trinidad to allow it to work with either
>> Portlet 1.0 or Portlet 2.0. Portlet 2.0 containers will support AJAX.
>>
>> So here is my problem. In order to support extra functionality of
>> Portlet 2.0, I need to compile against a Portlet 2.0 container. Most of
>> the code does a graceful fallback at runtime, but Trinidad has a number
>> of custom wrapper objects that we were using for Portlet 1.0 which
>> implement the Portlet Request/Response objects. Portlet 2.0 extends
>> these objects and on some methods returns a ResourceURL which is a class
>> that didn't exist in Portlet 1.0.
>>
>> To make a long story short, in order for us to support both Portal
>> containers we'll need these wrappers to be compiled using Portlet 1.0
>> while the rest of the code in Trinidad needs to be compiled using
>> Portlet 2.0.
>>
>> As such I think we have several options for handling this:
>>
>> 1. Force someone to add an extra jar as a "portlet compatibility
>> layer". We would have 1 jar for portlet 1.0 compatibility and another
>> for portlet 2.0 compatibility. Then, you just include the proper
>> portlet compatibility jar and you're off.
>>
>> 2. We could support portlet 2.0 out of the box and force portlet 1.0
>> compatibility to use a special jar. This would mean that only 1.0
>> containers would need the extra jar to be added to their web-inf.lib.
>>
>> It is a LOT harder to support portlet 1.0 by default and add a jar for
>> portlet 2.0 because of the way the architecture works. Possible, but
>> hard.
>>
>> Please let me know if either of these options sounds acceptable for
>> Trinidad...
>>
>>
>> Scott
>>
>>
>>
>
>
Re: [TRINIDAD] Portlet 2.0 compatibility
Posted by Hiren Sheth <hs...@sperianprotection.com>.
Hi
My name is Hiren Sheth.
i am new in Trinidad. i used Tomhawk before. i want to use Trinidad in my
websphere portal6.1 environment. with Portlet 2.0. can you please tell me
where can i found the simple demo war file?
or can u send me a simple demo which works in my portal environment.
Scott O'Bryan wrote:
>
> Hey everyone,
>
> I completed a migration to Trinidad to allow it to work with either
> Portlet 1.0 or Portlet 2.0. Portlet 2.0 containers will support AJAX.
>
> So here is my problem. In order to support extra functionality of
> Portlet 2.0, I need to compile against a Portlet 2.0 container. Most of
> the code does a graceful fallback at runtime, but Trinidad has a number
> of custom wrapper objects that we were using for Portlet 1.0 which
> implement the Portlet Request/Response objects. Portlet 2.0 extends
> these objects and on some methods returns a ResourceURL which is a class
> that didn't exist in Portlet 1.0.
>
> To make a long story short, in order for us to support both Portal
> containers we'll need these wrappers to be compiled using Portlet 1.0
> while the rest of the code in Trinidad needs to be compiled using
> Portlet 2.0.
>
> As such I think we have several options for handling this:
>
> 1. Force someone to add an extra jar as a "portlet compatibility
> layer". We would have 1 jar for portlet 1.0 compatibility and another
> for portlet 2.0 compatibility. Then, you just include the proper
> portlet compatibility jar and you're off.
>
> 2. We could support portlet 2.0 out of the box and force portlet 1.0
> compatibility to use a special jar. This would mean that only 1.0
> containers would need the extra jar to be added to their web-inf.lib.
>
> It is a LOT harder to support portlet 1.0 by default and add a jar for
> portlet 2.0 because of the way the architecture works. Possible, but
> hard.
>
> Please let me know if either of these options sounds acceptable for
> Trinidad...
>
>
> Scott
>
>
--
View this message in context: http://www.nabble.com/-TRINIDAD--Portlet-2.0-compatibility-tp23151308p25578046.html
Sent from the My Faces - Dev mailing list archive at Nabble.com.
Re: [TRINIDAD] Portlet 2.0 compatibility
Posted by Kito Mann <ki...@virtua.com>.
2009/4/21 Scott O'Bryan <da...@gmail.com>
> Yes I agree Matthias. Anyone else have a contrary opinion?
I agree as well.
>
>
> Matthias Wessendorf wrote:
>
>> On Tue, Apr 21, 2009 at 10:23 AM, Scott O'Bryan <da...@gmail.com>
>> wrote:
>>
>>
>>> Hey everyone,
>>>
>>> I completed a migration to Trinidad to allow it to work with either
>>> Portlet
>>> 1.0 or Portlet 2.0. Portlet 2.0 containers will support AJAX.
>>>
>>> So here is my problem. In order to support extra functionality of
>>> Portlet
>>> 2.0, I need to compile against a Portlet 2.0 container. Most of the code
>>> does a graceful fallback at runtime, but Trinidad has a number of custom
>>> wrapper objects that we were using for Portlet 1.0 which implement the
>>> Portlet Request/Response objects. Portlet 2.0 extends these objects and
>>> on
>>> some methods returns a ResourceURL which is a class that didn't exist in
>>> Portlet 1.0.
>>>
>>> To make a long story short, in order for us to support both Portal
>>> containers we'll need these wrappers to be compiled using Portlet 1.0
>>> while
>>> the rest of the code in Trinidad needs to be compiled using Portlet 2.0.
>>>
>>> As such I think we have several options for handling this:
>>>
>>> 1. Force someone to add an extra jar as a "portlet compatibility layer".
>>> We
>>> would have 1 jar for portlet 1.0 compatibility and another for portlet
>>> 2.0
>>> compatibility. Then, you just include the proper portlet compatibility
>>> jar
>>> and you're off.
>>>
>>> 2. We could support portlet 2.0 out of the box and force portlet 1.0
>>> compatibility to use a special jar. This would mean that only 1.0
>>> containers would need the extra jar to be added to their web-inf.lib.
>>>
>>>
>>
>> Portlet 2.0 is the "latest, greatest" portlet technology, so I am in fav
>> of this. If one wants (or has) to use older technology, adding an
>> extra jar to the web-inf/lib is not the end of the world.
>>
>>
>>
>>> It is a LOT harder to support portlet 1.0 by default and add a jar for
>>> portlet 2.0 because of the way the architecture works. Possible, but
>>> hard.
>>>
>>> Please let me know if either of these options sounds acceptable for
>>> Trinidad...
>>>
>>>
>>
>> Option 2) sounds like a good one.
>> I guess that's what you prefer as well, right ?
>>
>> -Matthias
>>
>>
>>
>>> Scott
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
Re: [TRINIDAD] Portlet 2.0 compatibility
Posted by Scott O'Bryan <da...@gmail.com>.
Yes I agree Matthias. Anyone else have a contrary opinion?
Matthias Wessendorf wrote:
> On Tue, Apr 21, 2009 at 10:23 AM, Scott O'Bryan <da...@gmail.com> wrote:
>
>> Hey everyone,
>>
>> I completed a migration to Trinidad to allow it to work with either Portlet
>> 1.0 or Portlet 2.0. Portlet 2.0 containers will support AJAX.
>>
>> So here is my problem. In order to support extra functionality of Portlet
>> 2.0, I need to compile against a Portlet 2.0 container. Most of the code
>> does a graceful fallback at runtime, but Trinidad has a number of custom
>> wrapper objects that we were using for Portlet 1.0 which implement the
>> Portlet Request/Response objects. Portlet 2.0 extends these objects and on
>> some methods returns a ResourceURL which is a class that didn't exist in
>> Portlet 1.0.
>>
>> To make a long story short, in order for us to support both Portal
>> containers we'll need these wrappers to be compiled using Portlet 1.0 while
>> the rest of the code in Trinidad needs to be compiled using Portlet 2.0.
>>
>> As such I think we have several options for handling this:
>>
>> 1. Force someone to add an extra jar as a "portlet compatibility layer". We
>> would have 1 jar for portlet 1.0 compatibility and another for portlet 2.0
>> compatibility. Then, you just include the proper portlet compatibility jar
>> and you're off.
>>
>> 2. We could support portlet 2.0 out of the box and force portlet 1.0
>> compatibility to use a special jar. This would mean that only 1.0
>> containers would need the extra jar to be added to their web-inf.lib.
>>
>
> Portlet 2.0 is the "latest, greatest" portlet technology, so I am in fav
> of this. If one wants (or has) to use older technology, adding an
> extra jar to the web-inf/lib is not the end of the world.
>
>
>> It is a LOT harder to support portlet 1.0 by default and add a jar for
>> portlet 2.0 because of the way the architecture works. Possible, but hard.
>>
>> Please let me know if either of these options sounds acceptable for
>> Trinidad...
>>
>
> Option 2) sounds like a good one.
> I guess that's what you prefer as well, right ?
>
> -Matthias
>
>
>> Scott
>>
>>
>
>
>
>
Re: [TRINIDAD] Portlet 2.0 compatibility
Posted by Matthias Wessendorf <ma...@apache.org>.
On Tue, Apr 21, 2009 at 10:23 AM, Scott O'Bryan <da...@gmail.com> wrote:
> Hey everyone,
>
> I completed a migration to Trinidad to allow it to work with either Portlet
> 1.0 or Portlet 2.0. Portlet 2.0 containers will support AJAX.
>
> So here is my problem. In order to support extra functionality of Portlet
> 2.0, I need to compile against a Portlet 2.0 container. Most of the code
> does a graceful fallback at runtime, but Trinidad has a number of custom
> wrapper objects that we were using for Portlet 1.0 which implement the
> Portlet Request/Response objects. Portlet 2.0 extends these objects and on
> some methods returns a ResourceURL which is a class that didn't exist in
> Portlet 1.0.
>
> To make a long story short, in order for us to support both Portal
> containers we'll need these wrappers to be compiled using Portlet 1.0 while
> the rest of the code in Trinidad needs to be compiled using Portlet 2.0.
>
> As such I think we have several options for handling this:
>
> 1. Force someone to add an extra jar as a "portlet compatibility layer". We
> would have 1 jar for portlet 1.0 compatibility and another for portlet 2.0
> compatibility. Then, you just include the proper portlet compatibility jar
> and you're off.
>
> 2. We could support portlet 2.0 out of the box and force portlet 1.0
> compatibility to use a special jar. This would mean that only 1.0
> containers would need the extra jar to be added to their web-inf.lib.
Portlet 2.0 is the "latest, greatest" portlet technology, so I am in fav
of this. If one wants (or has) to use older technology, adding an
extra jar to the web-inf/lib is not the end of the world.
>
> It is a LOT harder to support portlet 1.0 by default and add a jar for
> portlet 2.0 because of the way the architecture works. Possible, but hard.
>
> Please let me know if either of these options sounds acceptable for
> Trinidad...
Option 2) sounds like a good one.
I guess that's what you prefer as well, right ?
-Matthias
>
>
> Scott
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf