On 03.07.2007 21:47, Grzegorz Kossakowski wrote:
I'm glad to see that we agreed on design of OM, now I would like to
focus on converter concept.
First of all, I would like to know which form should be preferred:
"converter" or "convertor". Since both are valid (according to
dictionary.com) I'm not really sure which one I should pick.
In CForms it's convertor but IIRC it was considered a strange name
though correct. Google: 10 million hits vs. 100 millions. So converter
is probably the more natural choice.
Now I must admit that I'm not sure if I understand converter concept.
Let me explain my current understanding.
Basically, converter for certain type is a class that performs
conversion between that type and its string representation.
Yes.
The
converter is locale-aware so string produced by converter may depend on
user's locale (e.g. Date representation).
Don't know. Read on ...
It is perfectly valid to have more than one converter for particular
type, each one identified by unique, short identifier.
Yes.
Thanks to converter concept following syntax:
{jxpath:cocoon/request/parameters/date}#shortDate
Does that one (and converters in any way) already exist?
will be used to tell Cocoon that user expects 'date' request parameter
to be formatted as short date (whatever it means).
I ask because I don't consider that one a good idea. Not the syntax
itself, but the fact that you can "select" a particular converter. Why?
Read on ... :-)
For each type it is possible to define default converter and it is
assumed that Cocoon ships with set of default converters for primitive,
common types.
Ok.
Is the description above exhaust the converter concept?
Think so. But ... now the stuff I want to add.
I don't know if that topic has already been discussed. At least I can't
remember - but that might also be one of the unread old threads in my
inbox. If you start from scratch I want to suggest to have a look at how
Spring handles this before we invent anything new.
Actually it's not even invented by Spring but they use so called
PropertyEditors [1]. They are part of the JDK (even before Java 5 ;-))
and in the package java.beans. Since this stuff was once targetted for
tool providers for introspection this interface is anything else than
slim, but after my experiences with Spring and many built-in and custom
PropertyEditors that is not a problem at all. The reason is the
PropertyEditorSupport [2] providing a meaningful default implementation.
So when you need to write your own PropertyEditor you actually extend
PropertyEditorSupport and implement only getAsText() (conversion from
object to string) and setAsText(String) (other way around).
One downside: PropertyEditors are not thread-safe. Spring used to
synchronize on them in 1.x, a real bottle-neck. In 2.x you are
encouraged to work with prototypes, Spring provides the necessary
infrastructure [3].
Now to some particular questions.
1. Selecting a converter. That's really a bad choice. That's like
<fmt:formatDate/> in JSP/JSTL. Why is it bad? Imagine setting the
formatted date as value of an input field. Now the form is submitted.
Who is supposed to parse that date string? It must be a two-way process
- like it is done in CForms with convertors or PropertyEditors in Spring
MVC. They are registered for a particular widget (CForms), type/class or
path or combination of the both (Spring MVC) [6].
We can provide the possibility for read-only stuff which ends in text
but I wonder what for. In Spring MVC I also use the PropertyEditors for
those use cases. I register them once anyway.
2. When not selecting a converter you also don't need a syntax for it
:-) What about the syntax for the paths itself? I always found the
JEXL/JXPath syntax rather counterintuitive. Maybe that had improved with
the JXTemplate refactoring, especially the need to switch between both.
IIRC a goal of the refactoring was also to allow easy addition of
further expression languages. So what about adding the path syntax which
is really intuitive. Spring provides the whole infrastructure with
BeanWrapperImpl [3, 7] as the central access point. Spring e.g.
integrates it with JSP via a tag [8], we would need to add integration
with our template stuff.
3. Locale. PropertyEditors have no support for i18n/l10n. (Actually I
wonder why. Shouldn't tool providers also show localized string
representations of a bean?) So how to do it? I had a look at Spring's
CustomDateEditor [9]. It's set up with a DateFormat. Since
PropertyEditors should be prototypes anyway I don't see a problem to
inject the Locale into the editor on registration as done via DateFormat
for the CustomDateEditor. That works without the PropertyEditors being
locale-aware.
That was quite much, I hope you could follow. I'm really deep inside
Spring MVC at the moment :-) Feel free to ask where I should elaborate.
Regards,
Joerg
[1] http://java.sun.com/j2se/1.4.2/docs/api/java/beans/PropertyEditor.html
[2]
http://java.sun.com/j2se/1.4.2/docs/api/java/beans/PropertyEditorSupport.html
[3]
http://static.springframework.org/spring/docs/2.0.6/reference/validation.html#beans-beans
(Actually the reference still only shows the old way with shared
PropertyEditors. The new way was only added recently [4] and will be
included in 2.0.7's documentation. The important interface is
PropertyEditorRegistrar [5].)
[4] http://opensource.atlassian.com/projects/spring/browse/SPR-3512
[5]
http://www.springframework.org/docs/api/org/springframework/beans/PropertyEditorRegistrar.html
[6]
http://www.springframework.org/docs/api/org/springframework/beans/PropertyEditorRegistry.html
[7]
http://www.springframework.org/docs/api/org/springframework/beans/BeanWrapperImpl.html
[8]
http://www.springframework.org/docs/api/org/springframework/web/servlet/tags/form/AbstractDataBoundFormElementTag.html
[9]
http://www.springframework.org/docs/api/org/springframework/beans/propertyeditors/CustomDateEditor.html
