Working with portlet technology is often discredited for it’s seemingly complex API and development hoops one must jump through. But if you have worked on a portlet project for a considerable amount of time, and then jump back to a servlet based project, you have a feeling that life just got easier.
This is all within the context of which servlet-based framework you might be working with, but overall things are a bit easier when dealing with one request and response.

What if you didn’t have to worry about portlet development gotchas anymore? What if you could develop portlets with the ease and hassle free life that you have with good ol’ servlets? Well, I’m here to tell you that this can be partly achieved with JSR-301 portlet bridge technology.

I encourage (actually I dare you) to those who have never even touched a portal to take the JBoss Portlet Bridge for a test drive. It takes 1 download (GateIn bundled with JBoss) and one maven archetype to get started. You can choose from any combination of plain JSF, Richfaces, and Seam with
mvn archetype:generate -DarchetypeCatalog=http://bit.ly/jbossportletbridge from the command line.

If you run into any questions or special usecases, we have 7 videos which demo and walk you through just about anything you could think up.

And for those that like to have a refcard by their side, you can get all the information you need about the story of portal technology and configuration drill downs here:

From “Mastering Portals with a Portlet Bridge” DZone Refcard:
“A portlet bridge allows you to run application frameworks like JSF in a portal environment without needing to know anything about the underlying portlet API or portlet concepts.”

And if all that wasn’t enough, I will be giving a 50 minute talk at JBoss World titled "Making Portals Cool: The Compelling Advantages of a Portlet Bridge" where you can come and personally track me down and specifically tell me about your problems, pains, or happiness with the project or the world in general JBoss World will be located in Boston from May 3–6.
I think early bird pricing ends this Friday (April 8th), so you better hurry if you want to save a little cash.

By default, the JSR-301/329 portlet bridge manages your navigation history during PortletMode changes. Meaning that, if the user is clicking around in the portlet "view" mode and decides to click the help icon (help mode), the user should be directed to the place where he left off in help mode - and vice versa. Of course, if the user has never been in help mode during the current session, he will go to the default help viewId.

Why use portlet modes instead of javascript widgets?

First I would like to give you a little justification of the beauty of this feature. Some people will argue the point of "Why do you need different modes like, Help and Edit?", when you could add some cool "javascript of the week" that would dynamically display what you intended to present in one of the given modes. Well, you could develop your interactions either way but it really isn't a question of why. It's a question of "How?". How do you want users to interact with your applications? And since you have already made the decision to invest in a portal solution, why not use the features that are built in and that stay consistent across the entire UI? Any UI Developer or Interaction Designer will tell you that adding cool javascript widgets adds another layer of complexity and maintenance, thus adding to developer time and bottom line ROI. In addition, when you develop any servlet based application to work within a portal environment, you are properly separating your concerns when you use these modes (without even realizing it in most cases). You are presenting distinguished flows for different trains of thought and making it easier for users to accomplish the task at hand.

The Usecase

Ok, off the soap box and onto the use case. Let's say your user is filling out a beloved expense report. It's probably one of his top 5 things that he loves most about his job Seriously, his IT department just launched a new intranet portal using the latest and greatest GateIn platform and they completely revamped their old Seam application that was used for expense report submissions to run as a portlet.

So, Joe User starts to fill out his expense report in a 6 step wizard. He gets through the first few steps and arrives at a screen asking for his cost center and other details that he has no idea about. Behold the beautiful question mark(help mode) in the top right hand corner of his portlet window! Joe clicks the button and sees exactly the information he needs, and he also sees a link at the bottom of the screen that says “add this to the form”. Joe clicks it, and is returned to his expense report with all of the details pre-populated in his form. Not only was the help screen easy to understand, but it was just a basic .xhtml page that can be templated and maintained by any UI developer without any special javascript kung fu.

The next screen (in view mode), asks him to itemize each receipt and expense. Since he took a trip to Euro-land, all of his receipts are in Euros. And since he recently just got his internet privileges suspended (and no, he won't tell us why) he has no idea what the current conversion rates are. Once again, Joe clicks the help button and is presented with a clickable table of currency options. Not only that, but the finance department has placed some important notifications on this page via CMS. Joe reads the notifications and clicks on "Euros" and is taken back to a modified input table that auto converts his itemized euro(€) values to USD($).

As you can see, these are just random examples of possibilities of detecting PortletMode changes with GateIn, Seam, and RichFaces. The real beauty of this code is detecting the actual mode change and providing contextual help. This is not currently provided by the bridge as a default behavior, so here is the code to do it:

The Code

First create a simple session bean with the following code. This will allow us to get a handle on the current mode.

 private String mode;

 public String getMode()
 {
 Object responseObject = FacesContext.getCurrentInstance().getExternalContext().getRequest();
 if (responseObject instanceof RenderRequest) {


 RenderRequest renderRequest = (RenderRequest)responseObject;
 if(renderRequest.getPortletMode().toString().equals(mode)){
 mode = null;
 }else{
 mode = renderRequest.getPortletMode().toString();
 }


 }
 return mode;
 }

 public String getFromView() {
 PortletSession portletSession = (PortletSession)FacesContext.getCurrentInstance().getExternalContext().getSession(false);
 String viewId = (String)portletSession.getAttribute("javax.portlet.faces.viewIdHistory.view");


 viewId = viewId.substring(0,viewId.indexOf("?"));
 return viewId;
 }

 public void setMode(String mode)
 {


 this.mode = mode;
 }

Next add something similar to this in pages.xml

 
 <page view-id="/expenseWizard/*" action="#{mode.getMode()}"> 
 <navigation> 
 <rule if-outcome="help" if="#{mode.getFromView() == '/expenseWizard/step3.xhtml'}"> 
 <render view-id="/helpPages/step3help.xhtml"/> 
 rule> 
 <rule if-outcome="help" if="#{mode.getFromView() == '/expenseWizard/step4.xhtml'}"> 
 <render view-id="/helpPages/step4help.xhtml"/> 
 rule> 
 navigation> 
 page> 
 

I dedicated some time this weekend to creating a fully functional demo with OpenSocial, Shindig and JBoss Portal. It seems like OpenSocial has a lot of new supported platforms coming out in 0.8 and the future is looking promising. Here is a bullet list to summarize what I found:

• Documentation is scarce when you want to roll you own OS container via Shindig
• Luckily Chris Schalk did a good job providing some documentation on getting persistence setup on a mysql db
• Unfortunately, due to the bleeding edge of this technology, some of (the few) demos that exist don't work with today's Shindig trunk
• I was able to quickly learn Google widgeting and am on my way to being a "widget master"
• Next on the list is to mess around with Google Data APIs in OpenSocial Apps
• The transition/integration of Shindig into a standard webapp/portlet was a huge pita. Too many hard coded servlet context in .js files.
• It seems like (for now) you really need to be into the Orkut scene to leverage current social users. Myspace is something I try to stay away from, and I was really hoping to see some LinkedIn stuff but was let down.

This is definitely the way portals are headed and I guess I will try to muster up the energy to write an article once the kinks are worked out of my demo. I would also like to do something cool with the collected social data inside of a portal environment (like notifications of other user activities, posts, changes, etc...). I used the JBoss Portlet Bridge Richfaces project/archetype to create the demo. The bridge makes it incredibly easy to do stuff like this because of having things working on both the servlet and portlet side.

InfoQ just published the first in a series of 3 articles for the JBoss Portlet Bridge. The author of this series did an unbelievable job. I could write a whole post about how great his article(s) are, but I would hate to loose sight of this post topic :-) heh - just kidding... the author is me!

This first part is about basic JSF development with an easy to follow tutorial and real world development tips. The next one will be about RichFaces and the final (about Seam) will be published right after the release of Beta 4 in early September.

Enjoy!
http://www.infoq.com/articles/jsf-ajax-seam-portlets-pt-1

http://www.infoq.com/articles/jsf-ajax-seam-portlets-pt-2

**Update - See this article for more info.