DM2 validation questions

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there,

I'm currently working on the DM2 creation mode facility, and (again) stumbled on
a (I think) design problem regarding validation.

Right now, DM2 has *two* points where validation rules can be plugged in:

One is  at the datamanager level, which is checked even with programmatic use of
DM2 driven objects (e.g. cases where you don't use the Formmanager part). The
original thought behind this "level" of access control is to make it work
always, regardless of circumstances. Right now no essential checks are located
in this layer (except for a few boundary limitations of the number type and
similar, trivial stuff).

The other point is the QF-based form validation, which I originally thought as a
primary "line of defense" against the user. It is widely in use already, and
very flexible. As a matter of fact, the current widgets written by me even map
the DM level validation rules to the FM level. These rules are checked *prior*
syncing form fields to datamanager fields and therefore prevent object
manipulation even before the DM even gets into the game.

The problem I'm facing now is that I cannot easily catch the DM level errors in
the same way QF does. In the current implementation state (which is by all means
far from complete) this actually means that all controller instances built so
far reject saving (as the encaspulated DM instance does the same thing) and
reroutes the processing chain to the "edit" state. However, right now *no* error
message is shown on screen, they are just logged. In many cases, btw., the
type-ward validation rules are also mapped to the QF layer automatically, as the
corresponding widgets know what typeward restrictions they have to "obey".

Before I start wondering how I could register my own errors *easily* with
Quickform my question is a different one: Do we need this distinction actually?
Or could we live with having full validation on the user side but not on the
pure code side? That would mean that components using pure datamanager instances
for object manipulation need to do their own validation where neccessary. Types,
which fail to validate some fundamental constraint without any option for a
graceful fallback in turn would have to generate_error to actually propagate the
 problem to the outside.

I personally think that this simplification should be quite usable and not too
much of a drawback. Mainly, because the point where 99% of the validation needs
to be done is the enduser-point.

Other alternatives would be:

a) hacking our way into the QF code so that type validation would be displayed
b) extending form rendering to have a classic save-failed area like DM1 had

If this feature should stay, I'd prefer a) -- not that I have an idea when I'd
get around to implementing it.


Any opinions?


Live long and Prosper!
Torben Nehmer

- --
Torben Nehmer, Guenzburg, Bavaria, Germany
http://www.nathan-syntronics.de, mailto:[email protected]
PGP Public Key: https://www.link-m.de/pgp/t.nehmer.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD2jNAJPh4Kn6d5FYRAmxFAKDvByVAQ8JnGYPqj7deYBgaKOMyOACePXNt
uo1OubCv7H3bIWRkXu1MLuA=
=+uvr
-----END PGP SIGNATURE-----