On Tue, 2004-11-02 at 19:21 +0100, Daniel Fagerstrom wrote: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.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); }
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 aIf 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.
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.
/Daniel
