Bruno Dumon wrote:
On Sat, 2004-11-13 at 05:50 +0100, Jonas Ekstedt wrote: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.
On Wed, 2004-11-10 at 12:15 +0100, Daniel Fagerstrom wrote:<snip/>
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,
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.
/Daniel
