[XW-134] Type Conversion Handling

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.0-beta2
• Fix Version/s: 1.0
• Component/s: Type Conversion
• Assignee: Patrick Lightbody
• Reporter: Richard HALLIER
• Created: 01/Dec/03 01:59
• Updated: 28/Dec/03 22:57
• Resolved: 28/Dec/03 22:57

Description

I refer to the mail I've sent to the mailing list. Hope it can help to write something clear and consistent.
Richard.

<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: [e-mail] [e-mail] On Behalf Of Fred Lamuette
Sent: Saturday, November 29, 2003 7:00 AM
To: [e-mail]
Subject: RE: [OS-webwork] Type Conversion Handling

Jason,

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 :

class DateConverter

public Object defaultValue = null;

public object getDefaultValue()

{ return defaultValue; }

public Object convertValue(Map context, Object target, Member member, String propertyName, Object value, Class toType)

{

if(value==null)

return defaultValue;

if( ... )

...

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(); }

}

In XWorkConverter

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>

]
</field>

With this vision, you dont have to use a special interceptor, only if converters do correctly their job.

Hope it can help.

Richard HALLIER
Chef de projet
[e-mail]
01.40.12.41.52
www.uniclick.org
UNICLICK

[Richard Hallier]

----Message d'origine----
De : [e-mail] [e-mail] la part de Jason Carreira
Envoy? : samedi 29 novembre 2003 03:27
? : [e-mail]
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,

Jason