A somewhat better working example

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

A somewhat better working example

FDominicus
Some of you probably have followed my requests. Now I have attached a
somewhat working example. Well you better not try t use the Delete
button in the edit form. This is still not working.

And well it's uses "hard" coded strings, which by any means can't be
taken serious. I've to find a nice way getting internationalization
done.

The last tip for getting the refresh down (after the click on the Delete
link) was using
el := WebElement new.
el registerId.

According to Janko this can be counted as a bug.

IMHO there are many other things lackign also:
1) this lenghty rendering methods. Which are in honest just glorified
Copy & Paste code (and this is *really* bad)
2) lacking validation on the elements
3) the toString fromString bottleneck (or put in the other way the
representaton of "structured" data even as simple like Dates

I doubt anyone has heard of it, but I feel checking out CLIM (the common
Lisp interface management system) offers something. It is named
Presenter/Accept. I think something along that would be very useful for
web development.

It was done and used e.g in CL-Http (see
http://www.cl-http.org:8001/cl-http/)

Other things which has come to my mind. Who is really responsible for
presenting information.

I think Aida and Iliad have gone a kind of "observer" pattern way, where
as Seaside has put this responsibility on the objects itself. The Aida
way is in the "spirit" of a model view separation. But I'm really not
sure what's the better approach is.

If we look though Smalltalk we find a lot of things like asxxx in the
diverse classes. so it feel somewhat natural to have it. I thought about
it up an down, but can not make anything out of it.... However my
impression is a somewhat portable way of sending objects around would be
a good thing to have. And in this area JSON would be my choice. It has
advantages especially over presenting and marshalling via XML. It's the
native interface to diverse NOSQL databases Couchdb etc. And it could be
a nice interface to all non-Smalltalk users of our system. Maybe someone
really is thinking about using such NOSQL databases as OO-Stores for
Smalltalk. Wouldn't that be a good "match"?

AFAIKT does Iliad support JSON..., so maybe Aida should follow them with
that?

Regards
Friedrich





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

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Aida-Tests-Tan-QSS-frido.7.mcz (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A somewhat better working example

Nicolas Petton
Le vendredi 10 décembre 2010 à 07:08 +0100, Friedrich Dominicus a
écrit :
>
> I think Aida and Iliad have gone a kind of "observer" pattern way

Iliad doesn't use the Oberver pattern at all. Regarding this Iliad is
closer to Seaside than Aida.

Cheers,
Nicolas

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: A somewhat better working example

Nicolas Petton
In reply to this post by FDominicus
Le vendredi 10 décembre 2010 à 07:08 +0100, Friedrich Dominicus a
écrit :
> Maybe someone
> really is thinking about using such NOSQL databases as OO-Stores for
> Smalltalk. Wouldn't that be a good "match"?

I know there is a couchdb binding for squeak somewhere on squeaksource.

>
> AFAIKT does Iliad support JSON
Yes, in Iliad most of the communication between the server and the
client is done in JSON.

Cheers,
Nicolas

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: A somewhat better working example

FDominicus
In reply to this post by Nicolas Petton
Nicolas Petton <[hidden email]> writes:

> Le vendredi 10 décembre 2010 à 07:08 +0100, Friedrich Dominicus a
> écrit :
>>
>> I think Aida and Iliad have gone a kind of "observer" pattern way
>
> Iliad doesn't use the Oberver pattern at all. Regarding this Iliad is
> closer to Seaside than Aida.
Yes, you are right of course. it let the object present itself...

Regards
Friedrich

--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: A somewhat better working example

Herbert König
In reply to this post by FDominicus
Hi Friedrich,

FD> Some of you probably have followed my requests. Now I have attached a
FD> somewhat working example. Well you better not try t use the Delete
FD> button in the edit form. This is still not working.

Doing in a workspace:

tt := Tans new.
(AIDASite named: 'aidademo') urlResolver defaultURL: '/tans' forObject: tt.

lets me log into tans but as soon as I press "add a new entry" I get a
debugger. Guess I miss some initialisation here which lives in your
image?


FD> I doubt anyone has heard of it, but I feel checking out CLIM (the common
FD> Lisp interface management system) offers something. It is named
FD> Presenter/Accept. I think something along that would be very useful for
FD> web development.

Funny I have quite some AutoLisp (the crippled Lisp used to script
AutoCAD) experience. Like it a lot :-))


Cheers,

Herbert                            mailto:[hidden email]

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: A somewhat better working example

FDominicus
Herbert König <[hidden email]> writes:

> Hi Friedrich,
>
> FD> Some of you probably have followed my requests. Now I have attached a
> FD> somewhat working example. Well you better not try t use the Delete
> FD> button in the edit form. This is still not working.
>
> Doing in a workspace:
>
> tt := Tans new.
> (AIDASite named: 'aidademo') urlResolver defaultURL: '/tans' forObject: tt.
>
> lets me log into tans but as soon as I press "add a new entry" I get a
> debugger. Guess I miss some initialisation here which lives in your
> image?
I guess that's a reasonable assumption. Maybe it's usedTans which is not
initialized? What's does the stack trace say...?

>
>
> FD> I doubt anyone has heard of it, but I feel checking out CLIM (the common
> FD> Lisp interface management system) offers something. It is named
> FD> Presenter/Accept. I think something along that would be very useful for
> FD> web development.
>
> Funny I have quite some AutoLisp (the crippled Lisp used to script
> AutoCAD) experience. Like it a lot :-))
Well I postede soemthing to Janko. Maybe it should be discussed here
also?
IMHO validations are one of the most urgent problems. I wonder if you
have checked Andrés Vallhauds Sunit based Validation. I think it's very
well explained in "A mentoring Course on Smalltalk".

I'm under the impression Validations need to be handled right from the
start and not "added" later.

He has published his code one the Cincom public repository. Maybe it
would be an idea to check out the SUnit based stuff there and think
about using it in Aida.

I'm currently thinking about the following classes/object attached to
WebElements.
Accepter(s) (this will allow to read in Elements from different sources,
e.g there mayb be an CVSAccepte, a JSONAccepter, StringAcceptor or
whatever
Presenter(s) (I thought about it in the following way. On an "error" one
may want to have another color of the field which has points out the
error

For how this is done elswhere you can take CLIM as "example".

Decorators (according to some out line one may want to have diffrent
colors of lines in a collection to see what belongs to where. E.g even
numbers are darker than odd numbers

Validator(s). I think just having a block returning some boolean will
not work (it will be tedious and not very informative) I suggested what
to check out for it.

Of course I've not written one line of code to support my
"points". However just imagine


we have my "incredible tiny example"

we have tanNr (which for the sake of an example, should just be
editable once)
we have the date (which I want in whatever format I like)
we have an amount
we have some comment

Now imagine

tanNr := new Webelemnt
tanNr validator: MustBeIntegerValidator new
tanNr presenter: JustBeEditableOnAdding new

date := new WebElement
date validator: MustBeDateInPast new.
date presenter: ISOxxxPresenter new.
date accepter: DateAccepter new

amount := new WebElement
amount validator: MustBeCurrencyValidator new.
....

you see the points?

Now imagine we want different "aspects" of this object. One could imagine
having something in an Array.

atan := #(#(#tanNr ValidatorOrNil PresenterOrNil AccepterorNil) ...
          #(#date  ValidatorOrNil ....)

Now you build a form just by

myElements do: [each.

If we want to modify one entry. we just replace one Element in this
matrix.
E.g at: someIndex putPresenter: JustBeEditableOnAdding new.


and we got many web forms "for free".
It's very descriptive, you don't tell how you want things done but what
you expect.

After that you do never have to bother that tanNr may not be an
Integer. The validation does not allow it differently..

maybe for a finer grain of control one keeps events around, why not take
Access as an example here. We could have

#beforeValidationEvent
#onValidationEvent
#afterValidationEvent

....

I hope one can see what I mean I want to avoid
repeating code as much as possible and I want a "high level" expressive
way of getting the "usual" things done. With acting on the diverse
events we can go as much into the "how to do things" level as we like.

I'm not up-to-the-task implementing it in the Aida Web framework, but
this is what I want for the WebContfakt development.

I do not want this:



showEditableParts: aWebElement
        aWebElement newCell addText: 'TanNr'.
        aWebElement newCell addInputFieldAspect: #tanNr for: self observee.
        aWebElement newRow.
        aWebElement newCell addText: 'Date'.
        aWebElement  newCell addInputFieldAspect: #date for: self observee.
        aWebElement  newRow.
        aWebElement  newCell addText: 'Amount:'.
        aWebElement  newCell addInputFieldAspect: #amount for: self observee.
        aWebElement  newRow.
        aWebElement  newCell addText: 'Comment:'.
        aWebElement  newCell addInputFieldAspect: #comment for: self observee.
        aWebElement  newRow.

This is ugly as hell and does not scale at all. I have've write
different methods looking as this but with something change. E.g I would
need this

showEditableParts: aWebElement
        aWebElement newCell addText: 'TanNr'.
        aWebElement newCell justShowNonEditableTanNr
        aWebElement newRow.
        aWebElement newCell addText: 'Date'.
        aWebElement  newCell addInputFieldAspect: #date for: self observee.
        aWebElement  newRow.
        aWebElement  newCell addText: 'Amount:'.
        aWebElement  newCell addInputFieldAspect: #amount for: self observee.
        aWebElement  newRow.
        aWebElement  newCell addText: 'Comment:'.
        aWebElement  newCell addInputFieldAspect: #comment for: self observee.
        aWebElement  newRow.

yes agreed I could put the editable Parts elswhere but
Imagine I want the amount to not be changeabel also. And yet another
function weiht repeated things. It simply is sorry "butt" ugly. If I
just want to show parts of it I again have to write an extra methods
which at least as much redundancy.

I want to be able to treat an Object
a) as a whole
b) parts of it

as one "logical" element. this logical element is presented with "one"
call. I do never ever want to say something like

aTan1 aTanNr: aTan2 aTanNr
...

...

but

aTan := aTan2...


And I surly do not want to have
TanComplete:

field1, field2, field3...

and TanWithoutDate
field1, field3, ....


And I want to not explictiyl tell each "instance" to be places by me
"explitly" I want the "bigger objets"! related e.g

layout := Layout new.
layout add: Address
layout add: InvoiceDetails rightOf: Address
...


layout show.


Regards
Friedrich

--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: A somewhat better working example

Herbert König
Friedrich,

FD> I guess that's a reasonable assumption. Maybe it's usedTans which is not
FD> initialized? What's does the stack trace say...?

it's not usedTans, though it was nil but a initUsedTans didn't help.

One of the things that come with Aida (maybe seaside too?) is that the
stack trace may not be as helpful as we are used.

From looking at it did you modify some Aida methods I don't have? Or
something in Date?

I guess you should not use #date in #showEditableParts but try the
Float trick I mentioned earlier, like having #defaultDateFormat as
accessors to date.

FD> Well I postede soemthing to Janko. Maybe it should be discussed here
FD> also?
FD> IMHO validations are one of the most urgent problems. I wonder if you
FD> have checked Andrés Vallhauds Sunit based Validation. I think it's very
FD> well explained in "A mentoring Course on Smalltalk".

Though I bought his books months ago I haven't gotten very far in
reading. Both are not the kind of book you can freely skip around the
pages.

FD> He has published his code one the Cincom public repository. Maybe it
FD> would be an idea to check out the SUnit based stuff there and think
FD> about using it in Aida.

There's also a Squeaksource project recently announced on Squeakdev.

FD> I'm currently thinking about the following classes/object attached to
FD> WebElements.

FD> Accepter(s) (this will allow to read in Elements from different sources,
FD> e.g there mayb be an CVSAccepte, a JSONAccepter, StringAcceptor or
FD> whatever

Yes, sounds useful.

FD> Presenter(s) (I thought about it in the following way. On an "error" one
FD> may want to have another color of the field which has points out the
FD> error
FD> For how this is done elswhere you can take CLIM as "example".
FD> Decorators (according to some out line one may want to have diffrent
FD> colors of lines in a collection to see what belongs to where. E.g even
FD> numbers are darker than odd numbers.

Isn't this a matter of building some CSS and use the appropriate
(css)classes?

FD> Validator(s). I think just having a block returning some boolean will
FD> not work (it will be tedious and not very informative) I suggested what
FD> to check out for it.

Though I know I need validators I still fail to see how they belong to
the Web framework.

Having read the first 15 pages of the relevant part of Andres book
seems to confirm that the validators belong to the model hierarchy. My
Webapp's observee has an error variable which is set by asking the
validator for it's errors and the Webapp decides on how to present the
error(s). He has convincing arguments and when I really read this
chapter I will refactor my validators to conform to the SUnit
paradigm.

If I where to do that refactoring now I would have to only change the
single #displayErrorComponent method in the Webapp to handle more than
a String.

FD> Of course I've not written one line of code to support my
FD> "points". However just imagine

The discussion is useful anyway. And thanks for the pointer.

FD> Now imagine

FD> tanNr := new Webelemnt
FD> tanNr validator: MustBeIntegerValidator new
FD> tanNr presenter: JustBeEditableOnAdding new

FD> date := new WebElement
FD> date validator: MustBeDateInPast new.
FD> date presenter: ISOxxxPresenter new.
FD> date accepter: DateAccepter new
In this case the accepter would need to employ the validator, same
with the rest of the fields.

FD> amount := new WebElement
FD> amount validator: MustBeCurrencyValidator new.
FD> ....

FD> you see the points?
Yes and the WebComponent consisting of these "fields" would be build
by the same principle, in the end employing a more complex validator.

But the model should do this accepting and validating. Actually the
controller. Now that I write this I realize that the controller partly
lives in the WebApp action methods. In my case the other part of the
controller lives in the WebApp's observee which in my case sits
between the WebApp and the real domain objects.

FD> Now imagine we want different "aspects" of this object. One could imagine
FD> having something in an Array.

The following is very interesting but as far as it's described I see
it only work for simple things.

FD> I hope one can see what I mean I want to avoid
FD> repeating code as much as possible and I want a "high level" expressive
FD> way of getting the "usual" things done. With acting on the diverse
FD> events we can go as much into the "how to do things" level as we like.

FD> I do not want this:

FD> showEditableParts: aWebElement
FD> aWebElement newCell addText: 'TanNr'.
FD> aWebElement newCell addInputFieldAspect: #tanNr for: self observee.
FD> aWebElement newRow.

agreed.

For this I have:
self
   addTabbingLineTo: e "onEnterTabulate for fast Entry via numeric keypad"
   header: 'TanNr:'
   selector: #tanNrText  "invokes the validator on the model"
   receiver: self observee.

When I use it often enough I'll stick it as another convenience method
into WebElement.

To iterate over a list to build a component is easy. It will simplify
the code. And I will follow Andres book in one more aspect: My headers
are the same as the accessors (except capitalization and appending
'Text' for the validation), so with a bit of reflection I will end up
with:

|headers|
headers := #('Anfang' 'Ende' 'Radius' 'Parameter')
e:= self buildInputComponentFor: self observee achselement
         headers: headers
         inputSize: 12

With some more reflection over the accessing protocol, I'd just have
to hand in the object.
         
Thanks for the discussion :-)


FD> yes agreed I could put the editable Parts elswhere but
FD> Imagine I want the amount to not be changeabel also.

Ok and putting the type of input to build into another list is
no biggie. I think Smalltalk has frameworks to do these things.
Glamour for building browsers comes to mind. Or even WebGrid with its
#columnAspects, ..align ..addBlocks

When I've built more web applications I will know how (and if) these
building blocks can be generalised.

Cheers,

Herbert                            mailto:[hidden email]
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Halt.png (25K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A somewhat better working example

FDominicus
Herbert König <[hidden email]> writes:

> Friedrich,
>
> FD> I guess that's a reasonable assumption. Maybe it's usedTans which is not
> FD> initialized? What's does the stack trace say...?
>
> it's not usedTans, though it was nil but a initUsedTans didn't help.
>
> One of the things that come with Aida (maybe seaside too?) is that the
> stack trace may not be as helpful as we are used.
>
> From looking at it did you modify some Aida methods I don't have? Or
> something in Date?
Yes I patched aroudn in Date the fromString stuff has used slovenien
date format and I wanted the ISO 9660 somewhat format

>
> I guess you should not use #date in #showEditableParts but try the
> Float trick I mentioned earlier, like having #defaultDateFormat as
> accessors to date.
>
> FD> Well I postede soemthing to Janko. Maybe it should be discussed here
> FD> also?
> FD> IMHO validations are one of the most urgent problems. I wonder if you
> FD> have checked Andrés Vallhauds Sunit based Validation. I think it's very
> FD> well explained in "A mentoring Course on Smalltalk".
>
> Though I bought his books months ago I haven't gotten very far in
> reading. Both are not the kind of book you can freely skip around the
> pages.
>
> FD> He has published his code one the Cincom public repository. Maybe it
> FD> would be an idea to check out the SUnit based stuff there and think
> FD> about using it in Aida.
 >

> There's also a Squeaksource project recently announced on Squeakdev.
>
> FD> I'm currently thinking about the following classes/object attached to
> FD> WebElements.
>
> FD> Accepter(s) (this will allow to read in Elements from different sources,
> FD> e.g there mayb be an CVSAccepte, a JSONAccepter, StringAcceptor or
> FD> whatever
>
> Yes, sounds useful.
>
> FD> Presenter(s) (I thought about it in the following way. On an "error" one
> FD> may want to have another color of the field which has points out the
> FD> error
> FD> For how this is done elswhere you can take CLIM as "example".
> FD> Decorators (according to some out line one may want to have diffrent
> FD> colors of lines in a collection to see what belongs to where. E.g even
> FD> numbers are darker than odd numbers.
>
> Isn't this a matter of building some CSS and use the appropriate
> (css)classes?
May be I simply but we have to tell CSS what format to use and here
comes the Decorator into action:
number isOdd: css style: 'odd-line'
number isEven: css style: 'even-line'

At least I do not want tow write that for every other table. so maaybe


e := WebElement new
e Decorator add: ErrorDecorator new
e Decorator add: OddEvenDecorator new.

surely not
| ctr |
ctr := 0

e add: WebGrid new.


self toggleCtr: ctr
...

..

and that all over all the elements..



>
> FD> Validator(s). I think just having a block returning some boolean will
> FD> not work (it will be tedious and not very informative) I suggested what
> FD> to check out for it.
>
> Though I know I need validators I still fail to see how they belong to
> the Web framework.
Well you must use validators if you want to give feedback. How else
would you be able to tell if some Element is acceptable. The validators
are needed in the "frontend" and of course they are needed in the
backend also. The intions are different. In the Frontend, informing the
users in the Backend to keep the Data sound. A WebElement is the
"interface" to the use so need some sort of Accepter/Presenter pattern.
>
> Having read the first 15 pages of the relevant part of Andres book
> seems to confirm that the validators belong to the model hierarchy. My
> Webapp's observee has an error variable which is set by asking the
> validator for it's errors and the Webapp decides on how to present the
> error(s). He has convincing arguments and when I really read this
> chapter I will refactor my validators to conform to the SUnit
> paradigm.
It belongs to the model also, but you need to make round trips to he
server before the model validators have any chance to run. Now if you
know beforehand that something is "not ok". You probably want  to give
immediatly feedback to the user and not after sending a few KB over the
line. Yes validators belong to the model also. But in this case one has
to balance feedback and sound data models. With having a validator
attached to the WebElement you do not have to bother about ad-hod
validators. as in the Example of Aida. And you can see the isValid is
part of the WebElements. So no I don't think you can get away just
having validator on the Model.


>
> FD> amount := new WebElement
> FD> amount validator: MustBeCurrencyValidator new.
> FD> ....
>
> FD> you see the points?
> Yes and the WebComponent consisting of these "fields" would be build
> by the same principle, in the end employing a more complex validator.
>
> But the model should do this accepting and validating. Actually the
> controller. Now that I write this I realize that the controller partly
> lives in the WebApp action methods.
It sits there but also on the WebElement see e.g this:
WebRegistrationApp>> vieMain
there you can see the suggested approach from Janko:
field := e newCell addInputFieldAspect: #email for: self newUser.
        field
                validIfTrue: [:value | self isValidEMail: value];
                errorText: 'Email not valid!'.
You see where the validator is placed. This is a proper place for it but
just having true or false is a bit lacking if you see what Smalltalk can
offer.




>
> FD> Now imagine we want different "aspects" of this object. One could imagine
> FD> having something in an Array.
>
> The following is very interesting but as far as it's described I see
> it only work for simple things.
May all be. It's currently food for thought and it's though to make life
easier for me and also Janko which has agreed to work with me on a port
of my software. But it's should be clear what I want. I want components
and I do not want to bother to handle or render them "each" time I
wanted to re-use part of it.. And so I simply need a way to "just" use
the parts of an object I'm interested in without having to introduce all
kind of helper classes which in the end, end in let's say an Address.

However many of the ideas have sprung into my mind after reading Andres
book. He's very right in it. If we knwo things beforhand, it would be a
shame not using objects which represent this knowledge. And I do not
have to bother to "think" about attaching all this validations etc
during runtime. As Yoda would say "Use the Objects, Luke" ;-)

And we gain quite a lot more than "relief" from remembering all the
details. We surely have classes which we can use all over the
place. Just wait a few months and you have Validators for
"this-and-that-and-not-forget..." ;-)

As I pointed oit elswhere Magritte does quite much in this aspect.








>
> FD> I hope one can see what I mean I want to avoid
> FD> repeating code as much as possible and I want a "high level" expressive
> FD> way of getting the "usual" things done. With acting on the diverse
> FD> events we can go as much into the "how to do things" level as we like.
>
> FD> I do not want this:
>
> FD> showEditableParts: aWebElement
> FD> aWebElement newCell addText: 'TanNr'.
> FD> aWebElement newCell addInputFieldAspect: #tanNr for: self observee.
> FD> aWebElement newRow.
>
> agreed.
>
> For this I have:
> self
>    addTabbingLineTo: e "onEnterTabulate for fast Entry via numeric keypad"
>    header: 'TanNr:'
>    selector: #tanNrText  "invokes the validator on the model"
what happens if the validator fails. where is it handeled?

>
> To iterate over a list to build a component is easy. It will simplify
> the code. And I will follow Andres book in one more aspect: My headers
> are the same as the accessors (except capitalization and appending
> 'Text' for the validation), so with a bit of reflection I will end up
> with:
>
> |headers|
> headers := #('Anfang' 'Ende' 'Radius' 'Parameter')
> e:= self buildInputComponentFor: self observee achselement
>          headers: headers
>          inputSize: 12
>
> With some more reflection over the accessing protocol, I'd just have
> to hand in the object.
>          
> Thanks for the discussion :-)
You're welcome  ;-)

Friedrich
--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
Reply | Threaded
Open this post in threaded view
|

Re: A somewhat better working example

Herbert König
Hi Friedrich,

ok, understood and agreed.

You need a set of Javascript validators which spare you the roundtrip
on a slow line. This is loaded once on page load and the web
framework needs to provide the methods to attach the validation
functions to the inputs.

Then the model only would have to care for the complex validations
(uniqueness for adding...) because e.g. an integer could be relied on
being a valid integer in the allowed range by the time it arrives at
the model.

More or less the same with the decorators and no, i did not want to
write lineNumber odd ifTrue: [.... I meant to give the whole WebGrid a
style class and let the css take care of the odd/even line colouring
et al.

Same as I sometimes use the css class WebGrid when I build
combinations of Texts, inputs, buttons in a table layout.

Cheers,

Herbert                            mailto:[hidden email]

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida