cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Clarification on converter concept
Date Wed, 04 Jul 2007 22:47:51 GMT
Joerg Heinicke pisze:

First of all, thanks for your insightful comment!

I'll address all the points separately.

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

Same here.

>> It is perfectly valid to have more than one converter for particular
>> type, each one identified by unique, short identifier.
> Yes.

There is nothing to comment here, but I mark this as (*) to reference it further.

>> Thanks to converter concept following syntax:
>> {jxpath:cocoon/request/parameters/date}#shortDate
> Does that one (and converters in any way) already exist?

Yes and no. We don't have converters applied to values returned by ELs but its my task to
introduce them if we agree we need them. The main 
idea is that we have them already in CForms so it's quite natural to extend the concept to
the areas when conversion is also needed.

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

Fighting with myself to not answer right away, right here ;-)

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

As Daniel pointed out, it has been discussed but I must admit I'm not completely sure that
I "feel" the concept. That uncertainty made shape 
of my original mail. Nevertheless I'm all eager to learn from others.

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

 From purist's point of view it is really _bad_ idea to use interfaces and classes for something
that they were not invented for. I'm not 
purist and the world is dynamic so I can live with "hacky" solutions like that one. My comment
reflects my first impression after reading 
about it.

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

To be honest I'm not Spring specialist so I do not understand which infrastructure exactly
and how it helps. Even more confusing is that 
something is going to be replaced by something else. I really don't know what replaces what
and what's for. Sorry.

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

Do you want to state that you can define only one Converter for Foo class? Or do you want
to say that in Spring MVC you can register 
converter for Foo class that is available by using particular epxression (like xyz/bar/foo)?

What do you mean by registering? The idea for converters is that you just create a bean (that
implements necessary interface) and you are done.

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

What was counter-intuitive apart from switching between both that I do not like either?

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

After my refactorings you can add your own EL implementation by creating one bean (ExpressionCompiler).
Just providing a bean will let you 
to use a new langauge. The whole EL stuff is not used consistently across whole Cocoon areas
(sitemap, forms, flowscript, etc.) but it's my 
primary goal to change that. :-)

How Spring syntax looks like and how it is better than JXPath/JEXL?

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

It all looks like plumbing and is counter-intuitive for my taste. It may be that I miss the
idea totally. If you could explain it and say 
way such solution is better than proposed one it would be very helpful.

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

I really see that you are Spring insider because I really can't follow most of you have written.
I hope that you will be patient enough to 
explain all basic things.

Best regards,
Grzegorz Kossakowski

View raw message