cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Wed, 17 Nov 2004 09:55:21 GMT
Bruno Dumon wrote:

>On Sat, 2004-11-13 at 05:50 +0100, Jonas Ekstedt wrote:
>>On Wed, 2004-11-10 at 12:15 +0100, Daniel Fagerstrom wrote:
>>How about an interface like this:
>>public interface Convertor {
>>    public String getId();
>>    public void setId(String id);
>>    public Class getTypeClass();
>>    public String convertToString(Object value, Locale locale) 
>>	throws Exception;
>>    public Object convertFromString(String value, Locale locale) 
>>	throws Exception;
>>Each convertor has an id (useful for error reporting when conversion
>>fails) and a typeClass (ie the class type it converts to/from). Those
>>convertors that need extra configuration would implement Configurable.
>So if convertFromString fails, you'd throw an exception? A user who
>enters something invalid is far from an exceptional condition,
Agree abot that. The idea with the conversion block (in case you didn't 
follow the long thread), is to make convertors available outside CForms, 
for all kinds of input and output handling, e.g. in template languages. 
The problem with ConversionResult from this POV is that it depends on 
some other CForms classes (ValidationError, I18NMessage and Constants). 
And the conversion block should have as few dependencies as possible.

> that's
>why currently the ConversionResult is returned which includes this
>information (exceptions are rather heavy to create).
>Originally, convertors returned null if conversion failed (and otherwise
>the converted value), but then the ConversionResult was introduced to
>allow convertors to also return an error message describing why the
>conversion failed.

Most of the CForms convertors have a try block around the value parsing 
anyway and a catch block that creates a message in the ConversionResult 
based on the type of convertor. Throwing an exception and making the 
type info available seemed to be a good way to booth make it more 
independent of the context where it is used and make it easy to write a 
CForms-convertor wrapper for it. Even if a conversion failure isn't an 
exceptional state in form handling it might be an exceptional case for 
other use cases. But it is not a big deal, if you have better 
suggestions we can use them instead.


View raw message