On Sun, 2008-02-17 at 09:44 +0100, Mario Ivankovits wrote:
> Sorry for top posting, the handy client makes it hard to make it right.
>
> What you have done so far is great I think.
> But there is a third way of configuring a converter.
> This is configuring a converter with its own tag, like dateTimeConverter.
> This allows you to configure this very instance of the converter.
We don't need to support pulling f:dateTimeConverter instances from
Spring do we? Those standard converters will never need an Orchestra
converstation context or persistence context...
> I don't know how it works exactly from top of my head. Probably it is very
> easy.
> As a first step our converter wrapper should save the state of the spring
> converter (if it is a StateHolder) too.
Are you talking about how to configure the orchestra
SerializableConverter class as a wrapper around a converter?
Here's how I tested this:
In spring config:
<bean name="toUpper"
class="org.apache.myfaces.orchestra.lib.jsf.SerializableConverter">
<constructor-arg>
<value>toUpperConverter</value>
</constructor-arg>
</bean>
<bean name="toUpperConverter"
class="org.apache.myfaces.examples.simple.backings.UpperStringConverter"/>
Then either
<h:inputText converter="#{toUpper}" ../>
or
<h:inputText ...>
<orchestra:converter beanName="toUpper"/>
</h:inputText>
will return an UpperStringConverter wrapped in a SerializableConverter.
I think having it explicit like this is nicer than having magic
converter creation that auto-wraps stuff. Firstly it gives people full
control over the process; wrap or not wrap as they choose. And secondly
it is very obvious what is going on, rather than making the existence of
a SerializableConverter almost invisible.
Alternatively, in the default orchestra-spring-config.xml we could
possibly define a Spring BeanPostProcessor that intercepts the creation
of all beans of type Converter and returns a wrapped object. I would
personally prefer the explicit approach though; more work for the user
but less "magic".
Note that not all converters will be suitable for wrapping in a
SerializableConverter; any converter type that has "state" will not work
this way because a new instance is created on deserialize.
Regards,
Simon
