On Wed, 2004-11-03 at 21:46 +0100, Daniel Fagerstrom wrote:
> Jonas Ekstedt wrote:
> >
> > 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.
True
> In some cases like when you
> can build lists or trees in the user interface, a more traversal based
> interface is needed.
I agree that I haven't really thought this issue through thoroughly. In
the widget framework there is a "public int size(String path)" method
that returns the size of whatever object is present at that path. But
there could certainly be more stuff thrown in such as support for
pointers similar to JXPath that can run around in your model data.
> 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.
Protecting the application object is partly what the Model interface is
all about. In the getValue/setValue functions you can implement any
measures to protect the application object you'd like. The point is that
the user should decide what type of shielding should be used.
Eg. the project I'm working on is dependant on letting the view access
derived values from the bean model. That means I need to populate the
beans directly. I do not really care if the beans are inconsistent as I
won't hibernate them if they are (in a sense the database is my
"application object" that I need to shield). So in my case it makes
sense to operate directly on the application object.
However, as a different example, should I start using beans with
properties like ints or Dates then I would choose some other strategy as
I need to be able to save values even when they are not convertible. In
this case the wrapping model could store illegal values in a separate
map. getValue() would then return values from the map if they exist or
from the bean otherwise.
The second approach is similar to how CForm widgets works. What I think
is the benefit of the Model interface is that it is up to the user to
decide what type of shielding should take place.
> 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.
I think it would be quite easy to make this change to CForm.
Cheers Jonas
