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 :)
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.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 #.
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.
