You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gr...@tuffmail.com> on 2007/07/03 21:47:53 UTC
Clarification on converter concept
Hello,
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.
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). 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
will be used to tell Cocoon that user expects 'date' request parameter to be formatted as short date (whatever it means).
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?
Thanks for your opinions.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Joerg Heinicke skrev:
> On 03.07.2007 21:47, Grzegorz Kossakowski wrote:
...
>> 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 ...
Locale awareness is part of the idea.
...
>> Thanks to converter concept following syntax:
>>
>> {jxpath:cocoon/request/parameters/date}#shortDate
> Does that one (and converters in any way) already exist?
In Cocoon we only have the "convertors" in CForms. The "converter
concept" is about improving the CForms convertors and making them
available in templates (and possibly in other places).
There is an old prototype https://issues.apache.org/jira/browse/COCOON-1345.
>> 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 ... :-)
Normally you don't choose what converter to use. The framework select
based on data type and locale. But for e.g. dates there are several
different string representations (short, medium, full and long or maybe
some custom format) that the template or form author needs to choose
between. To me it seem reasonable to have a syntax for making this
possible in e.g. the template.
...
> 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.
...
> 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 didn't manage to follow all the technical details. But in general it
would of course be good to reuse the Spring stuff. The main hurdles is
that the Spring mechanism doesn't support locales in any systematic way
and that it is not obvious how to use it for a webapp that supports
multiple locales. While it clearly has a lot of overlap with what we
want for the new improved OM, expression handling and converters it is
far from an 1-1 mapping.
It would be nice if you could expand a little bit more on what
advantages in using the Spring stuff that you see.
Architecture
============
Anyway, let us discuss architecture a little bit so that we can be more
concrete about how the Spring stuff would fit in:
The "converter architecture" as I imagine it consist of three parts.
* Converters: that provides a bidirectional mapping between objects and
string representations of them.
* Converter registry: where converters are registered together with what
type they act on and optionally what locale they handle and maybe a
variant (the later for handling multiple representations). The registry
has a lookup method that finds the right converter based on data type,
locale and variant. The lookup method probably contains default
strategies and fall back methods for parameter combinations where no
converter is registered.
* Integration: The template and forms uses the converter registry for
finding the right converter for going from objects found with the
expression language to string representation and for converting form
input to the right kind of object.
Applying the architecture
=========================
Converters
----------
For the converters we have the CForms convertors today
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/datatype/convertor/Convertor.java,
the most imortant methods are
ConversionResult convertFromString(String value, Locale locale,
FormatCache formatCache);
String convertToString(Object value, Locale locale, FormatCache
formatCache);
It is not that different from the setAsText and getAsText methods of the
PropertyEditor
http://java.sun.com/j2se/1.4.2/docs/api/java/beans/PropertyEditor.html.
An important differences are that the convertor depends on a locale
which the property editor doesn't. IMO it would be cleaner to have the
locale dependency in the registry instead of in the converter. Next the
convertor needs a format cache, this is IIRC because date and number
formating objects not are thread safe and takes some work to construct.
When the forms framework was written, thread locals where quite
inefficient, so an external cache was used instead. This is not a
problem in Java 1.4 so we could use a thread local cache and get rid of
the format cache in the API. Last the convertFromString returns a
ConversionResult while setAsText throws a IllegalArgumentException for
badly formated input strings. I haven't looked at the details and have
no opinion about this.
As a conclusion I think that PropertyEditors would work fine for us if
we find it worthwhile. Some effort is needed for integrating them in the
forms framework.
Converter Registry
------------------
The PropertyEditorRegistry
http://www.springframework.org/docs/api/org/springframework/beans/PropertyEditorRegistry.html
of the Spring framework, register and lookup "converters" based on class
and property path. For a Cocoon framework I would prefer looking up a
converter based on class, locale and variant, while I don't see any
obvious use cases for property path. So the fit between the
PropertyEditor lookup and our needs is not that obvious AFAICS.
Integration
-----------
The BeanWrapper
http://www.springframework.org/docs/api/org/springframework/beans/BeanWrapper.html
could be interesting as a "container" for the expression handling and
converter stuff in Cocoon. Then the forms framework and template would
connect to the object model through our custom BeanWrapper. In this case
we would have a custom implementation that could use our more general
plugable ELs as property path strings. Also here it is unclear what to
do with locale handling.
--- o0o ---
So as a conclusion: it would be nice to reuse the Spring stuff and there
are big overlaps, but especially for locale handling it is not obvious
to me how to use it. Then of course there is the question if it is
worthwhile to reuse.
WDYT?
/Daniel
Re: Clarification on converter concept
Posted by Joerg Heinicke <jo...@gmx.de>.
On 15.07.2007 00:45, Vadim Gritsenko wrote:
>>> I also wonder how you are going to use CForms without CTemplate? You
>>> must use some template mechanism to produce data representing form
>>> and its state.
>>
>> FormsTransformer? It has a template approach as well [1], but no EL at
>> all.
>
> FormsTransformer is sort of on its way out (right, Jeremy?)
It was only an example for independent usage of either CForms or
CTemplate. It is also possible to not use CForms, but just some plain
simple form. When you use a converter here you somehow need to get the
value converted back as well. With Spring I can do this, I'm not tied to
use their taglib since the converter wraps the object.
>> Actually I'm not very keen on any templating approach at all.
>
> FormsGenerator?
I'm aware of it. Again it was just an example of independent usage.
Joerg
Re: Clarification on converter concept
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Joerg Heinicke wrote:
> On 13.07.2007 10:31, Grzegorz Kossakowski wrote:
>
>> I also wonder how you are going to use CForms without CTemplate? You
>> must use some template mechanism to produce data representing form and
>> its state.
>
> FormsTransformer? It has a template approach as well [1], but no EL at all.
FormsTransformer is sort of on its way out (right, Jeremy?)
> Actually I'm not very keen on any templating approach at all. I don't
> like to first provide data to some template context and second retrieve
> it from there in the template. IMO it's much better to have a complete
> push approach and only encroach if it is necessary (like XSLT
> templates). (My diploma thesis was about this btw.) A possible
> implementation for this is to convert the form model into an XML
> representation and let a quite generic XSLT do the rest.
FormsGenerator?
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/forms/generation/FormsGenerator.html
Vadim
Re: Clarification on converter concept
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
> Joerg Heinicke skrev:
>> On 13.07.2007 10:31, Grzegorz Kossakowski wrote:
> ...
>> Actually I'm not very keen on any templating approach at all. I don't
>> like to first provide data to some template context and second
>> retrieve it from there in the template. IMO it's much better to have a
>> complete push approach and only encroach if it is necessary (like XSLT
>> templates). (My diploma thesis was about this btw.)
> I prefer a push approach as well. But this project is not about creating
> the ideal template framework. It is about keeping back compatibility and
> at the same time giving users a simpler and cleaner way forward for new
> development and possible refactoring of old stuff.
Yes, I think Daniel is right about my goal.
> AFAIU, it will be possible to use the object model without any default
> content, (is that true Grzegorz?). In such a scenario you can have a
> pure push approach, by only pushing the data that should be rendered
> into the object model.
Yes, there will be default ObjectModel implementation that will collect environmental data and expose in unified way but you can easily
write your own implementation (it will have very light-weight interface) that could expose any data you like and any form you like.
It's a worth to say that thanks to Spring Configurator capabilities it will be extremely easy to force any our component to use your own
ObjectModel implementation.
> I preferred that kind of solution once. But now I find it unnecessary
> complicated in most cases. The first problem is that it requires some
> work to convert bean structure to XML data. You will probably need some
> configuration file that handle part of the conversion. In comparison to
> just applying an EL to a bean structure it is more complicated. Second,
> many people find XSLT much more complicated than a simple template
> language. Third, the development of XSLT processors and tooling, has
> been a disappointment. Xalan, still doesn't implement XSLT 2.0, and the
> error messages from both Xalan and Saxon can often be cryptic or non
> existent.
Same feelings here, unfortunately (I find XSLT really nice as idea).
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Posted by Joerg Heinicke <jo...@gmx.de>.
On 16.07.2007 04:58, Daniel Fagerstrom wrote:
>> Actually I'm not very keen on any templating approach at all.
>
> I prefer a push approach as well. But this project is not about creating
> the ideal template framework.
You digress :-) I did not want to get into this discussion about the
best approach at all. I only wanted to point out that there are
different approaches to do things, where you don't have an EL available,
so where variants can't be used. That's why I'd like to see at least a
combined path/variant approach instead of a variant-only approach. OTOH
switching to a path-only approach seems also not possible since this
can't handle all use cases as you outlined with the multiple date
representations.
Joerg
Re: Clarification on converter concept
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Joerg Heinicke skrev:
> On 13.07.2007 10:31, Grzegorz Kossakowski wrote:
...
> Actually I'm not very keen on any templating approach at all. I don't
> like to first provide data to some template context and second
> retrieve it from there in the template. IMO it's much better to have a
> complete push approach and only encroach if it is necessary (like XSLT
> templates). (My diploma thesis was about this btw.)
I prefer a push approach as well. But this project is not about creating
the ideal template framework. It is about keeping back compatibility and
at the same time giving users a simpler and cleaner way forward for new
development and possible refactoring of old stuff.
AFAIU, it will be possible to use the object model without any default
content, (is that true Grzegorz?). In such a scenario you can have a
pure push approach, by only pushing the data that should be rendered
into the object model.
> A possible implementation for this is to convert the form model into
> an XML representation
Not everything is in forms. We need a mechanism for rendering model data
without connecting it to a form.
> and let a quite generic XSLT do the rest. With this approach no EL
> come into play. This also means there is a separate object-to-string
> step.
I preferred that kind of solution once. But now I find it unnecessary
complicated in most cases. The first problem is that it requires some
work to convert bean structure to XML data. You will probably need some
configuration file that handle part of the conversion. In comparison to
just applying an EL to a bean structure it is more complicated. Second,
many people find XSLT much more complicated than a simple template
language. Third, the development of XSLT processors and tooling, has
been a disappointment. Xalan, still doesn't implement XSLT 2.0, and the
error messages from both Xalan and Saxon can often be cryptic or non
existent.
In the end XSLT has its uses, but for simple rendering of beans I find
simple template languages like JXTG much more productive (and I have
written tons of XSLT).
/Daniel
Re: Clarification on converter concept
Posted by Joerg Heinicke <jo...@gmx.de>.
On 13.07.2007 10:31, Grzegorz Kossakowski wrote:
>>> In a state full scenario we are keeping the form object in e.g. a
>>> session, so the form template generator could store the associations
>>> between property paths and formating variants in the form object as
>>> well.
>>
>> Doesn't that tie both CForms and CTemplate together?
>
> My understanding is that this approach ties CForms to EL and CTemplate
> to EL so EL functionality becomes a bridge for two way communication.
This is indeed more exact. I considered EL being part of CTemplate :-)
> I also wonder how you are going to use CForms without CTemplate? You
> must use some template mechanism to produce data representing form and
> its state.
FormsTransformer? It has a template approach as well [1], but no EL at all.
Actually I'm not very keen on any templating approach at all. I don't
like to first provide data to some template context and second retrieve
it from there in the template. IMO it's much better to have a complete
push approach and only encroach if it is necessary (like XSLT
templates). (My diploma thesis was about this btw.) A possible
implementation for this is to convert the form model into an XML
representation and let a quite generic XSLT do the rest. With this
approach no EL come into play. This also means there is a separate
object-to-string step.
>>> In a stateless scenario, we could instead store the assoications in
>>> the form page.
>>
>> IMO it should always work this way, not like the above one for
>> stateful form-processing.
>
> This would make whole processing easier to follow, wouldn't it?
Difference should not be that big since it's more an implementation
detail than something that should concern the user. My main reasoning
was the decoupling of EL and CForms.
>> And actually we are back to the Spring way using the path, aren't we?
>> There is only the minor difference of using the full path vs. the
>> anchor. The anchor adds additional flexibility since it can be
>> specified in contrary to the generated path.
>
> My impression is that there is a more serious difference between the
> concepts. While using Daniel's approach you attach converter to the
> certain path by choosing its variant when you actually pull the data. It
> doesn't matter if you pull it in form model or template.
> Spring approach is about attaching everything in advance.
That's true. It's the controller that decides which converters get
applied, not the view.
The "minor difference" I talked about was from the registry POV.
Something is just asking for a converter, the only difference is the
string which is used for retrieving the converter then.
> Then it turns out that Daniel's proposal is about registering several
> converters for every possible path and use variant to choose one from
> the list (if default is not satisfying). Since, it's all about
> registering for every possible path (assuming that there is suitable
> converter for each object) and registering more than one converter it's
> conceptually different from Spring's approach.
Hmm, not really. Even with the current default implementation you can
register multiple converters per path differing in the type. You just
add another criteria. What's different is the more complex understanding
of "path" since you might include the variant in it. Seems to be only a
matter of registry implementation how it stores and finds converters.
> I hope that paragraph didn't confuse things even more...
I needed to read it twice but I think I got the message :-)
>> So how far are we from an overall agreement and Grek implementing this
>> for us ;-)
>
> I would happy to do it, but I'd be very grateful if we come with strong
> and detailed agreement.
I didn't want to put any pressure on you ;-) Just wondered what the open
issues are we still have.
Joerg
[1] http://cocoon.apache.org/2.1/userdocs/publishing/templating.html
Re: Clarification on converter concept
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
>> In a state full scenario we are keeping the form object in e.g. a
>> session, so the form template generator could store the associations
>> between property paths and formating variants in the form object as
>> well. These associations are then available to use when parsing the
>> input from the post. And we can make sure that the right variant of
>> the converter is used.
>
> Doesn't that tie both CForms and CTemplate together? Imagine using only
> one of both - which would break the concept.
My understanding is that this approach ties CForms to EL and CTemplate to EL so EL functionality becomes a bridge for two way communication.
I also wonder how you are going to use CForms without CTemplate? You must use some template mechanism to produce data representing form and
its state.
>> In a stateless scenario, we could instead store the assoications in
>> the form page. We could e.g. add it to the property path in the name
>> attribute: "tasks.2.startDate#short". Then the post parser can use the
>> variant info for choosing the right converter.
>
> That's an interesting approach. IMO it should always work this way, not
> like the above one for stateful form-processing.
Same feelings here. This would make whole processing easier to follow, wouldn't it?
> And actually we are back to the Spring way using the path, aren't we?
> There is only the minor difference of using the full path vs. the
> anchor. The anchor adds additional flexibility since it can be specified
> in contrary to the generated path.
My impression is that there is a more serious difference between the concepts. While using Daniel's approach you attach converter to the
certain path by choosing its variant when you actually pull the data. It doesn't matter if you pull it in form model or template.
Spring approach is about attaching everything in advance.
> I only really don't know if that flexibility is good. I mean you talked
> about scattered locale handling. This solution now tends to scattered
> variant handling IMO. I also don't know how it conforms with Parr's
> requirements for a template language. Doesn't this variant selection go
> very much into the direction of assumption about the data type?
>
> I can live with this concept but actually I prefer the path stuff of
> Spring much more since this is completely transparent to the template.
> It also completely decouples the object-to-string conversion from the
> templating while with the "select a variant"-approach in the template
> the conversion can not be done without the template.
Both are good points. I would be very interested in Daniel's response...
>> It would be like having id selectors but not class selectors in CSS.
>
> I think this comparison is misleading. IMO path and variant are really
> similar concepts. It's only the way where/how they were specified and so
> the converter is selected.
I support Daniel's view. You can apply certain variant to several different paths. Actually, the point is that we could treat Daniel's
proposal in Spring terms.
Then it turns out that Daniel's proposal is about registering several converters for every possible path and use variant to choose one from
the list (if default is not satisfying). Since, it's all about registering for every possible path (assuming that there is suitable
converter for each object) and registering more than one converter it's conceptually different from Spring's approach.
I hope that paragraph didn't confuse things even more...
> The new approach using PropertyEditorRegistrar externalizes this into
> another component. But that one has no access to the request information
> and so can not even create locale-specific converters. What I know asked
> myself: How I am supposed to do this at all with Spring? I will file an
> issue at Spring's Jira requesting an improvement about a locale-aware
> registry. My hope is that this might get fixed for Spring 2.1 since I
> consider this really important and generic enough to be of use in Spring
> in general. Then we do not even need to modify/ replace this part of
> Spring's converter infrastructure.
>
> Otherwise I would reuse as much as possible of this infrastructure
> though. It's only the registry part that needs modification/
> replacement. Therefore dropping the complete infrastructure does not
> make much sense IMO.
>
> So how far are we from an overall agreement and Grek implementing this
> for us ;-)
I would happy to do it, but I'd be very grateful if we come with strong and detailed agreement. I started to implement Object Model several
days ago without detailed vision and the whole development turned out to be fairly painful because I found hard to design something that
covers so broad subject like universal Object Model usable for whole Cocoon.
I hope it will be easier with converters because all this struggle scared me a little bit.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Daniel Fagerstrom wrote:
...
> A particular date could be presented
> both in its short form in a table and in its long form in a text. That
> is clearly a presentation issue.
>
> A specific double in a model should normally not represent both a
> percentage, a currency amount and a scientific value, what it represents
> is clearly a model issue.
This particular double, *can* potentially have multiple representations (even on
the same page). Example - 2 and 4 positions after the dot: 0.11 and 0.1111;
negative with '-' or negative in parenthesis '()': -123 and (123); with leading
0 or without: .123 and 0.123; scientific representation; etc.
So I'd say double in no way different from date.
Vadim
Re: Clarification on converter concept
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Joerg Heinicke skrev:
> On 14.07.2007 15:55, Daniel Fagerstrom wrote:
...
>>> Doesn't this variant selection go very much into the direction of
>>> assumption about the data type?
>> It is up to the user. The user could as an example have a "short"
>> variant for the short form of a couple of different data types.
> This argument is a bit lousy, isn't it? ;-)
I don't see that an assumption about what kind of concept you are
accessing should be a problem, but we should definitively avoid low
level assumptions. As an example: I don't see any problem with letting
the template author knowing that something is a date, and optionally
make it possible to chose between different visual presentations. But
the template author should not need to be aware about differences
between java.sql.Date, java.util.Date and a custom date type.
>>> It also completely decouples the object-to-string conversion from
>>> the templating while with the "select a variant"-approach in the
>>> template the conversion can not be done without the template.
>>
>> That is an implementation detail. We have an object model that an
>> expression language can be applied on where the result in turn can be
>> converted by a converter and the result in turn can be used in a
>> template. We have 4 different parts that can be used both together
>> and in parts if implemented in the right way.
>
> For me it's 1. object model, 2. object-to-string conversion and 3.
> referencing the value in the template via the EL. If the EL influences
> the conversion 2. and 3. are coupled. That's not just an
> implementation detail.
No, the object to string conversion is done on the result from the EL,
not the other way around. The "#variant" is not part of the EL, it is
part of a separate "converter language".
...
/Daniel
Re: Clarification on converter concept
Posted by Joerg Heinicke <jo...@gmx.de>.
On 14.07.2007 15:55, Daniel Fagerstrom wrote:
> The main difference in my view is that with paths the choice of
> presentation is connected to the model and with anchors it is connected
> to the presentation.
Ok, I agree.
> Both cases have legitimate uses. A particular date could be presented
> both in its short form in a table and in its long form in a text. That
> is clearly a presentation issue.
I'd really like to involve Spring guys here. I'm interested how they
think this can be solved.
>> Doesn't this variant selection go very much into the direction of
>> assumption about the data type?
>
> It is up to the user. The user could as an example have a "short"
> variant for the short form of a couple of different data types.
This argument is a bit lousy, isn't it? ;-)
>> It also completely decouples the object-to-string conversion from the
>> templating while with the "select a variant"-approach in the template
>> the conversion can not be done without the template.
>
> That is an implementation detail. We have an object model that an
> expression language can be applied on where the result in turn can be
> converted by a converter and the result in turn can be used in a
> template. We have 4 different parts that can be used both together and
> in parts if implemented in the right way.
For me it's 1. object model, 2. object-to-string conversion and 3.
referencing the value in the template via the EL. If the EL influences
the conversion 2. and 3. are coupled. That's not just an implementation
detail.
> Further, using an EL and format variants on a bean model would
> probably be possible for a web designer. Writing Spring bean
> configurations seem to be a little bit to much.
I agree that the different date representations are presentation issues,
not model issue. I don't have any solution for it except those variants.
> Also if you have e.g. a regexp defined format, will you need to repeat
> it for each property path you would like to apply it on?
You don't need to. Similar to the setup of the "short" variant you can
set up the regexp-defined editor. You only would need to reference it
multiple times in the bean definition as shown with my
MapBasedPropertyEditorRegistrar sample [1]. That's similar to
referencing "short" in the EL.
>> There is indeed no way to select a converter based on the locale at
>> the moment.
>
> To me this sounds like Spring doesn't have a satisfying solution to the
> locale problem right now.
Didn't I confirm this already? :-)
That's the second thing I'd like to get Spring community involved.
Joerg
[1] http://marc.info/?l=xml-cocoon-dev&m=118438238711044&w=4
Re: Clarification on converter concept
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Joerg Heinicke skrev:
> On 07.07.2007 11:16, Daniel Fagerstrom wrote:
>
...
>> The form infrastructure creates two property paths from the id. One
>> for accessing the start date from the form object to insert in the
>> generated html page. And one property path is used as content of the
>> name attribute in the generated html form element.
>
> Can't quite follow. Isn't that supposed to be the same one? I mean when
> the path is used as form field's name it ends as request parameter name.
> That one needs to be used to bind the value to the form object correctly.
What I meant is that the property path is of course the same for both
read and write access, but its representation is different in CForms for
the both cases. For reading it is doesn't have any explicit form but is
only implicitly represented in the tag structure for a CForm. For write
access it has the mentioned (e.g. "tasks.2.startDate") form in the name
attribute of the generated html form tag.
...
> And actually we are back to the Spring way using the path, aren't we?
> There is only the minor difference of using the full path vs. the
> anchor. The anchor adds additional flexibility since it can be specified
> in contrary to the generated path.
The main difference in my view is that with paths the choice of
presentation is connected to the model and with anchors it is connected
to the presentation.
Both cases have legitimate uses. A particular date could be presented
both in its short form in a table and in its long form in a text. That
is clearly a presentation issue.
A specific double in a model should normally not represent both a
percentage, a currency amount and a scientific value, what it represents
is clearly a model issue. And we are probably only having one
presentation for each representation, so the path idea is better in this
case.
From a OO purist POV, there should be own classes for currency amounts,
percentages and so on, so we wouldn't have to care about variant
representations at all in this case. But as Java isn't a pure OO
language, such a purist view isn't practically feasible, we need
variants in this case as well.
> I only really don't know if that flexibility is good. I mean you talked
> about scattered locale handling. This solution now tends to scattered
> variant handling IMO. I also don't know how it conforms with Parr's
> requirements for a template language. Doesn't this variant selection go
> very much into the direction of assumption about the data type?
It is up to the user. The user could as an example have a "short"
variant for the short form of a couple of different data types.
> I can live with this concept but actually I prefer the path stuff of
> Spring much more since this is completely transparent to the template.
In the date case where there are several different presentations of the
same concept it is part of the presentation concern and shouldn't be
separated from the template.
> It also completely decouples the object-to-string conversion from the
> templating while with the "select a variant"-approach in the template
> the conversion can not be done without the template.
That is an implementation detail. We have an object model that an
expression language can be applied on where the result in turn can be
converted by a converter and the result in turn can be used in a
template. We have 4 different parts that can be used both together and
in parts if implemented in the right way.
> The question is what we lose when refraining from the variant: Only the
> possibility to use one property of the object twice in a template and
> format it differently.
That is an important thing that we would lose. As described above we
would lose the ability to chose between different presentations in the
view. Further, using an EL and format variants on a bean model would
probably be possible for a web designer. Writing Spring bean
configurations seem to be a little bit to much.
Also if you have e.g. a regexp defined format, will you need to repeat
it for each property path you would like to apply it on?
> Anything else is addressed in Spring. So you can
> register form-specific converters. That's also how I handle it when I
> register converters for a particular path. In contrary type-specific
> converters are registered globally. (Where "globally" is not quite
> correct since the converters are prototypes anyway. The registration is
> a topic on its own below.)
>
>>> The property path could be used to determine the variant instead of
>>> specifying it explicitly. It's obviously not that flexible - but
>>> can't be broken in that way. That's why I would opt for class, locale
>>> and path, so add locale to Spring's PropertyEditorRegistry methods.
>>
>> It would be like having id selectors but not class selectors in CSS.
>
> I think this comparison is misleading.
Class selectors in CSS was the inspiration for the variants.
> IMO path and variant are really
> similar concepts. It's only the way where/how they were specified and so
> the converter is selected.
>
>> As we need handling of ELs, we could use "property paths" that
>> includes the format variant e.g. "foo.bar#short" or even just
>> "#short". The later for applying the beanEditor when the "short"
>> variant is asked for.
>
> Yes, a combination of both (very similar) concepts seems to be possible
> easily.
>
>> Do you mean that you agree about that it is unclear how to handle
>> locals with the bean wrapper stuff? Or are you starting to see some
>> solution?
>
> Both actually. I try to rephrase the confusing paragraph ...
>
> There is indeed no way to select a converter based on the locale at the
> moment. What you can do though is to register a locale-specific
> converter based on the request information (remember the initBinder() in
> my last mail). But this approach is really awkward since you need to do
> this in every controller you write. That's why I wrote "So you might
> drop that complete section from mind :-)".
>
> The new approach using PropertyEditorRegistrar externalizes this into
> another component. But that one has no access to the request information
> and so can not even create locale-specific converters. What I know asked
> myself: How I am supposed to do this at all with Spring? I will file an
> issue at Spring's Jira requesting an improvement about a locale-aware
> registry. My hope is that this might get fixed for Spring 2.1 since I
> consider this really important and generic enough to be of use in Spring
> in general. Then we do not even need to modify/ replace this part of
> Spring's converter infrastructure.
> Otherwise I would reuse as much as possible of this infrastructure
> though. It's only the registry part that needs modification/
> replacement. Therefore dropping the complete infrastructure does not
> make much sense IMO.
To me this sounds like Spring doesn't have a satisfying solution to the
locale problem right now.
PropertyEditors and BeanWrapper could be usable, but the registry
architecture in Spring just don't help us currently.
/Daniel
Re: Clarification on converter concept
Posted by Joerg Heinicke <jo...@gmx.de>.
On 07.07.2007 11:16, Daniel Fagerstrom wrote:
>> As I wrote repeatedly the possibility to influence the formatting from
>> the template breaks the two-way process.
>
> First, from a separation of concern POV, it is IMO much preferable to
> influence the formating variant, both for output and input, in the form
> template.
>
> Second, we have the question if it is possible to accomplish ;) Yes, I
> think it is.
>
> The form infrastructure creates two property paths from the id. One for
> accessing the start date from the form object to insert in the generated
> html page. And one property path is used as content of the name
> attribute in the generated html form element.
Can't quite follow. Isn't that supposed to be the same one? I mean when
the path is used as form field's name it ends as request parameter name.
That one needs to be used to bind the value to the form object correctly.
> So from the above we see that the form template actually create the
> property path that is used both for getting and setting the property in
> the form model that the widget is connected to.
Yes, clear so far. Spring MVC does it very similar btw.
> From this we are not that far away from connecting formatting variant
> to the property path.
>
> In a state full scenario we are keeping the form object in e.g. a
> session, so the form template generator could store the associations
> between property paths and formating variants in the form object as
> well. These associations are then available to use when parsing the
> input from the post. And we can make sure that the right variant of the
> converter is used.
Doesn't that tie both CForms and CTemplate together? Imagine using only
one of both - which would break the concept.
> In a stateless scenario, we could instead store the assoications in the
> form page. We could e.g. add it to the property path in the name
> attribute: "tasks.2.startDate#short". Then the post parser can use the
> variant info for choosing the right converter.
That's an interesting approach. IMO it should always work this way, not
like the above one for stateful form-processing.
And actually we are back to the Spring way using the path, aren't we?
There is only the minor difference of using the full path vs. the
anchor. The anchor adds additional flexibility since it can be specified
in contrary to the generated path.
I only really don't know if that flexibility is good. I mean you talked
about scattered locale handling. This solution now tends to scattered
variant handling IMO. I also don't know how it conforms with Parr's
requirements for a template language. Doesn't this variant selection go
very much into the direction of assumption about the data type?
I can live with this concept but actually I prefer the path stuff of
Spring much more since this is completely transparent to the template.
It also completely decouples the object-to-string conversion from the
templating while with the "select a variant"-approach in the template
the conversion can not be done without the template.
The question is what we lose when refraining from the variant: Only the
possibility to use one property of the object twice in a template and
format it differently. Anything else is addressed in Spring. So you can
register form-specific converters. That's also how I handle it when I
register converters for a particular path. In contrary type-specific
converters are registered globally. (Where "globally" is not quite
correct since the converters are prototypes anyway. The registration is
a topic on its own below.)
>> The property path could be used to determine the variant instead of
>> specifying it explicitly. It's obviously not that flexible - but can't
>> be broken in that way. That's why I would opt for class, locale and
>> path, so add locale to Spring's PropertyEditorRegistry methods.
>
> It would be like having id selectors but not class selectors in CSS.
I think this comparison is misleading. IMO path and variant are really
similar concepts. It's only the way where/how they were specified and so
the converter is selected.
> As we need handling of ELs, we could use "property paths" that includes
> the format variant e.g. "foo.bar#short" or even just "#short". The later
> for applying the beanEditor when the "short" variant is asked for.
Yes, a combination of both (very similar) concepts seems to be possible
easily.
> Do you mean that you agree about that it is unclear how to handle
> locals with the bean wrapper stuff? Or are you starting to see some
> solution?
Both actually. I try to rephrase the confusing paragraph ...
There is indeed no way to select a converter based on the locale at the
moment. What you can do though is to register a locale-specific
converter based on the request information (remember the initBinder() in
my last mail). But this approach is really awkward since you need to do
this in every controller you write. That's why I wrote "So you might
drop that complete section from mind :-)".
The new approach using PropertyEditorRegistrar externalizes this into
another component. But that one has no access to the request information
and so can not even create locale-specific converters. What I know asked
myself: How I am supposed to do this at all with Spring? I will file an
issue at Spring's Jira requesting an improvement about a locale-aware
registry. My hope is that this might get fixed for Spring 2.1 since I
consider this really important and generic enough to be of use in Spring
in general. Then we do not even need to modify/ replace this part of
Spring's converter infrastructure.
Otherwise I would reuse as much as possible of this infrastructure
though. It's only the registry part that needs modification/
replacement. Therefore dropping the complete infrastructure does not
make much sense IMO.
So how far are we from an overall agreement and Grek implementing this
for us ;-)
Regards,
Joerg
Re: Clarification on converter concept
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
>> What about map: language we have discussed earlier?
>
> How is it related? Or does map: mean something different here than the
> default sitemap language namespace prefix?
Yes, it means something different, see:
http://article.gmane.org/gmane.text.xml.cocoon.devel/73700
http://article.gmane.org/gmane.text.xml.cocoon.devel/73760
I've brought map expression language back to discussion to show that we effectively need more than one EL.
>> Getting back to the earth, are you sure that all browsers will be
>> happy with # character in field's name?
>
> HTML spec nearly makes no restrictions for name attribute, it's declared
> as CDATA [1, 2]. [2] though mentions explicitly ID and *NAME* tokens
> which are defined quite restrictive, so that's a bit confusing.
>
> Spring MVC also generates names like object.collection[3].property
> instead of CForms object.collection.3.property. Being declared as CDATA
> I wonder what the browsers do with an = in a form field's name.
>
> Anyway we should not only have name but also id in mind [3]. Not much is
> allowed for them [4]. Except some rather obscure "combining chars" and
> "extenders" only '.', '-', '_' and ':'. So the last one might be the
> best choice.
Thanks for analysis. It seems that Daniel's proposal is even possible to implement, good to know. :-)
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Posted by Joerg Heinicke <jo...@gmx.de>.
On 08.07.2007 06:34, Grzegorz Kossakowski wrote:
>> Just to clarify: I would much have preferred if we only had one
>> expression language (EL) in Cocoon and a property style syntax like
>> the Spring one or JEXL would be fine with me.
>>
>> This is the main motivation for the plugable EL architecture.
>
> What about map: language we have discussed earlier?
How is it related? Or does map: mean something different here than the
default sitemap language namespace prefix?
> Getting back to the earth, are you sure that all browsers will be happy
> with # character in field's name?
HTML spec nearly makes no restrictions for name attribute, it's declared
as CDATA [1, 2]. [2] though mentions explicitly ID and *NAME* tokens
which are defined quite restrictive, so that's a bit confusing.
Spring MVC also generates names like object.collection[3].property
instead of CForms object.collection.3.property. Being declared as CDATA
I wonder what the browsers do with an = in a form field's name.
Anyway we should not only have name but also id in mind [3]. Not much is
allowed for them [4]. Except some rather obscure "combining chars" and
"extenders" only '.', '-', '_' and ':'. So the last one might be the
best choice.
Joerg
[1] http://www.w3.org/TR/html401/interact/forms.html#h-17.4
[2] http://www.w3.org/TR/html401/types.html#h-6.2
[3] http://www.w3.org/TR/2006/REC-xml-20060816/#id
[4] http://www.w3.org/TR/2006/REC-xml-20060816/#NT-NameChar
Re: Clarification on converter concept
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
>
> Just to clarify: I would much have preferred if we only had one
> expression language (EL) in Cocoon and a property style syntax like the
> Spring one or JEXL would be fine with me.
>
> But as ELs are used everywhere in Cocoon webapps, most users have a
> heavy investment in the current set of ELs. So we just cannot deprecate
> them and require all the users to rewrite all their webapps to the new
> "better" EL at one go. We need a mechanism that simplify for new users
> and new webapps by making it easy to use one default EL everywhere at
> the same time that we don't require users to rewrite their old webapps.
>
> This is the main motivation for the plugable EL architecture.
What about map: language we have discussed earlier? I think it makes sense to have such a domain-specific, damn simple language. If it takes
ten minutes to learn such a language and it improves readability, I think it makes to have one. Having bunch of general ELs is what I want
to avoid too.
> First, from a separation of concern POV, it is IMO much preferable to
> influence the formating variant, both for output and input, in the form
> template.
>
> Second, we have the question if it is possible to accomplish ;) Yes, I
> think it is. Consider a form template, where you have various widgets:
>
> <ft:widget id="startDate">
> <fi:styling type="short"/>
> <ft:widget/>
>
> The form infrastructure creates two property paths from the id. One for
> accessing the start date from the form object to insert in the generated
> html page. And one property path is used as content of the name
> attribute in the generated html form element. The name attribute is then
> used by the browser when posting the filled in value of the form
> element. In the case of nested widgets, the property path is created
> from all the ids of the parent widget as well, so we can have property
> paths like tasks.2.startDate, if the start date is part of a task list,
> e.g.
>
> So from the above we see that the form template actually create the
> property path that is used both for getting and setting the property in
> the form model that the widget is connected to. From this we are not
> that far away from connecting formatting variant to the property path.
>
> In a state full scenario we are keeping the form object in e.g. a
> session, so the form template generator could store the associations
> between property paths and formating variants in the form object as
> well. These associations are then available to use when parsing the
> input from the post. And we can make sure that the right variant of the
> converter is used.
>
> In a stateless scenario, we could instead store the assoications in the
> form page. We could e.g. add it to the property path in the name
> attribute: "tasks.2.startDate#short". Then the post parser can use the
> variant info for choosing the right converter.
That's a really neat idea! I have not thought about it that way and I really like it! :-)
> So as you can see it is possible to put the choice of formatting variant
> in the form template so that the two-way aspect is respected.
Getting back to the earth, are you sure that all browsers will be happy with # character in field's name?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Joerg Heinicke skrev:
> On 05.07.2007 00:47, Grzegorz Kossakowski wrote:
...
>>> I always found the JEXL/JXPath syntax rather counterintuitive.
>>
>> What was counter-intuitive apart from switching between both that I do
>> not like either?
>
> The ${} and #{}, the impedance mismatch between objects and xml model:
> JXPath on beans does not behave like on xml.
>
>> How Spring syntax looks like and how it is better than JXPath/JEXL?
>
> Bean property syntax which as used in other template languages like
> Velocity and scripting languages as well: object1.object2.property.
Just to clarify: I would much have preferred if we only had one
expression language (EL) in Cocoon and a property style syntax like the
Spring one or JEXL would be fine with me.
But as ELs are used everywhere in Cocoon webapps, most users have a
heavy investment in the current set of ELs. So we just cannot deprecate
them and require all the users to rewrite all their webapps to the new
"better" EL at one go. We need a mechanism that simplify for new users
and new webapps by making it easy to use one default EL everywhere at
the same time that we don't require users to rewrite their old webapps.
This is the main motivation for the plugable EL architecture.
...
> On 05.07.2007 14:24, Daniel Fagerstrom wrote:
...
>> Converter Registry
>> ----------
>
>> For a Cocoon framework I would prefer looking up a converter based on
>> class, locale and variant, while I don't see any obvious use cases for
>> property path.
>
> Indeed the PropertyEditorRegistry seems not to meet our requirements.
>
> (copied from further above, better fits in here)
>> The framework select based on data type and locale. But for e.g. dates
>> there are several different string representations (short, medium, full
>> and long or maybe some custom format) that the template or form author
>> needs to choose between. To me it seem reasonable to have a syntax for
>> making this possible in e.g. the template.
>
> As I wrote repeatedly the possibility to influence the formatting from
> the template breaks the two-way process. You can't parse a date
> expecting a FULL pattern string when receiving a string formatted with
> SHORT pattern. And there is no chance to get informed about this mismatch.
First, from a separation of concern POV, it is IMO much preferable to
influence the formating variant, both for output and input, in the form
template.
Second, we have the question if it is possible to accomplish ;) Yes, I
think it is. Consider a form template, where you have various widgets:
<ft:widget id="startDate">
<fi:styling type="short"/>
<ft:widget/>
The form infrastructure creates two property paths from the id. One for
accessing the start date from the form object to insert in the generated
html page. And one property path is used as content of the name
attribute in the generated html form element. The name attribute is then
used by the browser when posting the filled in value of the form
element. In the case of nested widgets, the property path is created
from all the ids of the parent widget as well, so we can have property
paths like tasks.2.startDate, if the start date is part of a task list, e.g.
So from the above we see that the form template actually create the
property path that is used both for getting and setting the property in
the form model that the widget is connected to. From this we are not
that far away from connecting formatting variant to the property path.
In a state full scenario we are keeping the form object in e.g. a
session, so the form template generator could store the associations
between property paths and formating variants in the form object as
well. These associations are then available to use when parsing the
input from the post. And we can make sure that the right variant of the
converter is used.
In a stateless scenario, we could instead store the assoications in the
form page. We could e.g. add it to the property path in the name
attribute: "tasks.2.startDate#short". Then the post parser can use the
variant info for choosing the right converter.
So as you can see it is possible to put the choice of formatting variant
in the form template so that the two-way aspect is respected.
> The property path could be used to determine the variant instead of
> specifying it explicitly. It's obviously not that flexible - but can't
> be broken in that way. That's why I would opt for class, locale and
> path, so add locale to Spring's PropertyEditorRegistry methods.
It would be like having id selectors but not class selectors in CSS. But
as we saw choosing format variant in format templates is possible.
As we need handling of ELs, we could use "property paths" that includes
the format variant e.g. "foo.bar#short" or even just "#short". The later
for applying the beanEditor when the "short" variant is asked for.
>> So as a conclusion: it would be nice to reuse the Spring stuff and
>> there are big overlaps, but especially for locale handling it is not
>> obvious to me how to use it. Then of course there is the question if
>> it is worthwhile to reuse.
>
> The concepts seem to be totally equal. We only extend the registry with
> the locale. Then I mentioned a new way of registering PropertyEditors,
> the PropertyEditorRegistrar. That's actually a PropertyEditor factory
> which also does the registering shown above when talking about the
> initBinder() method. It is possible to set up such a registrar once (!)
> in the application context and reuse it in the application context
> itself (e.g. for custom data types) or in the controllers. The point I
> want to make is the following: This PropertyEditorRegistrar is in
> contrary to initBinder() not even request-aware and so not locale-aware
> at all. So I wonder how it is supposed to be done in Spring now. Maybe
> filing an issue for an extension of the registry brings this into 2.1
> and we do not have to invent anything new. And even if not there is
> still so much to reuse and it's IMO absolutely worthwile to do it.
I'm not able to parse the above paragraph. Do you mean that you agree
about that it is unclear how to handle locals with the bean wrapper
stuff? Or are you starting to see some solution?
> I hope, I did not write too much non-sense in my hurry. Have to get to
> the plane to the US (finally!) soon. Maybe I could even clarify a bit of
> the confusion I caused with the last mail. :-)
You clarified a lot.
/Daniel
Re: Cocoon Spring configurator
Posted by Joerg Heinicke <jo...@gmx.de>.
On 19.08.2007 11:56 Uhr, Reinhard Poetz wrote:
>>> /META-INF/cocoon/spring when using Cocoon Spring configurator
>>> independently from Cocoon.
>>> It's probably not that hard to change but we should do it before
>>> propagating it :)
>>
>> There are constants defined in
>> org.apache.cocoon.spring.configurator.impl.Constants.
>>
>> So changing this is very simple. The whole loading is done through own
>> xml elements (the "settings" element). Most classes in
>> org.apache.cocoon.spring.configurator.impl deals with this stuff.
>
> That means that we can make this a configuration option of the settings
> element and its default value is "META-INF/cocoon/spring", right?
That's what I understood.
Joerg
Re: Cocoon Spring configurator
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>>> /META-INF/cocoon/spring when using Cocoon Spring configurator
>>> independently from
>>> Cocoon. It's probably not that hard to change but we should do it before
>>> propagating it :)
>> There are constants defined in
>> org.apache.cocoon.spring.configurator.impl.Constants.
>>
>> So changing this is very simple. The whole loading is done through own
>> xml elements (the "settings" element). Most classes in
>> org.apache.cocoon.spring.configurator.impl deals with this stuff.
>
> That means that we can make this a configuration option of the settings
> element and its default value is "META-INF/cocoon/spring", right?
The best thing is that we already have this :)
you can embed "include-beans" and "include-properties" in the settings
element which allow you to read the configuration from additional locations.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Cocoon Spring configurator
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
>> /META-INF/cocoon/spring when using Cocoon Spring configurator independently from
>> Cocoon. It's probably not that hard to change but we should do it before
>> propagating it :)
> There are constants defined in
> org.apache.cocoon.spring.configurator.impl.Constants.
>
> So changing this is very simple. The whole loading is done through own
> xml elements (the "settings" element). Most classes in
> org.apache.cocoon.spring.configurator.impl deals with this stuff.
That means that we can make this a configuration option of the settings element
and its default value is "META-INF/cocoon/spring", right?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Cocoon Spring configurator
Posted by Carsten Ziegeler <cz...@apache.org>.
Joerg Heinicke wrote:
> Carsten Ziegeler <cziegeler <at> apache.org> writes:
>
> Carsten, when I recommended the bean map today [1] I wondered how it actually
> works. The documentation talks about jar drop-in [2] which does not seem to be
> the full truth. Please correct me if I'm wrong ...
:)
>
> The BeanMap looks for all beans of a particular type. Therefore the beans needs
> to be registered in the application context.
Yes, that's true - so you can use the bean map "standalone" without
using anything else from the configurator.
> So far so good, but here I think
> the drop-in fails. Even if the jar includes the configuration the bean does not
> get added automatically to the application context. Only the other parts of
> Cocoon Spring configurator enable this functionality. (If that's correct this
> should better be added to the BeanMap documentation.)
Yes, that's true - the bean map is just a map of some registered beans.
Together with the other functionality of the spring configurator you get
the automatic configuration stuff - and if such a configuration
contains beans for the map, they are added to the map of course.
Yepp, I think this needs some clarifications in the docs.
> Which class exactly does
> this? And how much stuff is hard-coded in it? You don't want to have paths like
> /META-INF/cocoon/spring when using Cocoon Spring configurator independently from
> Cocoon. It's probably not that hard to change but we should do it before
> propagating it :)
There are constants defined in
org.apache.cocoon.spring.configurator.impl.Constants.
So changing this is very simple. The whole loading is done through own
xml elements (the "settings" element). Most classes in
org.apache.cocoon.spring.configurator.impl deals with this stuff.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Cocoon Spring configurator
Posted by Joerg Heinicke <jo...@gmx.de>.
Carsten Ziegeler <cziegeler <at> apache.org> writes:
> Ah, great, yes bean map has been added later - I'll document it in the
> next days.
Carsten, when I recommended the bean map today [1] I wondered how it actually
works. The documentation talks about jar drop-in [2] which does not seem to be
the full truth. Please correct me if I'm wrong ...
The BeanMap looks for all beans of a particular type. Therefore the beans needs
to be registered in the application context. So far so good, but here I think
the drop-in fails. Even if the jar includes the configuration the bean does not
get added automatically to the application context. Only the other parts of
Cocoon Spring configurator enable this functionality. (If that's correct this
should better be added to the BeanMap documentation.) Which class exactly does
this? And how much stuff is hard-coded in it? You don't want to have paths like
/META-INF/cocoon/spring when using Cocoon Spring configurator independently from
Cocoon. It's probably not that hard to change but we should do it before
propagating it :)
Regards,
Joerg
[1] http://forum.springframework.org/showthread.php?t=42701
[2] http://cocoon.zones.apache.org/daisy/cdocs-spring-configurator/g1/1400.html
Re: Clarification on converter concept
Posted by Carsten Ziegeler <cz...@apache.org>.
Joerg Heinicke wrote:
> Issue 3 to hand in there :)
:)
> Ok, I just did not found anything about the bean map. And compared the
> number of classes (20+) with the number of pages regarding functionality
> (4: running modes, property handling, bean configuration, log4j). Maybe
> I jumped the conclusions :-) They main topics seem indeed to be covered,
> only (?) bean map docs are missing.
Ah, great, yes bean map has been added later - I'll document it in the
next days.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Clarification on converter concept
Posted by Joerg Heinicke <jo...@gmx.de>.
On 16.07.2007 02:48, Carsten Ziegeler wrote:
>> Hmm, was the first time I had a look into it today.
>
> Really? :)
Unfortunately :(
> So if anyone thinks that it makes sense to promote this stuff
> "somewhere", let's do it :)
Issue 3 to hand in there :)
>> For the latter it would be good to have documented what's
>> there and how it is supposed to be used. The documentation at Daisy is a
>> bit spare.
> Hmm, I haven't looked at the docs recently, but I thought i had
> documented everything which is in it.
Ok, I just did not found anything about the bean map. And compared the
number of classes (20+) with the number of pages regarding functionality
(4: running modes, property handling, bean configuration, log4j). Maybe
I jumped the conclusions :-) They main topics seem indeed to be covered,
only (?) bean map docs are missing.
Joerg
Re: Clarification on converter concept
Posted by Carsten Ziegeler <cz...@apache.org>.
Joerg Heinicke wrote:
>> Spring configurator stuff is really handy and has no Cocoon
>> dependencies so its wise to use it. Joerg, you seem to sit inside
>> Spring community, have you considered giving Carsten a present by
>> promoting his stuff? I really think it should get more attention. :-)
>
> Hmm, was the first time I had a look into it today.
Really? :)
> I can't say if this
> all is of general use. Do you think of moving this stuff or parts of it
> to Spring (that would be actually up to Carsten IMO) or just get more
> users to it?
The spring configurator is imho of general use and I built it with this
in mind as I removed most of the Cocoon specific stuff - apart from the
package names there are no dependencies to cocoon (or any other 3rd
party libs) and we used it a lot outside of Cocoon.
It provides many nice features when you work with Spring. So, yes the
genreal idea was to move it to a broader place. It would be cool to have
it "nearer to Spring", but I personally don't have the time/energy to do
this right now.
I had the hope that with a release of 2.2 there woudl be many interested
people who find the configurator handy which then leads to a larger
community around the project etc. - but, well...
So if anyone thinks that it makes sense to promote this stuff
"somewhere", let's do it :)
> For the latter it would be good to have documented what's
> there and how it is supposed to be used. The documentation at Daisy is a
> bit spare.
Hmm, I haven't looked at the docs recently, but I thought i had
documented everything which is in it. It might be that the latest
features are not documented. I'll have a look at it in the next days.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Clarification on converter concept
Posted by Joerg Heinicke <jo...@gmx.de>.
On 13.07.2007 17:06, Grzegorz Kossakowski wrote:
> How your MapBasedPropertyEditorRegistrar knows path at which particular
> editor should be registered?
Hmm, that's indeed getting a problem. Not with the
MapBasedPropertyEditorRegistrar itself, it handles nested maps. The key
of the first map is the data type, the key of the second one the path.
This needs to get flattened on
PropertyEditorRegistrar.registerCustomEditors(PropertyEditorRegistry) to
match PropertyEditorRegistry.registerCustomEditor(Class type, String
path, PropertyEditor editor).
<bean class="MapBasedPropertyEditorRegistrar">
<constructor-arg index="0">
<map key-type="java.lang.Class">
<entry key="MyDataType" value="MyDataTypeEditor"/>
<entry key="MyOtherDataType">
<map>
<entry value="defaultMyOtherDataTypeEditor">
<key><null/></key>
</entry>
<entry key="object.property"
value="specialMyOtherDataTypeEditor"/>
</map>
</entry>
</map>
</constructor-arg>
</bean>
It now gets a problem since there seems to be no obvious way to
automatically register editors with path - except some more complex way
of (mis)using the bean's name. Hmm, what about (adapting the EL registry
way):
<bean name="MyDataTypeEditor/path#variant"
class="MyDataTypeEditor"/>
with both path and variant being optional. This still lacks the
registering for our third criteria, the locale. So I wonder if we don't
need a different style of registering anyway.
> Spring configurator stuff is really handy and has no Cocoon dependencies
> so its wise to use it. Joerg, you seem to sit inside Spring community,
> have you considered giving Carsten a present by promoting his stuff? I
> really think it should get more attention. :-)
Hmm, was the first time I had a look into it today. I can't say if this
all is of general use. Do you think of moving this stuff or parts of it
to Spring (that would be actually up to Carsten IMO) or just get more
users to it? For the latter it would be good to have documented what's
there and how it is supposed to be used. The documentation at Daisy is a
bit spare.
Joerg
Re: Clarification on converter concept
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
> Grzegorz Kossakowski <gkossakowski <at> apache.org> writes:
>
>> I mentioned that snippet as an example how registry could work; my aim was to
>> show that we use declarative approach instead of registering converters/
>> property editors manually.
>
> Ah, got it. :-) Though the names are a bit irritating. Aren't the
> ExpressionCompilers actually the factories and isn't the ExpressionFactory more
> of a registry? It's also a bit strange that the Expressions must be aware of the
> prefix they are mapped to (Expression.getLanguage() + constructors of
> implementations). Any reason for that?
Good point about names. I'll consider to rename this classes since I don't consider them as any public API (it was used in template block
only to date).
When it comes to prefix and getLanguage() method, I don't know really. Eclipse tells me that this method is not us anywhere in Cocoon so I
think it redundant. Before removing it I'll try to search archives. This stuff is really work in progress and comes as legacy so I don't
know answers for all questions...
> Something similar exists for the PropertyEditors, the PropertyEditorRegistrar
> [1]. You are only supposed to implement it yourself which more or less means to
> add the PropertyEditors programmatically. Since I did not want to do this, I
> wrote a MapBasedPropertyEditorRegistrar (matching more or less
> DefaultExpressionFactory) which I could at least configure from Spring.
> spring-configurator's BeanMap seems to go one step further and searches for all
> implementations of a particular interface in the application context.
How your MapBasedPropertyEditorRegistrar knows path at which particular editor should be registered?
Spring configurator stuff is really handy and has no Cocoon dependencies so its wise to use it. Joerg, you seem to sit inside Spring
community, have you considered giving Carsten a present by promoting his stuff? I really think it should get more attention. :-)
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Posted by Joerg Heinicke <jo...@gmx.de>.
Grzegorz Kossakowski <gkossakowski <at> apache.org> writes:
> >> Yes, there is still a registry but neither EL user nor EL
> >> implementation must care about it.
> >
> > This looks like a registry for expression languages, not for converters.
> > How is it related?
>
> I mentioned that snippet as an example how registry could work; my aim was to
> show that we use declarative approach instead of registering converters/
> property editors manually.
Ah, got it. :-) Though the names are a bit irritating. Aren't the
ExpressionCompilers actually the factories and isn't the ExpressionFactory more
of a registry? It's also a bit strange that the Expressions must be aware of the
prefix they are mapped to (Expression.getLanguage() + constructors of
implementations). Any reason for that?
Something similar exists for the PropertyEditors, the PropertyEditorRegistrar
[1]. You are only supposed to implement it yourself which more or less means to
add the PropertyEditors programmatically. Since I did not want to do this, I
wrote a MapBasedPropertyEditorRegistrar (matching more or less
DefaultExpressionFactory) which I could at least configure from Spring.
spring-configurator's BeanMap seems to go one step further and searches for all
implementations of a particular interface in the application context.
Joerg
[1] http://static.springframework.org/spring/docs/2.0.x/api/
org/springframework/beans/PropertyEditorRegistrar.html
Re: Clarification on converter concept
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
> On 10.07.2007 10:30, Grzegorz Kossakowski wrote:
>
>>
>> It will be bean's ID pointing that this particular bean implements
>> "short" variant. We use powerful Spring configurator[1] stuff for
>> doing the trick, see this[2] for an example:
>> <bean id="org.apache.cocoon.components.expression.ExpressionFactory"
>>
>> class="org.apache.cocoon.components.expression.DefaultExpressionFactory">
>> <property name="expressionCompilers">
>> <configurator:bean-map
>> type="org.apache.cocoon.components.expression.ExpressionCompiler"/>
>> </property>
>> </bean>
>>
>> The expressionCompilers property is a Map.
>>
>> Yes, there is still a registry but neither EL user nor EL
>> implementation must care about it.
>
> This looks like a registry for expression languages, not for converters.
> How is it related?
I mentioned that snippet as an example how registry could work; my aim was to show that we use declarative approach instead of registering
converters/property editors manually.
> Can you please elaborate on this and add it to this other branch why
> actually? Maybe there is a different understanding which lead to
> different impressions on this.
Ok, I'll do it.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Posted by Joerg Heinicke <jo...@gmx.de>.
On 10.07.2007 10:30, Grzegorz Kossakowski wrote:
>>> What do you mean by registering?
>>
>> Where does the template know from which converter to apply? That's
>> defined by a particular converter which can be looked up by the
>> template in the registry.
>
> It will be bean's ID pointing that this particular bean implements
> "short" variant. We use powerful Spring configurator[1] stuff for doing
> the trick, see this[2] for an example:
> <bean id="org.apache.cocoon.components.expression.ExpressionFactory"
>
> class="org.apache.cocoon.components.expression.DefaultExpressionFactory">
> <property name="expressionCompilers">
> <configurator:bean-map
> type="org.apache.cocoon.components.expression.ExpressionCompiler"/>
> </property>
> </bean>
>
> The expressionCompilers property is a Map.
>
> Yes, there is still a registry but neither EL user nor EL implementation
> must care about it.
This looks like a registry for expression languages, not for converters.
How is it related?
> Could you elaborate on the "impedance mismatch"? I would like to see
> concrete examples to know what you mean. I'm curious because I used to
> really like JXPath.
I stole this term from O2R mapping where it is known that there is no
1:1-mapping between the concepts. I remember having a similar problem
with working with XPath on objects, especially collections. I thought
this was even documented in the official documentation [1] but I can't
find it from a quick look. So drop this.
> Now I get your point, and understand your arguments. However, as we seen
> already Daniel proposed very neat solution.
Let's continue this discussion on the other branch of this thread.
> As for now I much prefer such solution because playing with registries
> keeping PropertyEditors attached to some paths is not the most elegant
> solution, IMHO.
Can you please elaborate on this and add it to this other branch why
actually? Maybe there is a different understanding which lead to
different impressions on this.
> This mail helped a lot not only to understand your stand but to bring
> issues that I have not been thinking about before.
Good to hear :-)
Joerg
[1] http://jakarta.apache.org/commons/jxpath/users-guide.html
Re: Clarification on converter concept
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
>> 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.
>
> Where does the template know from which converter to apply? For the
> example ${myobj.startDate#short} "short" must actually be defined and
> registered somewhere, doesn't it? How did you say: "short date (whatever
> it means)" :-) That's defined by a particular converter which can be
> looked up by the template in the registry.
It will be bean's ID pointing that this particular bean implements "short" variant. We use powerful Spring configurator[1] stuff for doing
the trick, see this[2] for an example:
<bean id="org.apache.cocoon.components.expression.ExpressionFactory"
class="org.apache.cocoon.components.expression.DefaultExpressionFactory">
<property name="expressionCompilers">
<configurator:bean-map type="org.apache.cocoon.components.expression.ExpressionCompiler"/>
</property>
</bean>
The expressionCompilers property is a Map.
Yes, there is still a registry but neither EL user nor EL implementation must care about it.
>>
>> What was counter-intuitive apart from switching between both that I do
>> not like either?
>
> The ${} and #{}, the impedance mismatch between objects and xml model:
> JXPath on beans does not behave like on xml.
The ${} and #{} will be simplified. Could you elaborate on the "impedance mismatch"? I would like to see concrete examples to know what you
mean. I'm curious because I used to really like JXPath.
> Ok, recently somebody posted the SimpleFormController Lifecycle Cheat
> Sheet[2] in the Spring forum, which shows the request processing in the
> controller. Don't try to understand it, I just want to show where we
> are. One of the first things in the request processing is initBinder
> which actually takes the request as parameter. That means you can
> determine the locale in that method. You are supposed to register your
> PropertyEditors in this method:
>
> Binder.registerCustomEditor(Class, ProperyEditor);
>
> So for the date converter:
>
> Locale locale = // determine from request
> DateFormat dateFormat = DateFormat.getDateInstance(SHORT, locale)
> binder.registerCustomEditor(Date.class, new CustomDateEditor(dateFormat,
> ..));
>
> So it's not the PropertyEditor being locale-aware but the PropertyEditor
> instantiation. It creates the proper (= correct locale) PropertyEditor.
>
> But yes, I don't like it that much anyway. Actually I used it very
> rarely in my project. There is a much better way to do this than those
> scattering the PropertyEditors all over the place. So you might drop
> that complete section from mind :-)
LOL ;-)
At least I understand you, now :-)
>> Architecture
>> ============
>>
>> The "converter architecture" as I imagine it consist of three parts.
>>
>> * Converters:
>> * Converter registry:
>> * Integration:
>
> I agree completely. It's only about the details. The only difference I
> see actually is on which parameters the converter is chosen.
Count me in, I agree too.
>> Converters
>> ----------
>
>> IMO it would be cleaner to have the locale dependency in the registry
>> instead of in the converter.
>
> I agree. This means locale is removed from the converter methods.
+1
> "Date formats are not synchronized. It is recommended to create separate
> format instances for each thread. If multiple threads access a format
> concurrently, it must be synchronized externally."
>
> Same for NumberFormat and probably others as well. So no advantage over
> PropertyEditors which suffer from the same problem. I don't think we
> need a "real" format cache, it only seems to complicate stuff. The
> proposed ThreadLocal might be a solution. Spring holds them on the
> binder where they get registered once. Might be limiting since it's
> targetted to form processing obviously.
Yes, we don't want converter narrowed to Forms processing only.
>> Converter Registry
>> ----------
>
>> For a Cocoon framework I would prefer looking up a converter based on
>> class, locale and variant, while I don't see any obvious use cases for
>> property path.
>
> Indeed the PropertyEditorRegistry seems not to meet our requirements.
>
> (copied from further above, better fits in here)
>> The framework select based on data type and locale. But for e.g. dates
>> there are several different string representations (short, medium, full
>> and long or maybe some custom format) that the template or form author
>> needs to choose between. To me it seem reasonable to have a syntax for
>> making this possible in e.g. the template.
>
> As I wrote repeatedly the possibility to influence the formatting from
> the template breaks the two-way process. You can't parse a date
> expecting a FULL pattern string when receiving a string formatted with
> SHORT pattern. And there is no chance to get informed about this mismatch.
>
> The property path could be used to determine the variant instead of
> specifying it explicitly. It's obviously not that flexible - but can't
> be broken in that way. That's why I would opt for class, locale and
> path, so add locale to Spring's PropertyEditorRegistry methods.
Now I get your point, and understand your arguments. However, as we seen already Daniel proposed very neat solution. To elaborate a little I
guess there are two cases when data is returned to the server:
1. Forms submission
2. Ajax/Rest/Other client that is capable to much more than just present HTML nicely
In first case we could encode needed information in parameter's name (if browsers can handle it). When it comes to second case, you are more
free to choose data representation and you can always annotate data with meta-information rich enough to direct server how to interpret it.
As for now I much prefer such solution because playing with registries keeping PropertyEditors attached to some paths is not the most
elegant solution, IMHO.
> The concepts seem to be totally equal. We only extend the registry with
> the locale. Then I mentioned a new way of registering PropertyEditors,
> the PropertyEditorRegistrar. That's actually a PropertyEditor factory
> which also does the registering shown above when talking about the
> initBinder() method. It is possible to set up such a registrar once (!)
> in the application context and reuse it in the application context
> itself (e.g. for custom data types) or in the controllers. The point I
> want to make is the following: This PropertyEditorRegistrar is in
> contrary to initBinder() not even request-aware and so not locale-aware
> at all. So I wonder how it is supposed to be done in Spring now. Maybe
> filing an issue for an extension of the registry brings this into 2.1
> and we do not have to invent anything new. And even if not there is
> still so much to reuse and it's IMO absolutely worthwile to do it.
>
> I hope, I did not write too much non-sense in my hurry. Have to get to
> the plane to the US (finally!) soon. Maybe I could even clarify a bit of
> the confusion I caused with the last mail. :-)
This mail helped a lot not only to understand your stand but to bring issues that I have not been thinking about before.
Thanks! I hope we can continue to discuss.
[1] http://cocoon.zones.apache.org/daisy/cdocs-spring-configurator/g1/1304.html
[2]
http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/resources/META-INF/cocoon/spring/DefaultExpressionFactory.xml?view=markup
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Posted by Joerg Heinicke <jo...@gmx.de>.
On 05.07.2007 00:47, Grzegorz Kossakowski wrote:
> As Daniel pointed out, it has been discussed but I must admit I'm not
> completely sure that I "feel" the concept.
I like Daniel's post [1] a lot. It goes very much into the direction of
PropertyEditors. Quoting him:
"As a solution to the problem he sugests MVCR
(Model-View-Controller-Renderer), where the renderer is responsible for
converting (Java) data types to displayable strings. The renderer can be
responsible for localization of numbers etc as well. The renderer is an
extra step between model and view."
The renderer applies very much to the original idea of PropertyEditor.
"Displayable" in the GUI programming might be a bit more complex. That's
why there is a method getCustomEditor() returning a java.awt.Component
for example. For web programming to and from string conversion should be
sufficient.
"The simplest possible renderer is to just implement toString() in the
classes one is going to access in the view. But a better SoC is to have
a separate rendering component. In this case the object from the model
is first accessed by an expression in a suitable expression language and
then the object is rendered to a displayable string by the rendering
component and at last the displayable string is emited by the template
engine."
The externalized toString() describes quite perfectly what
PropertyEditor actually does.
How does it work (pseudo code and simplified):
BeanWrapper wrappedOM = new BeanWrapper(objectModel);
String displayString = wrappedOM.getProperty(aPath);
Internally BeanWrapper does:
Object value = getPropertyValue(objectModel, aPath);
Class valueType = getPropertyType(objectModel, aPath);
PropertyEditor editor =
PropertyEditorRegistry.findCustomEditor(valueType, aPath);
editor.setValue(value);
return editor.getAsText();
> From purist's point of view it is really _bad_ idea to use interfaces
> and classes for something that they were not invented for.
See above, it's not that far away. Unfortunately, Java started with GUI
programming before it founds its niche, the web programming. That's what
you still can find on this interface.
> 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.
I feared that my first collection of thoughts was too confusing. Will
focus on the important stuff now.
> 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)?
The latter. If xyz/bar/foo would not be of type Foo it would not match.
> 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.
Where does the template know from which converter to apply? For the
example ${myobj.startDate#short} "short" must actually be defined and
registered somewhere, doesn't it? How did you say: "short date (whatever
it means)" :-) That's defined by a particular converter which can be
looked up by the template in the registry.
>> I always found the JEXL/JXPath syntax rather counterintuitive.
>
> What was counter-intuitive apart from switching between both that I do
> not like either?
The ${} and #{}, the impedance mismatch between objects and xml model:
JXPath on beans does not behave like on xml.
> How Spring syntax looks like and how it is better than JXPath/JEXL?
Bean property syntax which as used in other template languages like
Velocity and scripting languages as well: object1.object2.property.
>> 3. Locale. PropertyEditors have no support for i18n/l10n. [..]
>> 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.
Ok, recently somebody posted the SimpleFormController Lifecycle Cheat
Sheet[2] in the Spring forum, which shows the request processing in the
controller. Don't try to understand it, I just want to show where we
are. One of the first things in the request processing is initBinder
which actually takes the request as parameter. That means you can
determine the locale in that method. You are supposed to register your
PropertyEditors in this method:
Binder.registerCustomEditor(Class, ProperyEditor);
So for the date converter:
Locale locale = // determine from request
DateFormat dateFormat = DateFormat.getDateInstance(SHORT, locale)
binder.registerCustomEditor(Date.class, new CustomDateEditor(dateFormat,
..));
So it's not the PropertyEditor being locale-aware but the PropertyEditor
instantiation. It creates the proper (= correct locale) PropertyEditor.
But yes, I don't like it that much anyway. Actually I used it very
rarely in my project. There is a much better way to do this than those
scattering the PropertyEditors all over the place. So you might drop
that complete section from mind :-)
Now the better approach while answering Daniel's mail:
On 05.07.2007 14:24, Daniel Fagerstrom wrote:
> Locale awareness is part of the idea.
Yes, of course. Somehow it has to come into play. But you see above that
it is at least possible with locale-unaware converters.
> Architecture
> ============
>
> The "converter architecture" as I imagine it consist of three parts.
>
> * Converters:
> * Converter registry:
> * Integration:
I agree completely. It's only about the details. The only difference I
see actually is on which parameters the converter is chosen.
> Converters
> ----------
> IMO it would be cleaner to have the locale dependency in the registry
> instead of in the converter.
I agree. This means locale is removed from the converter methods.
> Next the convertor needs a format cache, this is IIRC because date and
> number formating objects not are thread safe and takes some work to construct.
They are not [3]:
"Date formats are not synchronized. It is recommended to create separate
format instances for each thread. If multiple threads access a format
concurrently, it must be synchronized externally."
Same for NumberFormat and probably others as well. So no advantage over
PropertyEditors which suffer from the same problem. I don't think we
need a "real" format cache, it only seems to complicate stuff. The
proposed ThreadLocal might be a solution. Spring holds them on the
binder where they get registered once. Might be limiting since it's
targetted to form processing obviously.
> Last the convertFromString returns a ConversionResult while setAsText
> throws a IllegalArgumentException for badly formated input strings.
BeanWrapper does that part (mapping IllegalArgumentException to
something "controllable", similar as you work with ConversionResult).
> As a conclusion I think that PropertyEditors would work fine for us if
> we find it worthwhile.
Fine. I do :-)
> Converter Registry
> ----------
> For a Cocoon framework I would prefer looking up a converter based on
> class, locale and variant, while I don't see any obvious use cases for
> property path.
Indeed the PropertyEditorRegistry seems not to meet our requirements.
(copied from further above, better fits in here)
> The framework select based on data type and locale. But for e.g. dates
> there are several different string representations (short, medium, full
> and long or maybe some custom format) that the template or form author
> needs to choose between. To me it seem reasonable to have a syntax for
> making this possible in e.g. the template.
As I wrote repeatedly the possibility to influence the formatting from
the template breaks the two-way process. You can't parse a date
expecting a FULL pattern string when receiving a string formatted with
SHORT pattern. And there is no chance to get informed about this mismatch.
The property path could be used to determine the variant instead of
specifying it explicitly. It's obviously not that flexible - but can't
be broken in that way. That's why I would opt for class, locale and
path, so add locale to Spring's PropertyEditorRegistry methods.
> So as a conclusion: it would be nice to reuse the Spring stuff and
> there are big overlaps, but especially for locale handling it is not
> obvious to me how to use it. Then of course there is the question if
> it is worthwhile to reuse.
The concepts seem to be totally equal. We only extend the registry with
the locale. Then I mentioned a new way of registering PropertyEditors,
the PropertyEditorRegistrar. That's actually a PropertyEditor factory
which also does the registering shown above when talking about the
initBinder() method. It is possible to set up such a registrar once (!)
in the application context and reuse it in the application context
itself (e.g. for custom data types) or in the controllers. The point I
want to make is the following: This PropertyEditorRegistrar is in
contrary to initBinder() not even request-aware and so not locale-aware
at all. So I wonder how it is supposed to be done in Spring now. Maybe
filing an issue for an extension of the registry brings this into 2.1
and we do not have to invent anything new. And even if not there is
still so much to reuse and it's IMO absolutely worthwile to do it.
I hope, I did not write too much non-sense in my hurry. Have to get to
the plane to the US (finally!) soon. Maybe I could even clarify a bit of
the confusion I caused with the last mail. :-)
Regards,
Joerg
[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/42968
[2]
http://home.exetel.com.au/cweatures/dev/SimpleFormControllerCheatSheet.pdf
[3] http://java.sun.com/j2se/1.4.2/docs/api/java/text/DateFormat.html
Re: Clarification on converter concept
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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/
Re: Clarification on converter concept
Posted by Joerg Heinicke <jo...@gmx.de>.
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
Re: Clarification on converter concept
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
<snip/>
> Something like that. You find some background in
> http://article.gmane.org/gmane.text.xml.cocoon.devel/42968 and
> http://article.gmane.org/gmane.text.xml.cocoon.devel/43141. Also I think
> we already discussed converters while discussing your GSoC application.
A small side note: Providing links to crucial posts instead of whole threads really helps the reader. I must adapt this behaviour. :-)
<snip/>
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Posted by Joerg Heinicke <jo...@gmx.de>.
On 05.07.2007 18:26, Grzegorz Kossakowski wrote:
> I had a feeling that there is much more besides Date/Number/Currency
> formatting but now I think that I was suffering from over-generalization
> problem. The converter concept is that simple how you describe it but
> it's not wrong because it solves very concrete problem.
Hopefully it goes beyond simple date, number or currency formatting!
With Spring's usage of PropertyEditors you can bind objects directly to
a selection list. You don't care how it gets converted to string and
back, the PropertyEditor does it. The CForms way is more complicated
[1], you have to convert your collection to a
org.apache.cocoon.forms.datatype.SelectionList.
In my Spring MVC project I have written one (!) EntityPropertyEditor
which is used for all domain entities in my application. Now in JSP
using Spring's form taglib I just write:
Which company do you want to work for?
<form:select path="user.selectedCompany" items="${companies}"
itemLabel="name"/>
"user" is the object the form is bound to.
"selectedCompany" is a property of the use and of type entity or
company, not a entity id or something like that.
"companies" is a collection of entities/companies, e.g. retrieved from
RequestContext.
"name" is a property of the entity/company, here used as label.
That's all. No selection list generation. No caring about the key. The
<option> in the <select> is correctly preselected if there was one set
on the user. I get a company instance set on user.selectedCompany property.
>> <jx:formatDate value="${myobj.startDate}" dateStyle="short"
>> locale="${cocoon.request.locale}">
>>
>> for each date. That is of course quite OK to write, but it clearly
>> clutters the code, and it is not that obvious for a non developer.
>> With converters it would be more like:
>>
>> ${myobj.startDate#short}
Isn't that only a shorter syntax?
The focus on template formatting is rather limiting. IMO it MUST be a
two-way process or you can't write back to the object model. Selecting
the converter in the template makes it just impossible.
We might have a different focus in mind. But if we talk about a general
converter concept we should not start with such a limitation.
Joerg
[1] http://cocoon.apache.org/2.1/userdocs/widgetconcepts/selectionlists.html
Re: Clarification on converter concept
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
>
> That would be the case if expressions with converter variant modifiers
> only was used alone as attribute values. But remember that expressions
> in CTemplate can be embeded in text as well, e.g.:
>
> <p>The start date is ${myobj.startDate#short}.</p>
>
> In such cases having the modifier outside the expression would be harder
> to parse. We chose '#' as a separator as it didn't seem to have any
> significant meaning in the expression languages we had in mind when the
> converters where discussed. We can always introduce some escaping
> mechanism "##" e.g. for cases when a literal '#' is needed as part of an
> expression.
Standard \# is more intuitive but generally I agree with your point.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>> Grzegorz Kossakowski skrev:
>>> Daniel Fagerstrom pisze:
...
> I had a feeling that there is much more besides Date/Number/Currency
> formatting but now I think that I was suffering from over-generalization
> problem. The converter concept is that simple how you describe it but
> it's not wrong because it solves very concrete problem.
Nothing spectacular this time ;) But improving usability is consists
mainly of lots of small improvements.
> Now I think that I fully get the idea and we can focus on discussing how
> to implement it.
>
>> Anyway, say that you have a couple of dates in your model bean that
>> you would like to render on a web page using CTemplate. Then you
>> currently would need to write something like (haven't checked the
>> details):
>>
>> <jx:formatDate value="${myobj.startDate}" dateStyle="short"
>> locale="${cocoon.request.locale}">
>>
>> for each date. That is of course quite OK to write, but it clearly
>> clutters the code, and it is not that obvious for a non developer.
>> With converters it would be more like:
>>
>> ${myobj.startDate#short}
>>
>> and
>>
>> ${myobj.startDate}
>
> Personally, I prefer ${myboject.startDate}#short syntax because choosing
> converter should not be part of expression (it would be hard to
> distinguish where expression part ends and converter name begins in some
> cases). The syntax would also imply that conversion is performed after
> obtaining value (object) by evaluating the exception.
That would be the case if expressions with converter variant modifiers
only was used alone as attribute values. But remember that expressions
in CTemplate can be embeded in text as well, e.g.:
<p>The start date is ${myobj.startDate#short}.</p>
In such cases having the modifier outside the expression would be harder
to parse. We chose '#' as a separator as it didn't seem to have any
significant meaning in the expression languages we had in mind when the
converters where discussed. We can always introduce some escaping
mechanism "##" e.g. for cases when a literal '#' is needed as part of an
expression.
/Daniel
Re: Clarification on converter concept
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
> Grzegorz Kossakowski skrev:
>> Daniel Fagerstrom pisze:
> ...
>> Yes, but I really didn't get the idea fully. Now I think that it may
>> be just a lack of use cases for converter. Would you be so kind to
>> provide some examples how it could work in particular cases and how it
>> would be helpful for Cocoon developer?
>>
>> Sometimes abstract explanations hide the basic idea, actually.
> Didn't my examples from CForms and CTemplate below help you?
I had a feeling that there is much more besides Date/Number/Currency formatting but now I think that I was suffering from
over-generalization problem. The converter concept is that simple how you describe it but it's not wrong because it solves very concrete
problem.
Now I think that I fully get the idea and we can focus on discussing how to implement it.
> Anyway, say that you have a couple of dates in your model bean that you
> would like to render on a web page using CTemplate. Then you currently
> would need to write something like (haven't checked the details):
>
> <jx:formatDate value="${myobj.startDate}" dateStyle="short"
> locale="${cocoon.request.locale}">
>
> for each date. That is of course quite OK to write, but it clearly
> clutters the code, and it is not that obvious for a non developer. With
> converters it would be more like:
>
> ${myobj.startDate#short}
>
> and
>
> ${myobj.startDate}
Personally, I prefer ${myboject.startDate}#short syntax because choosing converter should not be part of expression (it would be hard to
distinguish where expression part ends and converter name begins in some cases). The syntax would also imply that conversion is performed
after obtaining value (object) by evaluating the exception.
> Maybe, but in that case you have one way of handling formating for forms
> and another way for templates. And you would need two configurations
> instead of one. Also from a conceptual standpoint it is better to
> separate the rendering part (template) and the model part (form
> definition). See my abstract text ;)
> http://article.gmane.org/gmane.text.xml.cocoon.devel/42968 for more
> about the model-rendering separation.
Yes, I understand it now.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>> Grzegorz Kossakowski skrev:
...
> Yes, but I really didn't get the idea fully. Now I think that it may
> be just a lack of use cases for converter. Would you be so kind to
> provide some examples how it could work in particular cases and how it
> would be helpful for Cocoon developer?
>
> Sometimes abstract explanations hide the basic idea, actually.
Didn't my examples from CForms and CTemplate below help you?
Anyway, say that you have a couple of dates in your model bean that you
would like to render on a web page using CTemplate. Then you currently
would need to write something like (haven't checked the details):
<jx:formatDate value="${myobj.startDate}" dateStyle="short" locale="${cocoon.request.locale}">
for each date. That is of course quite OK to write, but it clearly
clutters the code, and it is not that obvious for a non developer. With
converters it would be more like:
${myobj.startDate#short}
and
${myobj.startDate}
for the default formatting.
And for CForms you would use exactly the same notation.
>> Of course there already is possible to do localization in CForms and
>> CTemplate but it is not that convenient. In CForms you need a
>> declaration like
>>
>> <fd:convertor type="formatting">
>> <fd:patterns>
>> <fd:pattern>MM/dd/yyyy</fd:pattern>
>> <fd:pattern locale="nl-BE">dd/MM/yyyy</fd:pattern>
>> <fd:pattern locale="fr">dd-MM-yyyy</fd:pattern>
>> </fd:patterns>
>> </fd:convertor>
>>
>> see
>> http://cocoon.apache.org/2.1/userdocs/widgetconcepts/datatypes.html#formatting+%28date%29,
>> for each date field in your form definition (maybe there are some
>> more convenient way to do it with form libraries?).
>
> AFAIR, using form libraries is the solution you look for in this case.
Maybe, but in that case you have one way of handling formating for forms
and another way for templates. And you would need two configurations
instead of one. Also from a conceptual standpoint it is better to
separate the rendering part (template) and the model part (form
definition). See my abstract text ;)
http://article.gmane.org/gmane.text.xml.cocoon.devel/42968 for more
about the model-rendering separation.
>> In CTemplate you instead use special tags
>> http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html#formatDate.
>>
>> With these constructions a localized Cocoon webapp becomes cluttered
>> with localization code.
>
> Are there any use-cases apart form Date/Number/Currency conversion?
I think those are the main use cases. But I think it should be plugable
so that people are able to write converters for there own classes. As
you can see in
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/datatype/convertor/,
cforms contains a number of different convertors.
...
>>> 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
>>>
>>> will be used to tell Cocoon that user expects 'date' request
>>> parameter to be formatted as short date (whatever it means).
>> Short etc. is from DateFormat
>> http://java.sun.com/j2se/1.4.2/docs/api/java/text/DateFormat.html.
>
> So converter is just a wrapper for configured DateFormat, right?
A date converter would be that, yes.
/Daniel
Re: Clarification on converter concept
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
> Grzegorz Kossakowski skrev:
> Convertor was from CForms, converter might be a better name.
There are three (including me) people that agree on this, I would said that it is already decided. ;-)
> Something like that. You find some background in
> http://article.gmane.org/gmane.text.xml.cocoon.devel/42968 and
> http://article.gmane.org/gmane.text.xml.cocoon.devel/43141. Also I think
> we already discussed converters while discussing your GSoC application.
Yes, but I really didn't get the idea fully. Now I think that it may be just a lack of use cases for converter. Would you be so kind to
provide some examples how it could work in particular cases and how it would be helpful for Cocoon developer?
Sometimes abstract explanations hide the basic idea, actually.
> The main usage is localization of string representations of dates and
> numbers. This is needed both for CTemplate and CForms. For CForms the
> converter needs to be bidirectional as well.
Yes.
> Of course there already is possible to do localization in CForms and
> CTemplate but it is not that convenient. In CForms you need a
> declaration like
>
> <fd:convertor type="formatting">
> <fd:patterns>
> <fd:pattern>MM/dd/yyyy</fd:pattern>
> <fd:pattern locale="nl-BE">dd/MM/yyyy</fd:pattern>
> <fd:pattern locale="fr">dd-MM-yyyy</fd:pattern>
> </fd:patterns>
> </fd:convertor>
>
> see
> http://cocoon.apache.org/2.1/userdocs/widgetconcepts/datatypes.html#formatting+%28date%29,
> for each date field in your form definition (maybe there are some more
> convenient way to do it with form libraries?).
AFAIR, using form libraries is the solution you look for in this case.
> In CTemplate you instead use special tags
> http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html#formatDate.
>
> With these constructions a localized Cocoon webapp becomes cluttered
> with localization code.
Are there any use-cases apart form Date/Number/Currency conversion?
> There are certainly room for some improvements:
>
> First, it would be better to have *one* localization method that could
> be used in both CForms and CTemplate (and possibly at other places), so
> it is enough to learn one method for newcomer.
+1
> Second, it should be enough to declare the localized rules for getting
> from an object to its localized string representation in one place
> (configuration file), needing to do it for each use makes the code hard
> to maintain and read.
+1
> Third, there should be a default converter (possibly localized) for
> important data types, so you don't need to write anything at all in your
> forms or templates in most cases.
...and option to override default converter.
>> 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
>>
>> will be used to tell Cocoon that user expects 'date' request parameter
>> to be formatted as short date (whatever it means).
> Short etc. is from DateFormat
> http://java.sun.com/j2se/1.4.2/docs/api/java/text/DateFormat.html.
So converter is just a wrapper for configured DateFormat, right?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Hello,
>
> 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.
Convertor was from CForms, converter might be a better name.
> 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).
Something like that. You find some background in
http://article.gmane.org/gmane.text.xml.cocoon.devel/42968 and
http://article.gmane.org/gmane.text.xml.cocoon.devel/43141. Also I think
we already discussed converters while discussing your GSoC application.
The main usage is localization of string representations of dates and
numbers. This is needed both for CTemplate and CForms. For CForms the
converter needs to be bidirectional as well.
Of course there already is possible to do localization in CForms and
CTemplate but it is not that convenient. In CForms you need a
declaration like
<fd:convertor type="formatting">
<fd:patterns>
<fd:pattern>MM/dd/yyyy</fd:pattern>
<fd:pattern locale="nl-BE">dd/MM/yyyy</fd:pattern>
<fd:pattern locale="fr">dd-MM-yyyy</fd:pattern>
</fd:patterns>
</fd:convertor>
see
http://cocoon.apache.org/2.1/userdocs/widgetconcepts/datatypes.html#formatting+%28date%29,
for each date field in your form definition (maybe there are some more
convenient way to do it with form libraries?).
In CTemplate you instead use special tags
http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html#formatDate.
With these constructions a localized Cocoon webapp becomes cluttered
with localization code. There are certainly room for some improvements:
First, it would be better to have *one* localization method that could
be used in both CForms and CTemplate (and possibly at other places), so
it is enough to learn one method for newcomer.
Second, it should be enough to declare the localized rules for getting
from an object to its localized string representation in one place
(configuration file), needing to do it for each use makes the code hard
to maintain and read.
Third, there should be a default converter (possibly localized) for
important data types, so you don't need to write anything at all in your
forms or templates in most cases.
> 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
>
> will be used to tell Cocoon that user expects 'date' request parameter
> to be formatted as short date (whatever it means).
Short etc. is from DateFormat
http://java.sun.com/j2se/1.4.2/docs/api/java/text/DateFormat.html.
> 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.
Yes.
/Daniel