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 Sun, 08 Jul 2007 10:34:48 GMT
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/


Mime
View raw message