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, 10 Nov 2004 11:15:18 GMT
Jonas Ekstedt wrote:

>On Mon, 2004-11-08 at 14:10 +0100, Leszek Gawron wrote:
>  
>
>>Something like ${bean.startDate} or <jx:out value="${bean.startDate}"/> would

>>use default renderer. Something like ${bean.startDate?class=emph} <jx:out 
>>value="${bean.startDate}" styling="emph"/> would point that other convertor is

>>needed.
>>    
>>
>
>I've implemented something similar to this and would be very happy to
>donate it.
>http://www.mail-archive.com/dev@cocoon.apache.org/msg23989.html
>
Cool stuff again :)

>It's basically a converter that sits on top of common-el's expression
>evaluator.
>
>You can have a template that looks like this for example
>
><p>Default conversion of date: ${date}</p>
><p>Short conversion of date: ${date#short}</p>
>
>The expression evaluator evaluates the ${date} to a Date. It then looks
>up its configuration for a Date -> String converter. Different
>converters between the same class types are differentiated by what comes
>after #.
>  
>
I guess we all, or at least the participants in this thread, agree about 
that we want a convertion component in Cocoon. Now the question is how 
we continue.

First the convertor component must, IMO, be integrated with the 
convertion stuff in CForms. Cocoon is complicated enough we don't need 
two different convertor packages that does the same thing in two 
slightly different ways. Especially as I, (as I have written about 
earlier in this thread), would like to refactor CForms, so that it can 
use the convertor component for input/output handling, instead of having 
convertion being part of the data type.

So what I'd like to do is to create a convertor block and move the 
convertor stuff from CForms to that block. Unfortionally the CForms 
Convertor has some small dependencies on other CForms stuff. Lets look 
at the details (if you are not interested in this, I discuss other 
details later in the mail).


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 
generateSaxFragment is also somewhat specific for my taste, I wonder if 
that is part of the convertion concern. Furthermore it has an empty 
implementation in all the convertors within CForms, so it is hard to see 
what it is supposed to be good for.

The CForms convertors is not configured the standard Avalon way. Mainly 
because the Avalon configuration doesn't handle name spaces.

What lacks in CForms Convertor from our POV, is a way to use 
presentation classes. Maybe also would like to have more general 
convertion between objects in general. I have no use cases for that and 
I would prefer keeping it as simple as possible.


Presentation Classes
--------------------

We need to find a good syntax for presentation classes. I'm not 
completely convinced about the '#' selector, as it normally is connected 
to positions, but I don't have any better suggestions. The 
${date?class=short} is unecesarilly verbose as class is the only 
attribute that we use. Using specialized tags might also be an 
alternative. But that is rather clumsy for xml attributes, and it would 
be nicer to have a mechanism that is not connected to a certain template 
language.

How does type, locale and class interact? I would propose to have the 
priority order type > locale > class. Meaning that if type, locale and 
class are given the convertion component will first look for convertions 
having the right type, if none is given a default convertor (.toString) 
is used. If there are convertors of the right type but not the right 
locale, the default convertor for the type is used. If there are 
convertors of the right type and locale, but not with the right class, 
the default convertor for the type and locale is used.

Configuration files
-------------------

What syntax do we want? Are we using one file for all locales or 
different ones? I think it would be rather usefull to have a mechanism 
for extending an existing configuration file. Then we can provide some 
default configuration files for differenent locales in the Cocoon 
distro, that users can extend with their more specialized rules.

JXTG etc.
---------

Where is the convertion component useful, JXTG and CForms are obvious 
places, IMO, other places?

WDYT?

/Daniel

P.S.

Jonas, I still think that Bugzilla is a good place for your patches ;) 
Please add the Apache license to all files also. And than you for your work.


Mime
View raw message