Showing posts with label SEAM. Show all posts
Showing posts with label SEAM. Show all posts

Thursday, January 29, 2009

JSF converter implementation notes

SEAM's built-in converters are big time-savers, especially the s:convertEntity and s:convertEnum. Now the needs of rolling out customized JSF converters are few and far between, I just want to jot down the patterns I had used in case I forget.


  1. take the entity's primary ID as string, and load it from persistence media by ID to convert back to object

  2. implement an algorithm that can encode the object into a unique string, and reconstruct the object by parsing the string

  3. Construct a map of strings and objects. Because converters are instantiated on demand, you have to save the map in a backing bean whose life-cycle spans over requests. The map is nested in the h:selectOneMenu component using f:attribute tag, so that the converter can get a handle of it.


SEAM Howto - end conversation and go back to the previous page

In web application it is often desirable to provide a "Cancel" button in a function area which will redirect the user back to the page they come from.

In SEAM if the function area is wrapped by a conversation, then there are two ways to archive this navigation effect, depending on whether or not you need to do clean up when ending the conversion.

If there is no clean up to be done, you can use s:link or s:button as shown in the example below. The action is invoked first. The view attribute is rendered if redirect did not happen after the action invocation.

If there is clean up to be done, you can archive this in pages.xml file with a navigation hack.




In your pages.xml:

Thursday, March 20, 2008

Using SEAM i18n support to externalize strings

SEAM brings support of i18n in JSF applications to a whole new level. It is another show case of "convention over configuration" design philosophy. But its documentation misled me a little bit.

By default, the resource bundle used by Seam is named messages and so you'll need to define your labels in files named messages.properties, messages_en.properties, messages_en_AU.properties, etc. These files usually belong in the WEB-INF/classes directory.
By reading this paragraph, I thought that when all you want is to externalize some labels/strings in your application, you can just throw a file named messages.properties then start referencing resources using messages built-in component. It didn't work like that.
I also tried to force loading the resource bundle using tag core:resource-loader in components.xml file. It didn't work either.
Finally it turned out that you got to put the locale string in your file name although you don't care about locale at all. In my case I just renamed my file as messages_en.properties and everything worked.
I guess it makes sense in a way that a resource bundle got be associated with a locale. But won't it be nice to dump everything without an explicit locale into the default?