Hi Mario,
Nice to see you back!
On Sat, 2008-02-16 at 16:37 +0100, Mario Ivankovits wrote:
> Hi!
>
> >It *is* useful to be able to create converters that have access to
> >conversation scopes, which in turn mean they need to be instantiated by
> >pulling them from Spring. But this syntax is already supported by jsf:
> > <someComponent id="comp2" converter="#{convId}"/>
>
> I don't think so. Isnt it that the value binding should return the converter
> id instead of a concrete instance?
Nope. The EL expression returns a Converter instance:
>From UIOutput.java from the Core 1.2 trunk:
public Converter getConverter()
{
if (_converter != null)
{
return _converter;
}
ValueExpression expression = getValueExpression("converter");
if (expression != null)
{
return
(Converter)expression.getValue(getFacesContext().getELContext());
}
return null;
}
There is no call to Application.createConverter here; the EL expression
return value is just cast directly to Converter.
>
> Also, I'd like to have the converter stuff implemented in a way which nicely
> integrate into JSF - as it is today. Otherwise you have to create a new way
> to define such converters.
I think what's there today is non-intuitive.
There is the method Application.getConverterIds() which is supposed to
return the list of all the ids that you can use in calls to
createConverter and as constants in f:converter tags.
Therefore with a normal JSF setup, the only things that you can
reference with
<f:converter id="someid"/>
are the converters that are defined in the faces-config.xml file, or
added via Application.addConverter.
With the Orchestra modification this is not true.
The serialization behaviour of the "magic" converter lookup stuff is
also non-standard. So
<f:converter id="id1"/>
and
<f:converter id="id2"/>
behave quite differently with respect to serialization if one is a
"normal" converter and one is pulled out of spring by Orchestra.
The syntax
<h:someComponent converter="#{myConverter}"../>
is very easy to understand; just look for the managed bean with that
name, like you would for any backing bean reference.
All this of course *only* applies to special home-made converters that
use the current conversation, right? We don't need to orchestra-enable
the f:convertDate converter, but instead need to enable converters that
are dealing explicitly with persistence?
>
> I don't want to make it more complicated just to avoid this JSF 1.2 oddity.
Agreed it would have been better if the JCR-252 people had done a better
job of backwards-compatibility. But that cannot be changed now.
I think using the converter attribute is much nicer syntax than a nested
converter tag anyway. It is pulling in a normal bean, which can be
configured via normal injection mechanisms. Everyone can understand that
just by looking at the EL expression.
The <f:converter> stuff is much uglier; it just creates a bare instance
of some class via Class.newInstance() and returns it. This is like the
stone-age compared to proper dependency-injection.
Anyway, less code is always better. Right now we have two classes in
Orchestra that exist *only* to work around the fact that f:converter
uses newInstance() instead of properly loading a managed bean. But we do
have a mechanism to properly load managed beans: the converter
attribute.
>
> Isn't there any tool which will help us to check about any JSF 1.2 usage?
Nope.
One other alternative would be to provide a new tag
<or:converter id="foo"/>
which would pull the converter from Spring.
Regards,
Simon
