cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Wed, 03 Nov 2004 20:46:27 GMT
Jonas Ekstedt wrote:
> On Tue, 2004-11-02 at 19:21 +0100, Daniel Fagerstrom wrote: 
>>Ok, the idea is as follows: we have a converter component, that is like 
>>the renderer component above, but bidirectional. I.e. both rendering: 
>>data type -> displayable string and input conversion: input string -> 
>>data type. The converter is configured in the same way as described for 
>>the renderer above.
> I've been working along the same line [1] (it's about a widget framework
> but contains elements that are relevant to your idea as well). The idea
> is that data is wrapped by a model that works directly on my data but
> that can perform any conversions, validations etc through its
> getValue/setValue functions:
> public interface Model {
>   public String getValue(String path);
>   public void setValue(String path, String value);
> }
IMO, such an interface is a good starting point, although it needs 
exceptions for cases when conversion fails. In some cases like when you 
can build lists or trees in the user interface, a more traversal based 
interface is needed.

Also, like everyone else that has commented your proposal, I think that 
it often is a bad idea to write directly to your model. Even if you are 
able to solve the security problems, the model will still need to be 
able to store partially invalid input data and missing data. IMO it is 
better SoC to have a form model in front of the real model. This 
decreases the complexity of the model as it always can get data in a 
more transactinal way in complete chunks.

I prefer the request processor idea to the current form population where 
each widget reads it data from the request object. The current scheme 
makes CForms unecesarily bound to the request parameter model of input 
data. With a request processor that is reponsible to write input data 
into the form model, it would be easy to plug in a different request 
processor if one gets xml input from a browser that implements XForms, e.g.

> For example if my data is a bean containing a Date then a
> ConvertingBeanModel wrapping my bean would have a getValue function
> performing the Date->String conversion (according to whatever locale is
> chosen). And vice versa with setValue. The benefit with having an
> abstract view of the model would be that you can implement any type of
> conversion in the setValue/getValue functions. You could have a generic
> set of conversions for the basic types as well as special conversions
> unique to your application. Eg. if your underlying data is a resultset
> then you can convert values to SQL types rather than java types. 
If we translate this to the CForms case, generic sets of convertors, 
would not only be useful for rendering and handling input to the widget 
hierarchy, they would be useful in the binding step also.


View raw message