JSF in a portlet has never been this easy!

We just released JBoss Portlet Bridge Beta3 along with some good supporting documentation and example projects. See the documentation for full details.

The majority of the code written for this release is internal to the portlet bridge project (refactoring, 301 spec updates and enhancements, bug fixes...). The next release (Beta 4 - early Sept) will be huge for the portlet bridge for the following reasons:

• The EG is currently discussing a lot of significant clarifications and improvements. For example, working with the JSF 2.0 EG to allow certain needs and working on Portlet 2.0 areas of the spec.
  
• There is currently a lot of discussion about navigation between portlet modes. Once this is nailed down in the spec, we will implement it.
  
• The Portlet 1.0 version should be getting close to public review.

Other than the spec related reasons for release schedule, we must work in unison with the latest Seam and RichFaces relases, make sure that we squash any bugs concerning the 3 integration points, handle features/improvements/refactorings, and try to test and give feedback to the 301 EG. And, of course we can't forget about JBoss Portal 2.7+!

There are soo many cool things going on right now within the JBoss Portal project, I would like to tell you about all of them but then this post wouldn't be about JBPB anymore. Just stay tuned to this blog...

With that said, here are a few tips for JSF portlet developers that concern this release:

• Namespacing
  In situations where you need to use the id of an element in your JSF/xhtml markup, you would normally see something like 'form1:myBtn' in the rendered markup. But now with the bridge namespacing you will see something similar to:

  jbpns_2fdefault_2fNews_2fStories_2fStoryTemplateWindow12snpbj:_viewRoot:form1:myBtn

  To overcome this, you can use the following expression in your Facelets page to prepend the namespace to your javascript code:

  document.getElementById('#{facesContext.externalContext.response.namespace}the_rest_of_JSF_ID

  since this uses the portletResponse, once you try to view this page on the servlet application side, you will get an exception. To avoid this, you need to check for the type of response in your backing bean and assign a new "safe" namespace variable for the UI.
  
  
• Excluding Attributes from the Bridge Request Scope
  When your application uses request attributes on a per request basis and you do not want that particular attribute to be managed in the extended bridge request scope, you must use the following configuration in your faces-config.xml. Below you will see that any attribute namespaced as foo.bar or any attribute beginning with foo.baz(wildcard) will be excluded from the bridge request scope and only be used per that application's request.
  

  
  <application>
       <application-extension>
           <bridge:excluded-attributes>
               <bridge:excluded-attribute>foo.bar</bridge:excluded-attribute>
               <bridge:excluded-attribute>foo.baz.*</bridge:excluded-attribute>
           </bridge:excluded-attributes>
       </application-extension>
      </application>

  
  Or you can use the javax.portlet.faces.annotation.ExcludeFromManagedRequestScope annotation to accomplish the same thing.
  

For more information on this release or to find out more about the project, visit the project page.