Wednesday, November 4, 2009

Standard Portlet Markup and CSS Classes

After reading Andy's slides on Annotation Driven Portlet Development with Spring, I ran across a post from Andy written earlier in the year called The Perfect Portlet Markup which provided an example of what he thought would be great markup, but was also mostly an attempt get people talking about what constitutes the perfect portlet markup.

Similar topics have been brought up on the Jasig lists (jasig-ui, portlet-dev), not even aiming for perfection, but at least some standardization, even if it is just for uPortal portlets.

First off, everyone should first read JSR-168 and JSR-286. These are the only standards I know about as of time of writing that refer to how (those types of) portlets should be written.

I shortened the styles defined in JSR-168 and JSR-286 PLT.C into the Portlet Styling Quick Reference while trying to understand these and use them. However, I learned in the process that it is highly disputed that the CSS classes/styles that they define in PLT.C are of much use.

In uPortal portlets hosted at Jasig up to date of writing, you’ll see a lot of non-semantic markup (basically everything is a div, which is not good) peppered with minimal usage of the PLT.C classes. This is not surprising, since even the WeatherPortlet provided by Sun when it introduced the specification doesn't use the classes defined in PLT.C.

I like that Andy is trying to nail down a standard. I’ve tried to also, and I know that others more talented than me with UI continue to try. But, the fact is that each portal’s portlets are going to be different and there is not really a good way to write a portlet that will render well in every (or even most) portal environments because of what many would argue to be the awful and outdated UI and CSS definitions in JSR-168 and JSR-286.

In uPortal 3.1, they’ve latched onto the FSS (Fluid Skinning System) which is non-standard across portals in an attempt to at least have some standardization in UI, even if it is only within uPortal and others that use FSS.

uPortal 3.1 also introduced a webapp to serve UI resources, which will also possibly make uPortal portlets a little less standard and less portable to other portal servers, even though image/javascript/CSS resource sharing is a good idea.

Something else to consider is that many have been using or are starting to use proxy portlets that pull in content served by Rails apps, PhP, etc. This could be the direction of things to come unless efforts to integrate other more dynamic languages into the portals themselves take hold.

No comments: