[aida] Validation enhancements?

Herbert König herbertkoenig at gmx.net
Wed Nov 24 21:08:38 CET 2010


Hi Friedrich,

FD> The validation of elements. If we add input elements to forms we do it
FD> via the  add..Aspect:for: functions. But we have to declare the
FD> validation in an extra step.

let me speak from my experience so far. In general I agree with both
of your posts.

But I doubt, my validator would solve your problems or that yours
would be useful to me. My abstract class InputValidator verifies the
basics String, REBInteger and REBFloat instead of Integer and Float.

The concrete classes verify over groups of inputs. In the attachment
you can see verification for some of the CRUD operations.

FD> field := e newCell addInputFieldAspect: #tanNr for: self observee.

In this case I write
e addInputFieldAspect: #floatNumberText for: self observee.

floatNumberText allows for + 123 456,789 as a Float before validation.

FD> like this:
FD> field := e newCell addInputField: ... for: ... validateAgainst:
FD> someBlock? someValidatorObject?

yes but also depending on the particular CRUD operation. See
attachment. I have buttons for add, update, delete which trigger the
validator.

FD> well than we still have the question on when this validation will be
FD> handeled. If JavaScript is active this validation can be run directly
FD> on the Client, but we probably need some other validation rules (either
FD> if someone does not have JavaScript active) or if we want to assure that
FD> our model data are ok. Anyway the code probably has to emit two
FD> different validation functions. One in JavaScript one in Smalltalk.

For this I have WebElement>>addClickDo: aBlock andUpdateFunction: aJavaScript
which is still an ugly hack but I want to propose this for inclusion
in AIDA when it's ready.

For some information on the rationale behind this see:
http://article.gmane.org/gmane.comp.web.server.aida/2649

In the even older discussions with Alex Baran we planned to have a
whole event system based on this.

FD> But maybe it's just me beeing to dumb...

Definitely not! We need CRUD operations on a grid, we need input
verification and we need parts done in the server and parts done in
the browser. All IMHO that is.

There's another thing I wish for and that's sending JSON back and
forth.

When somebody clicks on a line in a grid which should be
highlighted (rowBoldIfTrue: aBlock) instead of the previously
highlighted line, up to now we are:

-letting the server know about the newly selected line,
-rebuilding the component(s),
-replacing the new id's with the old ones
-creating the whole HTML of the component(s) and
-sending it

I want to just send:
[{id=1 class='WebGrid'},... {id=7 class='Blue'} ...] and have some
JavaScript update the DOM.

Maybe I'm straying too far from the path of REST here. But I need my
web application perform like my locally running spreadsheet, so in my
very constrained time I work towards this.

Another thing my grids need is a slider. The current way (rowsOnPage)
was not acceptable for me last time I looked.
Right now I have a slider beside my grid which indicates which of the
100 rows of a table are displayed in the 10 row grid. Navigating the
grid with the slider doesn't work yet. And it will put a big load on
the server if it has to go through all the above steps instead of
sending a JSON array of 50 floats and have JavaScript update the HTML.

Cheers,

Herbert                            mailto:herbertkoenig at gmx.net
-------------- nächster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : RB# DA53Validator.png
Dateityp    : image/png
Dateigr??e  : 42586 bytes
Beschreibung: nicht verf?gbar
URL         : http://lists.aidaweb.si/pipermail/aida/attachments/20101124/275ab9ee/attachment-0001.png 


More information about the Aida mailing list