[aida] Validation enhancements?

Herbert König herbertkoenig at gmx.net
Sat Nov 27 19:12:11 CET 2010


FD> That was the point on how to add a validator. Should validator just be a
FD> block (than I ask how you will combine them with and:; or:

by some accident I stumbled over:
showing that the block type validation seems to be built into AIDA

FD> or if we might use something like
FD> aValidator := IntegerValidator new.
FD> aValidator minValue : 1
FD> aValidator maxValue : 10

Block validation should be sufficient for String, Float and Integer
and is applied on the single Input field.

FD> we than also may have a form validation function which defaults may be

Yes though although I do it on components of a form which are then
Ajax updated.

FD> to something
FD> form runThroughAlleFormElementscollectingValidationResults

The validation classes for complex objects must assure uniqueness in
some sense (e.g. the combination of several ivars must be unique) to
allow a create. This is more than the sum of all the inputs

But yes, thinking about it in terms of CRUD it seems possible to do
some generalisation regarding the different operations.
Creation only of unique objects in the above sense.
Update only if the fields required for uniqueness above are unchanged
Delete ????
Forgot something?

http://www.squeaksource.com/ComplexCondition may come in handy for

All this said all my validators are used by the WebApplication's
observee which mediates between the actual model and its view. Which
seems to say that complex input validation is not the business of the
web framework at all. Following strict Aida philosophy each model
class should have had its own WebApplication. In that case my
assumption may not hold.

FD> and there 
FD> we either collect all bugs on page and whil rendering we look through it
FD> and e.g highlight the fields with "errors" ....

For uniqueness you can change one of several fields, so I opted for
one error line representing only the last error. But again attaching
some JavaScript to the errorfield which sets the class of the affected
inputs to red is a good idea.

>> There's another thing I wish for and that's sending JSON back and
>> forth.
FD> It's
FD> definitly more lightweight than XML and let's see it like it is it's
FD> easier to handle in every language. I don't have to mention XPATH or
FD> even worse XSLT or do I ;-)

Lucky me spent his life without XML except looking at it with disgust
when some programmers I supervised used it for object storage. But
they also used C++ and XML was the rage then so what should I expect :-))

>> I want to just send:
>> [{id=1 class='WebGrid'},... {id=7 class='Blue'} ...] and have some
>> JavaScript update the DOM.
FD> I don't know but if we provide a JSON api shouldn't that be a good
FD> replacement?

That's what I meant to say :-))

FD> Another advantage see ther are at least two quite Databases using JSON

I'm happy that Igor Stasenko maintains a Squeak CouchDB interface. But
up to now, wherever I went I heard SQL say "I'm already here" like the
hedgehog in the fairy tale.


Herbert                            mailto:herbertkoenig at gmx.net

More information about the Aida mailing list