[aida] Validation enhancements?

Friedrich Dominicus frido at q-software-solutions.de
Thu Nov 25 07:03:45 CET 2010


Herbert König <herbertkoenig at gmx.net> writes:

> 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. 
Well I would think that we have a let's say pluggable Object for that. 
And all of our validators should derive from this Object and while we
declare the elements we choose either one of the prefabricated
validators (one wich surly springs to your mind also is a
IntegerInputField), I doubt that this would not be useful to you also. 

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

or if we might use something like

aValidator := IntegerValidator new.
aValidator minValue : 1
aValidator maxValue : 10

someWebElement := WebElementWithValidator new.
   someWebElement use: aValidator....


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

something

form runThroughAlleFormElementscollectingValidationResults 

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



>
> In the even older discussions with Alex Baran we planned to have a
> whole event system based on this.
I think this may be the best ans most extensible but also the easiest to
comprehend approach. ...
>
> There's another thing I wish for and that's sending JSON back and
> forth.
Very funny. I suggested to add this facility to a software which is
currently developed. It's for the German EANV system which is about
handling waste and digitally signing such things. My idea to a port of
our current software, is to use JSON objects for WebServices. It's
definitly more lightweight than XML and let's see it like it is it's
easier to handle in every language. I don't have to mention XPATH or
even worse XSLT or do I ;-)

>
> 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. 
I don't know but if we provide a JSON api shouldn't that be a good
replacement?


>
> 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.
I think I'm on your side here. We really must see that we just send as
less information as is needed. Not everywhere you can get above let's
say even 50 KB/sec. For most of my customers needs I think less than 2 K
are really needed at once. And for one applicaton specifically I can get
away with a 9600 serial line....

I also think that JSSON could be quite easy be compressed, it's nothing
really "fancy" in it. You can see that this works for XML also... But we
have much less redundance but JSON has eveything we need to marshall
objects. And if you look ad JavaScript and Smalltalk you can see there
is a nearly 1:1 match....

Another advantage see ther are at least two quite Databases using JSON
and if we look  a little further, couldn't it be that using some of
those Databases would be a nice way for a Smalltalk Revision control but
with the advantage that every language able to treat JSON can use the
Data?

Of course you can say we have our SQL interfaces, but I'm looking into
OODB since ages and if you look at diverse ORM based tools. It often
just is as if our Objects should be "flattened". Inheritance is often
not used? The reason for that alone can't be that we won't use OO but
that we just constrain ourselves on "flatter" objects.  Just look at one
hallmark of an ORM Active Records but see how many words there have been
written over it.. Should that be "easy"?


-- 
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim 
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus


More information about the Aida mailing list