[Seaside] Are there any form input components that do javascript

[Avi Bryant]

On Wed, 26 Jan 2005 10:51:56 -0800 (PST), Mike <me at mikehogan.net> wrote:

> Great, I get a chance to be the customer :-)  Here is what i think
> should be supported, based on what I have seen done on other
> sites, and on what I want to do with my own.  I am happy and
> willing to try to implement some of this, once I am guided where
> best to place it.

Hi Mike,

Sorry not to respond sooner, I'm a little swamped these days.

One thing I read recently that would be interesting in this context is
the A List Apart article on "Javascript Triggers":
http://www.alistapart.com/articles/scripttriggers/ .  The basic idea
is very simple: just make up some extra attributes for things like
validation, put them into your HTML, and then have scripts run through
the DOM looking for them and attaching the right handlers dynamically.
 One thing that's appealing about this to me in a Seaside context is
that I hate having little snippets of Javascript generated by
Smalltalk - it would be ok if we had some library at the level of
HTMLRenderer that did it*, but all the string maniplulation makes me
wince every time.  This would separate all the JS into a nice simple
external script file, and let us encode the validation info much more
simply.

That seem like a reasonable direction to take things?  It should be
pretty easy to get started that way - no special Seaside voodoo
needed, just attrs and scripts, but if you have more questions just
ask...

Avi

*Cees has talked a couple of times about how cool it would be to have
one piece of code that did validation in both Smalltalk and
Javascript, which you could do with a GLORP-like trick using blocks -
so, say you have a validation block like [:ea | ea size <= 10], you
can either pass a string into that and validate it on the server, or
you can pass a parse node object in which uses the Interpreter pattern
to build up a parse tree and spits out JS from it.  Someday somebody
should do this.

>  * It should be possible to group all the validation errors from
> all the offending fields in one place in the page - at the top
> say.
>  * Altervatively, if should be possible to place the validation
> errors beside the offending form fields
>  * It should be possible to highlight the offending fields in red,
> lets say.
>  * The validation errors should be shown as content of the page,
> not as javascript alert popups.
>  * I can't decide between onblur() and on submit (typical customer
> :-)).  One of the best web UIs I ever saw had a fat status bar on
> the page, coloured in red, informing the user what he had to do to
> the form to make the status bar green, indicating the form was
> submittable.  Initially the red status bar says "Enter a
> username", when you enter one and tab to the next field, it says
> "enter date of purchase", when you tab out of that, and the date
> is invalid, the red status bar says "invalid date".  Etc etc.
> Eventually the bar turns green, and the submit button on the form
> is enabled and bobs your uncle as they say.
> 
> Is that all too ambitious for now?  I do think seaside should
> support this kind of interface eventually, but I have no idea how
> to road map it.  But just to get started on something for my
> current web app, I would be happy with something like:
> 
> html textInputWithValue: [] callback: [] constraints: #(date
> mandatory)
> 
> which would do client side validation when the submit button is
> pressed, and shows all error messages in one span or div some
> place on the page.
> 
> Not too demanding, am I!
> 
> How should I best proceed?
> 
> Thanks very much,
> Mike
> 
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
>