Hi! >> 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... > Corret! I haven't meant the standard converters. I just wanted to point out that you can have a tag to install a converter on a given component. I do not mean the f:converter tag but something like f:dateTimeConverter. So you can have a home-made converter tag to configure the converter and install it on the parent component at the same time.
> Are you talking about how to configure the orchestra > SerializableConverter class as a wrapper around a converter? > Uhm ... do we have to configure each converter that way now? Wouldn't be very appealing, will it? > 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. > I think this thing is much like the aop:scoped-proxy stuff - we tried to get rid of this very single line and now we have to define two beans for just one converter!? > 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". > I am not sure, I think it should work out of the box, at least when the converter has been placed into one of the Orchestra managed scopes - as we do with the scoped-proxy stuff. > 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. > Yep, this is exactly what I tried to point out in my previous mail. If the converter implements the StateHolder interface the wrapper should save/restore the state too. I think this is the required first step to allow having the tag-converter-setup thing I outlined above. Ciao, Mario
