Long-time Steering Committee Member, Ron DiFrango (CapTech Ventures) announced that he would step down.
It always bothered me that the JSR168 <portlet:actionURL /> and <portlet:renderURL /> tags didn’t encode their HTML character entities. The lack of encoding causes your HTML 4 or XHTML 1 markup to fail automated validation. After flipping through a bit more of the JSR286 spec, it mentions that in JSR168 “the behavior in regards to XML escaping URLs written by the tag library was undefined” 1. So, some vendors may have encoded and some may not have (as of 2.7 JBoss Portal, for example, does not).
Well, it turns out that the JSR286 expert group noticed that and accounted for it. Section 10.4.1 defines a new container runtime option: javax.portlet.escapeXml. The option causes portlet URLs to be escaped and is true by default. This is primarily for backwards compatibility so that older portlets that dependended on unencoded URLs will work on a portlet 2.0 container.
For example, you wouldn’t want to call the following:
Because the URL above would be encoded, your ‘id’ parameter wouldn’t be passed along properly.
It’s always nice to see this kind of improvement in the spec; hope this is helpful for you!
I thought I’d throw together a quick precursor to another post I plan on finishing in the next few days. This post is about portlets - or, how to structure the HTML markup for a JSR168/JSR286 portlet, to be more specific.
I’ve worked on theming portal user interfaces for a few years now, primarily on IBM WebSphere Portal and JBoss Portal. On WebSphere, you develop what’s called a ’skin’ - where the markup for a given portlet lives. JBoss has a similar but more granular concept called ‘renderers’. Being a big fan of the principle of semantic markup or POSH, I’ve come to think that all portlets should have the same general shell or HTML markup.
So, I present the perfect portlet markup:
<div class="portlet-window"> <div class="decoration"> <h2 class="title">portlet title</h2> <ul class="controls"> <li class="skip"><a href="#skip_$PORTLET_ID">skip this window</a></li> <li class="mode edit"><a href="#">edit this window</a></li> <li class="mode view"><a href="#">view this window</a></li> <li class="windowstate minimized"><a href="#">minimize this window</a></li> <li class="windowstate maximized"><a href="#">maximize this window</a></li> </ul> </div> <div class="portlet-content"> portlet content </div> </div> <a name="skip_$PORTLET_ID"></a>
You might notice this layout:
- follows the JSR168/JSR286 naming standards for window, decoration, controls, etc.
- marks the portlet title up as a level 2 heading; from my experience this is the ‘right’ choice for the portlet title as the portal page title itself should be the level 1 heading
- to promote accessibility, renders actual text content in the mode/state menu anchor links (which should be internationalized and can be replaced with appropriate icon images using your css image replacement technique of choice, of course)
- to promote accessibility, adds a skip link to the mode/state menu for skipping the content of a given portlet (this is very useful for screen readers and can be removed from the page using your css text hiding method of choice)
Note that one or more the elements in the shell may be removed. For example, sometimes portlets won’t display their portlet title, which is often the case with content-manged portlets (ideally, this would be a configuration rather than separate skin or renderer).
By the way, this post is intended to be a bit controversial; hoping to challenge my audience (if there is one =P) and maybe to come to some kind of consensus.
So what do you think? Did I get it right? What would you change or improve to this portlet markup?
Sometimes I look at old draft blog entries and ask myself “what was I thinking?”. Every once in a while, though, I look at an old draft post and say “hey, that’s pretty cool!”. This article fell into the pretty cool category, not so much for the content, but the example app, so I hope you enjoy it (OK, you can skip to the end now).
There’s a long-standing, accepted pattern for handling form submissions in web applications; it’s usually called the post redirect get pattern. The goal of the pattern is to prevent the payload of a HTTP POST request from being stored in the browser history.
Keeping the POST data out of the browser history helps prevent duplicate form submissions and also is the best way to make sense out of navigating backward/forward through the history after a post. Imagine refreshing a webpage without the PRG pattern after making a credit card purchase.
To speak in HTTP terms, the PRG pattern intends to handle the non-idempotent nature of the POST method. As defined by the HTTP specification, it’s not safe to submit the same POST data more than once, so the PRG pattern prevents the user from resubmitting POST data when refreshing their browser window or navigating through their browser history.
As I mentioned, this is a long-standing pattern and as such, there are several references available that describe it in full detail:
It is also widely implemented in most modern web application frameworks (eg: JBoss Seam, Ruby on Rails) and because it avoids problems caused by HTTP itself, it is implemented in various web-specific languages/frameworks (JavaEE, .NET, PHP, Python, Ruby, etc).
OK, so why did I think this post was worth finishing? Well, many moons ago, I built out an example application in PHP demonstrating the post redirect get pattern.
Hope you find it useful.
Packt Publishing recently published a book on JBoss Portal; the book, titled JBoss Portal Server Development, is written by Ramanujam Rao - a JavaEE architect who currently works for Nationwide. Packt sent me a copy and asked that I write a review of the book, which I plan on doing in the next few weeks.
Until then, Packt has made available a sample chapter of the book - JBoss Portal Server Development, Chapter 6: Portals and AJAX (download the sample chapter at: http://www.packtpub.com/files/jboss-portal-server-development-sample-cha...).
In the sample chapter, Rao discusses the basics of AJAX in the Portal environment, describing the enhancements for asynchronous communication JSR286 brings to the table. He also provides some basic code examples implementing a portlet with AJAX functionality, in addition to describing JBoss Portal’s out of the box AJAX support (drag and drop, partial page refreshing, etc.).
I’m excited about the book, because I think it’s one of the first on JBoss Portal, which speaks to the products coming maturity and will give it some clout to compete with the other portal vendors. I’m sure the folks at JBoss Mass would agree.
At first glance, the book appears to be a solid companion to the jboss.org documentation, adding an additional level of architectural guidance; it’s a great addition to the bookshelf if you’ll be working with JBoss Portal.
Do you use Spring Portlet MVC? Have you ever noticed the ImplicitModel request parameter in your URL? It looks something like:
Well, it’s a Spring Portlet MVC 2.5 feature and I was scratching my head trying to figure out what it does. It’s set by Spring under the covers, so I dug into their source code to understand it and thought I would share.
The ImplicitModel is defined in Spring’s AnnotationMethodHandlerAdapter (which I describe in another post on annotation-driven portlet development w/Spring). In short, the AnnotationMethodHandlerAdapter is primarily responsible for scanning the @RequestMapping annotations on a given controller and executing the best matching method. It also sets and retrieves the ImplicitModel on portlet requests.
So what does the ImplicitModel do? Well, because most portal implementations redirect to the render phase after an action request (applying the post-redirect-get pattern), request attributes set in the action can’t be used in the subsequent render phase.
Spring Portlet MVC uses the ImplicitModel to overcome this limitation. On an action request, if the request’s model (see ModelMap class) isn’t empty, the AnnotationMethodHandlerAdapter will automatically store the ModelMap in portlet’s session for use on the upcoming render request. It also sets the render parameter (org.springframework.web.portlet.mvc.ImplicitModel), to tell the render phase to pre-load its model from the ImplicitModel stored in the session.
One additional tip: after a successful action method call, you may want to manually clear the model to prevent the action model data from being stored in the ImplicitModel. As an example, say you submit a form in an action request and render the same form with a success message after a successful submission. If you don’t want to display the originally submitted data on the success view - call ModelMap.clear() to prevent it from being stored as an ImplicitModel.
Jared Richardson spoke at a Richmond Java Users Group meeting I attended last week; his topic was about investing in yourself and your career - what he called career 2.0. At one point during the presentation, he noted that “if you can’t draw something, you don’t understand it”, which motivated me to finish a blog post I started a while back about Spring Portlet MVC.
I gave a presentation at CapTech’s Feed Your Brain series about using Spring Portlet MVC’s annotation-driven development style, and I wanted to diagram how the lifecycle works under the covers.
The following diagram never made it into the presentation so I wanted to post it here.
Sorry if the graphic doesn’t blow you away; I have an older version of OmniGraffle - but want to get one of these.
So, in short the graphic depicts:
- like most implementations of the Front Controller pattern, the DispatcherPortlet sits in front of all PortletRequests
- if a DefaultAnnotationHandlerMapping is set as the default HandlerMapping implementation in your Portlet’s Spring application context, the DispatcherPortlet will use it to find a @Controller
- the DefaultAnnotationHandlerMapping itself searches your application context for the best matching class annotated as a @Controller
- the DefaultAnnotationHandlerMapping then passes control back to the DispatcherServlet, which then needs a AnnotationMethodHandlerAdapter to determine which method to call on your controller
- the AnnotationMethodHandlerAdapter then checks for methods annotated with @RequestMapping and, again, finds the “best match” method to handle the PortletRequest
- the request is served, and control is passed back to the DispatcherPortlet - voila!
Hope this is helpful to those looking to use Spring Portlet MVC’s nifty annotation model.
I’ve always been an open source fan and for the past 2 or 3 years I’ve been working with JBoss products - lately JBoss Portal. So, I decided I want to become more active in the JBoss Portal forums on JBoss.com - unfortunately, though, their forums aren’t RSS-enabled and I’m a big RSS user.
So, I decided to use one of my favorite, free web-tools - Yahoo Pipes - to build an RSS feed for the JBoss.com forums.
In short, the pipe does the following:
- uses a URL Builder object to “scrape” the jboss.com forum site
- passes in a parameter of the forum ID to read (ie: 215 for the Portal User’s forum, 205 for the Portal design forum)
- uses regular expressions to slice and dice the fetched page into an aggregated RSS feed
Because the forum ID is a parameter, you can add any JBoss.com forum to your RSS client of choice. The feed results aren’t perfect (eg: doesn’t get the original post date right), but it does the trick for my needs.
So check out the JBoss.com Forum Feeds Pipe at: http://pipes.yahoo.com/pembertonandy/jbossforums
Feel free to clone the pipe and use it to your liking; the same technique can be used on any publicly available site. Let me know if you like it!
Before the Portlet 2 specification (JSR286), the recommended method for adding AJAX functionality to a JSR168 portlet was to deploy an additional servlet to the portal server (either inside the same WAR as your portlet(s) or in a stand-alone WAR) to handle asynchronous requests. Requests to these servlets are then handled by the servlet container as opposed to being routed through the portlet container, so they don’t automatically inherit the security context from the portal, as your portlets would.
The goal of this article is to describe how to enable security in your AJAX servlets in JBoss Portal 2.6.
JBoss Portal 2.7 supports JSR286, which has features built into portlets for serving AJAX requests. So while this technique may be less useful in that environment, nothing precludes the use of AJAX servlets in the 286 environment, so this technique may still come in handy.
The goal of this article is to show you how to use pack:tag to optimize the performance of your JBoss Portal theme. I’ve used this approach on a production JBoss Portal 2.6 implementation and tested the approach out in version 2.7.