cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Wed, 17 Nov 2004 10:28:40 GMT
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


Mime
View raw message