> <h:inputText ... converter="#{myConverter}" .../>
If I have a converter configured as myConverter in faces-config.xml, it looks like this
<h:inputText ... converter="myConverter" .../>
Under which circumstances are the #{} needed?
If you have a converter registered by "id", you would not need the "#{...}" _expression_ capability. But, that limits you to an instance of the converter that is essentially created like what you'd get from a "new" operator, with only the default set of properties. What if you want to use some Converter class, but customize its property settings?
This question surfaces an interesting (and not always understood) feature of the "converter" property:
* If you pass a literal string, JSF looks up a converter that you
have registered by "id" in some faces-config.xml file.
* If you pass a value binding _expression_, JSF evaluates it
at runtime and expects the evaluation to return an instance
of type javax.faces.convert.Converter.
Even without Spring in the picture, that means you can declare a managed bean named "myConverter" that will be instantiated on demand (when the "#{myConverter}" is evaluated). Just to give a trivial example of this, lets assume your model data is of type java.util.Date, but you always want to display it showing the time only (i.e. if you're using the standard DateTimeConverter, you would set the "type" property to "time". You can define a component like this:
<h:inputText ... converter="#{timeConverter}" .../>
and then define a managed bean in your faces-config.xml file:
<managed-bean>
<managed-bean-name>timeConverter</managed-bean-name>
<managed-bean-class>javax.faces.convert.DateTimeConverter</managed-bean-class>
<managed-bean-scope>none</managed-bean-scope>
<managed-property>
<property-name>type</property-name>
<value>time</value>
</managed-property>
</managed-bean>
and you'll get a preconfigured converter that does the right thing, without having to remember to set the property every single time. For extra fun, you can use value binding expressions in the <value> element, to initialze property values based on dynamic conditions. JSF's managed beans, in other words, *provide* a simple Dependency Injection (DI) or Inversion of Control (IoC) framework out of the box.
If you include the Spring IoC integration along with JSF, you can still do the above ... or, you can use the standard Spring configuration file to instantiate a Spring bean named "timeConverter", configured using the full power of DI that Spring offers (for example, you can instantiate an instance that uses constructor injection instead of setter injection). That's because the integration layer will first look to see if there is a managed bean definition for a given name and, if not, check to see if Spring knows how to create one. The developer who writes the value bnding _expression_ into the JSP page does not have to know or care which mechanism is actually used to create the converter for you at runtime.
Craig
