Bruno Dumon wrote:
On Wed, 2004-11-10 at 12:15 +0100, Daniel Fagerstrom wrote:
<snip/>
CForms Convertor Integration
----------------------------
Here is the Convertor interface:
public interface Convertor {
/**
* Converts string representation into the object of convertor's type.
*
* @param formatCache can be null if not needed
*/
ConversionResult convertFromString(String value, Locale locale, FormatCache formatCache);
String convertToString(Object value, Locale locale, FormatCache formatCache);
Class getTypeClass();
/**
* Generates a bit of information about this convertor (optional).
*/
void generateSaxFragment(ContentHandler contentHandler, Locale locale)
throws SAXException;
public interface FormatCache {
public Object get();
public void store(Object object);
}
}
The main problem is the ConversionResult. It is a class that in turn
uses some CForms specific stuff, (ValidationError, I18NMessage and
Cosntants). I think the idea of having a ConversionResult is ok, but we
need to make it independent of the rest of CForms.
AFAICS we don't need the formatCache in a convertion component, each
convertor will only be needed to be defined once
The purpose of the formatCache is if a lot of values need to be
converted using the same convertor, which is (or can be) the case in
selection lists. Java's DateFormat and NumberFormat classes are not
thread-safe,
Ok. didn't know that, disturbing :/
so they need to be recreated for each conversion, and this
can be quite heavy (eg the number or date formatting pattern must be
reparsed each time). The format cache allows to store the prepared
Date/NumberFormat instance, but is completely optional.
Yes, now it makes perfect sense. Would it be possible to let the
convertor manager handle some thread local Date/NumberFormat cache, so
that the user of the convertor doesn't have to manage that?
/Daniel
