Fred,
I think that I am
seeing eye-to-eye with you on your vision. This is good stuff and I hope it
doesn’t get lost in the near future. If you can, can you open a jira issue
with these various aspects and/or continue to keep tabs on progress towards
this goal?
-Pat
-----Original
Message-----
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette
Sent: Saturday, November 29, 2003 7:00
AM
To:
[EMAIL PROTECTED]
Subject: RE: [OS-webwork] Type Conversion
Handling
I've
many remarks about the XWork conversion mechanism.
1/ It
would be cleaner to use setDefaultConverter(new XWorkBasicConverter()) than
fulfilling the xwork-default-conversion.properties with the current entries
that refers to the XWorkBasicConverter.
2/ I'm
wondering if catching every exception when converting a value is clean,
because you don't make the difference between runtime exceptions and the
controlled TypeConversionException. I would be inclined to handle only
TypeConversionException exceptions.
3/ I
think that returning the value acceptableErrorValue(toClass) when a converter
fails is strange enough. Don't you think it sould be the converter that must
return the default value ? -> return tc.getDefaultValue(toClass), surely a
new method to add to the TypeConverter interface.
4/ I
personnaly dont like the idea of a special interceptor to handle specific
values and preventing type conversion exceptions. On the other hand, the idea
of dealing with the conversion errors with the validation framework is
welcomed. I explain my point of view :
My vision of a
converter, it's a date converter, it could be anything
else :
public
Object defaultValue = null;
public
object getDefaultValue()
public
Object convertValue(Map context, Object target, Member member, String
propertyName, Object value, Class toType)
else if
(Date.class.isAssignableFrom(toType))
{
... I obtain a String value, sa = (String) value
SimpleDateFormat
sdf = new SimpleDateFormat("dd/MM/yyyy");
try
{
result
=
sdf.parse(sa);
}
catch
(ParseException
e)
{
throw
new
TypeConversionException();
}
try
{
return tc.convertValue(context, target, member, property, value,
toClass);
} catch ( TypeConversionException e )
{
handleConversionException(context, property, value,
target);
return
tc.getDefaultValue();
}
->
I handle only TypeConversionException exceptions
-> The
conversion error is stored in the context to be retrieved (if wanted) by the
validation framework
-> I
return tc.getDefaultValue()
In my
validation conf file
<field name="myDate">
<field-validator
type="conversion">
<message>You must enter a date with the following format ...
.</message>
</field-validator>
[
<field-validator
type="required">
<message>The date is
mandatory.</message>
</field-validator>
With
this vision, you dont have to use a special interceptor, only if converters do
correctly their job.
Richard
HALLIER
Chef de
projet
[EMAIL PROTECTED]
01.40.12.41.52
www.uniclick.org
UNICLICK
-----Message
d'origine-----
De :
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]De la part de Jason Carreira
Envoyé : samedi 29 novembre 2003
03:27
À :
[EMAIL PROTECTED]
Objet : [OS-webwork] Type Conversion
Handling
I've overhauled how type
conversion errors are handled. Type conversion errors are now added to a Map
stored in the ActionContext which is available via
ActionContext.getContext().getConversionErrors(). This map is a map of field
name to values which will allow you to access the original value which
failed conversion.
I've also implemented 2 ways of
populating field errors with the type conversion errors into the field
errors of the Action. The first will populate all of the field errors from
the conversion errors and is implemented as an Interceptor. There are
actually 2 Interceptors, one in XWork and one in WebWork which extends the
one in XWork. They differ in the implementation of the method
protected boolean
shouldAddError(String propertyName, Object value)
The XWork version always returns
true, whereas the WebWork Interceptor returns false for values of null, "",
and {""}, preventing type conversion exceptions for these common empty
values from propogating to the field errors of the Action. The WebWork
version of this Interceptor has been added to the webwork-defaults.xml and
to the defaultStack defined therein.
If you choose not to use this
Interceptor, you can choose to enable this on a per-field basis by using the
Validation framework with the new field validator I've added, defined in the
validators.xml file like this:
<validator
name="conversion"
class="com.opensymphony.xwork.validator.validators.ConversionErrorFieldValidator"/>
This validator will look up the
conversion errors and, if it finds a conversion error for the field it is
applied to, it will add the appropriate error message to the Action.
Both of these methods use the
XWorkConverter.getConversionErrorMessage(propertyName, stack) which looks up
the type conversion error message for the property name as was done
previously, by looking for a message keyed by
"invalid.fieldvalue.propertyName" and using a default value if it is not
found.
Let me know if you find any
problems,
