Hello
I really appreciate you taking the time to look through the code. I've
inlined some comments below.
On Thu, 2004-10-28 at 15:06, Sylvain Wallez wrote:
> Jonas Ekstedt wrote:
>
> >On Thu, 2004-10-28 at 12:50, Reinhard Poetz wrote:
> >
> >
> >>After reading it once, one question: Do you see any way to integrate your ideas
> >>into Cocoon Forms?
> >>
> >>
> >
> >One part that I believe could be incorporated into CForms would be how
> >the view model is populated.
> >
> >
>
> That's the "ugly" I was mentioning in my previous post : this is a very
> dangerous approach, similar to the now defunct XMLForm (see [1],
> "mapping to the application data model"). Having a direct and live
> mapping from the form to the data model is an open door to inconsistent
> business data in case validation fails.
>
> Furthermore, just like XMLForm, your approach doesn't allow smart
> convertors to be defined, taking into account formats, locale, etc. And
> validation occurs on strings, which is just why we rejected the use of
> Commons Validator, as CForms widgets have strongly typed values.
The models I provided do indeed map directly to the application object,
but this was on purpose. There are use cases when that is needed (eg.
when a bean provides derived values).
The next step is to create datamodels addressing the needs you
described. Here are some ideas that I've come up with:
* Cloning models
Operates on a clone of the application object. I'm working on a
ClonedBeanModel, and sketching a TransactionResultSetModel. The former
clones the application bean, and only when the user so request, updates
the application bean. The TransactionResultSetModel would copy the
resultset to a separate datastructure and similarly only update the
database when finished.
* Typesafe models with value conversions
This is an extension of the the cloned models concept with the addition
of type checking and value conversion in the getValue/setValue
functions.
* Secure models
The user can condition getting/setting of values by defining a security
policy. Eg. A user with role="administrator" can set the property A to
any of {1, 2, 3} but a user with role="user" can only set it to any of
{1, 2}.
As an example of a typesafe model with value conversion I updated the
framework to include a CFormModel that wraps a Cocoon Forms form. You
can download it at http://home.student.uu.se/j/joek8725/widgets.html.
The CFormModel takes advantage of the type checking and value conversion
in CForms as well as enable you to protect your business object from
being inconsistent using cforms binding. It should be said however that
the CFormModel is a terrible hack and should only be considered as an
example.
I added some samples as well. A CFormModel based Calculation wizard that
shows you type checking as well as a Personnel editor that uses CForms
binding to protect the application object.
Cheers
--
Jonas
