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 <[email protected]> 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
