vegetax wrote: > Validation integration , the second most cumbersome thing when coding > websystems,webapps. Interface coding being the hardest. > > I took a look at the upcoming Widgets framework, while it looked good > you have to put the validators on the widgets? imo this is not the > right place! , it goes compeltly against DRY, you are repeating a lot > of stuff there is already in the model. not_null, unique, IntCol, etc.
I had similar thought this summer while thinking about rolling my own web framework. What I came to is along this line: - since HTML only gives you strings, the controler/view part of the system must however make some conversions - these conversions may fail - so we *already* have a first validation occuring in the 'non-model' parts of the system. Now the question is not "who must be responsible for validation", but "who must be responsible for *what part* of the validation process" !-) Of course, most of the business rules are to be enforced by the model itself. But the model should be usable in others contexts too, so it's the view/controleur part's responsability to enforce the necessary preconditions. > Why not link the validators to the model ? > > class Person(SQLObject): > name = StringCol(notNone=True, validators=[my_validator]) > phone = IntCol(notNone=True, unique=True, > validators=[my_Validator2, my_validator3]) > > the something like: > > person.parse() > > which will return a parsed object that form widgets can understand and > redisplay in case of errors, That would be a too strong coupling between the model and the view IMHO. The controler and the view depends on the model, but the model should be mostly unaware of the controler/view. Also note that you don't need 'validators' to express business rules in the model - just write methods that do the job and raise appropriate exceptions, and let the controler/view take care of the rest. > that way there is no need to repeat things > 10 times, You don't have to repeat things 10 times. The model does impose some preconditions that the view/controler must respect - this is the first, 'technical, sanity check' validation phase -, and enforces some invariants and post-condition - this is the second, 'business rules' validation phase. > thats what makes changing,extending the app so dificult and > cumbersome. > BTW, what you're describing is somehow what some CMS/groupware app for Zope/CMF I'm actually working with tries to do, and the result is, well, not quite what you'd expect. My 2 cents -- bruno desthuilliers développeur [EMAIL PROTECTED] http://www.modulix.com
