cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: Clarification on converter concept
Date Tue, 10 Jul 2007 14:30:01 GMT
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/

Mime
View raw message