Dynamic tables and Orchestra’s conversation scope

Very very often you have to have tables that display data based on a search result (like customers by city or similar). In one (or more) of the entries you are interested in continuing your work. In Trinidad you can use the inputListOfValues component to trigger a dialog, that contains the search engine:

<tr:inputListOfValues label="customer id"
   action="dialog:search" windowHeight="300"

A click on the “search” icon (provided by the component) will launch a dialog, that contains the mentioned search engine. The search page may look like:

<tr:form defaultCommand="search">
    <tr:inputText label="Name:" value="#{search.query}" />
    <tr:commandButton id="search" text="Search..."

  <tr:panelPage rendered="#{not empty search.result}" >
    <tr:table id="results" rowSelection="single"
        value="#{search.result}" var="customer">
        <f:facet name="header">
          <tr:outputText value="Name"/>
        <tr:outputText value="#{customer.name}"/>
      <tr:commandButton text="Cancel" immediate="true"
      <tr:commandButton text="Select"

The big problem here is the search bean. What scope to use for that bean?

Request scope?

Doesn’t work. When doing the query, you get a list of results (when query was successfully…) but next action (the selection of a customer) you’ll notice, that the underlying selection data (in Trinidad done with table.getSelectedRowKeys()) is not present.

Session scope?

Well… the selection now of course works, but when you launch the dialog again, the previews result is still visible… You can work around that by doing some (bogus) clean ups… well, are you really interested in doing that ?

The solution?

A scope that is between request and session and this is what MyFaces Orchestra provides with its Conversation Scope Features. Using such a scope simply gives you the clean solution that you want. No bogus clean-ups / workarounds are needed. Just declare the scope of the bean like:

<bean id="search"
    p:dao-ref="myDaoImpl" />

Now you are good to go! The SearchController bean is straight forward. No extra annotations, interfaces or abstracts classes are required. It just works! An other cool feature of Orchestra is the “ConversationBindingListener” interface. When you implement it, your bean get’s notified when it was added to the new scope (or removed). But this is totally optional.Even if you don’t need all bits of Orchestra at least I strongly recommend to use the new additional scopes since they really make the life of a web application developer more easy!

Well… I also have one rant… Orchestra shouldn’t have to offer such a extra scope. It should be part of the JavaEE specs. Not only for JSF this scope is useful. It should be part of the Servlet Spec. Perhaps Servlet 3.0 will address this ? But until that happens, Orchestra is a good friend!

Have fun!



Posted in java, jsf, myfaces, orchestra, trinidad
One comment on “Dynamic tables and Orchestra’s conversation scope
  1. AT says:

    Thanks for the example, Matthias. I’m looking into analyzing RichFaces and Trinidad and has been leaning towards Trinidad (we’re converting Oracle Forms!). Data pageability (at the server) and built-in filter mechanisms are definitely key criterias. Your example is prompting me to think that Trinidad by itself can’t handle the filtering “cleanly” when doing these LOV type lookups? Thanks (and keep on blogging)!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

March 2008
« Feb   Apr »
%d bloggers like this: