Hello,

actually, I'm using Trinidad with a non JSR-301 bridge (even though it requires some "workarounds" ..). Isn't it possible to make this bugfix optional, for example by introducing a Jsr301StateManagerImpl?

regards,
Bernhard

On 02/20/2008 +0100,
"Scott O'Bryan" <[EMAIL PROTECTED]> wrote:
There is no compatibility for Trinidad with non JSR-301 bridges.

Scott

Bernhard Huemer wrote:
Hello,

additionally I'm concerned whether this breaks compatibility with current (non JSR-301) portlet bridges ..

regards,
Bernhard

On 02/20/2008 +0100,
"Matthias Wessendorf" <[EMAIL PROTECTED]> wrote:
also...
doesn't this belong to the 12x trunk ?
My understanding is that the JSR 301 is kind of depending on JSF 1.2

-M

On Feb 20, 2008 3:31 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
Hi,

       <dependency>
+        <groupId>org.apache.myfaces.portlet-bridge</groupId>
+        <artifactId>portlet-bridge-api</artifactId>
+        <version>1.0.0-alpha</version>
+        <scope>provided</scope>
+      </dependency>

I wonder fi is the right scope.
Pretty much all containers don't really ship that JAR.

-M



+
+      <dependency>
         <groupId>org.apache.myfaces.core</groupId>
         <artifactId>myfaces-api</artifactId>
         <version>${myfaces.version}</version>

Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml
URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=629242&r1=629241&r2=629242&view=diff ==============================================================================
--- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original)
+++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Tue Feb 19 13:35:43 2008
@@ -206,6 +206,11 @@
     </dependency>

     <dependency>
+      <groupId>org.apache.myfaces.portlet-bridge</groupId>
+      <artifactId>portlet-bridge-api</artifactId>
+    </dependency>
+
+    <dependency>
       <groupId>org.apache.myfaces.trinidad</groupId>
       <artifactId>trinidad-build</artifactId>
     </dependency>

Modified: myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java?rev=629242&r1=629241&r2=629242&view=diff ============================================================================== --- myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java (original) +++ myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java Tue Feb 19 13:35:43 2008
@@ -51,6 +51,11 @@

 import java.io.IOException;

+import javax.portlet.faces.annotation.PortletNamingContainer;
+import javax.portlet.faces.component.PortletNamingContainerUIViewRoot;
+
+import org.apache.myfaces.trinidad.util.ExternalContextUtils;
+
 /**
  * StateManager that handles a hybrid client/server strategy:  a
  * SerializedView is stored on the server, and only a small token
@@ -966,6 +971,17 @@
         UIViewRoot newRoot = (UIViewRoot)
fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);

+ //This code handles automatic namespacing in a JSR-301 environment
+        if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
+        {
+          //To avoid introducing a runtime dependency on the bridge,
+ //this method should only be executed when we have a portlet
+          //request.  If we do have a portlet request then the bridge
+          //should be available anyway.
+          newRoot = _getPortletRoot(newRoot);
+        }
+
+
// must call restoreState so that we setup attributes, listeners,
         // uniqueIds, etc ...
         newRoot.restoreState(fc, viewRootState);
@@ -984,6 +1000,37 @@

       return null;
     }
+
+    /**
+ * This should only be executed if we are currently in a Portlet Request. + * If executed, this method introduces a dependency on the JSR-301 bridge + * which is required for Trinidad to run in a portal environment. If this + * method is not run, then the bridge api's remain optional at runtime.
+     *
+     * This method checks the current UIViewRoot to see if it is a
+ * PortletNamingContainer. If it is, then this class simply returns the + * UIViewRoot. If it does not then the current UIViewRoot is used to create
+     * a new PortletNamingContainerUIViewRoot.
+     */
+    private UIViewRoot _getPortletRoot(UIViewRoot root)
+    {
+      Class<? extends UIViewRoot> rootClass = root.getClass();
+ //If the current root is not the real UIViewRoot object in faces then + //is no need to escape it. It is assumed it handles namespacing on its + //own. This is the same as the logic in the JSR-301 Bridge spec.
+      if(rootClass == UIViewRoot.class)
+      {
+ _LOG.fine("Creating PortletUIViewRoot for use with the portal.");
+        root = new PortletNamingContainerUIViewRoot(root);
+      }
+
+ //TODO: Do we need a warning here if the view root is not annotated + //properly? This could happen if another renderkit is involved and does + //not correctly implement JSR-301. This will NOT be an issue in Trin only
+      //environments.
+      return root;
+    }
+
   }







--
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org








Reply via email to