dev@javaserverfaces.java.net

[Converter] - Issue when using <f:converter />

From: Matthias Wessendorf <matzew_at_apache.org>
Date: Wed, 5 Sep 2007 18:07:17 +0200

Hi,

I noticed an issue, when using the <f:converter /> tag.
The issue I noticed is present with these two RI version:
-1.2_04-b10-p01
-1.2_04-p02

Running my application with version "1.2_03", the issue isn't there.

Background:
In Apache MyFaces Trinidad, we replace the standard NumberConverter,
by our own converter, for instance to have support for client side
conversion.

The trinidad-impl...jar/META-INF/faces-config.xml does this:

<converter>
<display-name>Number Converter</display-name>
<converter-id>javax.faces.Number</converter-id>
<converter-class>org.apache.myfaces.trinidadinternal.convert.NumberConverter</converter-class>
</converter>

To make it clear, this NumberConverter extends the standard
NumberConverter. Here is the hierarchy:

javax.faces.convert.NumberConverter
  |_ org.apache.myfaces.trinidad.convert.NumberConverter
       |_ org.apache.myfaces.trinidadinternal.convert.NumberConverter


So, the problem is, when doing this in a JSPX file

<inputXyz ...>
  <f:converter converterId="javax.faces.Number" />
</inputXyz>

The converter is instanceof
"com.sun.faces.taglib.jsf_core.ConverterTag$BindingConverter"

When doing this:
<inputXyz ...>
  <tr:converterNumber />
</inputXyz>

The converter is instanceof
"org.apache.myfaces.trinidadinternal.convert.NumberConverter"

Since our "converter replacements" like:
-org.apache.myfaces.trinidadinternal.convert.IntegerConverter
-org.apache.myfaces.trinidadinternal.convert.LongConverter
-org.apache.myfaces.trinidadinternal.convert.NumberConverter
-...
(to name only three)

are implementing "extra" interfaces, like
"org.apache.myfaces.trinidad.convert.ClientConverter"
we are doing checks like

if (converter instanceof ClientConverter)
{
 ...
}
else
{
...
}

therefore usage of "<f:converter converterId="javax.faces.Number" />"
causes some issues.
I expected that this converter would be our replaced converter, but
it's instanceof
"com.sun.faces.taglib.jsf_core.ConverterTag$BindingConverter". So a
check against the "extra" interfaces isn't possible, when using
<f:converter ... />

Another issue that could come up with this, is that someone creates a
"custom converter", that implements the Trinidad API
ClientConverter-Interfaces as well, but the developer is to lazy to
provide a tag... The only usage would be <f:converter /> but, this
custom converter will never be handled as a client-converter.

Thanks,
Matthias

-- 
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org