So I came across this link in Google:  TWITTER BOOTSTRAP FOR ADOBE CQ5.5.  I had no idea what a Twitter Bootstrap was, so off to the research mission!

Twitter Bootstrap is described by the developers as “Simple and flexible HTML, CSS, and Javascript for popular user interface components and interactions.”  That sounded interesting, so I dug further.  Bootstrap is based on HTML5, CSS3, a 12-column grid, some jQuery plug-ins to create a framework for building a fully responsive, run on any browser website.  What really caught my eye was that Bootstrap was built by and for nerds.

Bootstrap sounded pretty interesting, so I continued my research mission.  Next I found out that Bootstrap was the most watched project on GitHub back in March.  It is still generating lots of interest.  Its also Open Source, so anybody can participate in building out Bootstrap.  If you want to see samples of sites built using Bootstrap, you can see some on Tumblr or go to the Bootstrap page.

Back to Adobe CQ 5.5. So what does Bootstrap do for Adobe CQ 5.5?  Well officially nothing.  Adobe is not building Bootstrap sites with CQ 5.5.  But, a company called Headwire has built an integration for CQ .5.5 to use Bootstrap for the page framework.  So using the Bootstrap framework and CQ 5.5, you can easily build sites that use responsive design techniques, are instantly browser compatible, and can take advantage of jQuery, slideshows, tabs, button bars, etc.  Headwire also includes a drag and drop editor to create templates based on Bootstrap.  By creating templates you can allow your authors to fill in the templates without having to understand all that HTML and responsive stuff.

Yes, you can build these features into CQ 5.5 yourself, but why?  It seems to me that Bootstrap is a great standalone product, but when combined with Adobe CQ 5.5, you have an even better experience.

In addition, while the JSR 286 spec has been out since 2008, it took the Portal vendors some time to update their Portal Servers to support the new standard.  Now all the major vendors support JSR 286 on their Portal server.  Even many content management systems are supporting JSR 286 portlets on their systems.

Also known as Portlet 2.0, JSR 286 builds upon the first portlet standard, JSR 168, so it has all the features of the first standard plus more:

• Event handling
• Shared parameters
• Resource addressing
• Alignment with WSRP 2.0

If you want a really in depth discussion of these new features, take a look at this article on developerWorks: What’s new in the Java Portlet Specification V2.0 (JSR 286)?  It’s been three years since the JSR 286 spec came out, so its hardly new.

So when should you code to JSR 286 or when should you code to JSR 168?  Here are my thoughts:

• If you are using the latest version of a mainstream portal, code to JSR 286.  Liferay 6, WebSphere Portal 7, Oracle WebCenter 11.1.1.14, JBoss, Adobe CQ5, OpenText, Apache all support JSR 286.
• If you aren’t sure what spec your portal server supports, code to JSR 168.  If you have older versions of Liferay (prior to V5), WebSphere Portal (prior to V6), Oracle WebCenter (prior to v11), you don’t have a choice – JSR 168 is the only supported spec.
• Your development environment may dictate whether you use JSR 286 or not.  In IBM’s Rational Developer, for example, it can’t create a JSR 286 portlet using Struts.  You can build a JSR 168 portlet using Struts, though.

So my bottom line is this: code to the JSR 286 standard when you can and only use JSR 168 when forced to.