On Wed, 2004-11-10 at 12:15 +0100, Daniel Fagerstrom wrote:
> 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.
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.
The convertors would be created by a ConvertorManager configured by
something like:
<root>
<convertor id="java.util.Date"
src="o.a.c.conversion.convertor.DefaultDateConvertor"/>
<convertor id="java.util.Date#short"
src="o.a.c.conversion.convertor.DefaultDateConvertor"/>
<style>short</style>
</convertor>
<convertor id="java.util.Date#full"
src="o.a.c.conversion.convertor.DefaultDateConvertor"/>
<style>full</style>
</convertor>
<convertor id="java.util.Date#myformat"
src="o.a.c.conversion.convertor.CustomDateConvertor"/>
<pattern lang="en">MM/dd/yyyy</pattern>
<pattern lang="se">yyyy-MM-dd</pattern>
</convertor>
</root>
The convertors are accessed from a ConvertorManager:
public Convertor getConvertor(String id);
The id's of each convertor would take the form of className#type so that
whoever uses the convertors can do something like:
String className = obj.getClass().getName();
convertor = convManager.getConvertor(className + "#" + type);
String str = convertor.convertToString(obj, locale);
One problem with this type of configuration would be that it is hard to
implement a fallback mechanisms (eg if we don't have a
"java.util.Date#full" converter use "java.util.Date"). However I don't
know how useful fallback would be anyway (see below).
>
> 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.
One possible use case for other types of conversion would be Iterator
conversion. This could be useful in forEach template tags. Eg:
<forEach var="widget" items="$repeaterWidget">
...
</forEach>
Then you could use forEach for any object type that has an Object <->
Iterator convertor.
>
>
> 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.
I think the choice of separator character is rather limited as it cannot
be either a legal variable name character nor a legal operator
character. Someone might want to do ${1+1#decimal}.
>
> 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.
Wouldn't it be easier to just throw an exception if the correct type of
convertor couldn't be found. The fallback convertor probably wouldn't be
what the page author had in mind anyway. Regarding locale fallback,
shouldn't this be up to the convertors themselves as only they know if
they are locale sensitive. In the example above the DefaultDateConvertor
can handle any locale whereas the CustomDateConvertor should throw an
exception if there is no pattern for the locale or alternatively use a
default pattern.
<snip/>
> 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.
I'll do so. I hope I won't add to much noise to the bug database.
Cheers // Jonas
