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
http://reflectingonthevicissitudes.wordpress.com/
