cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: Clarification on converter concept
Date Tue, 03 Jul 2007 22:11:20 GMT
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
> 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.


> 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.


> 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.


> 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 

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.


(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].)

View raw message