[Catalyst] RFC: HTML::Widget / Ajax / Catalyst

[Peter Edwards]

In this case DRY could mean setting up a form definition where you define
form and form field attributes once, then have your scaffolding generate
JavaScript on the form and do equivalent post handler form verification
based on the attribute settings.

The sort of attributes you might have are
- global flag to check input against SQL field types (e.g. no chars in an
int field)
- field flags to override this per field or to do additional checking (e.g.
date of birth range check)
- names of helper JavaScript and perl functions that are
transaction-specific

For doing form validation I think you need
- on lost focus or tab out, do individual field checking
- on form submit, repeat individual field checks on entire set of form
fields and optionally call transaction-specific function
- plus any other JS events you want to handle like mouseover, right click

You could do individual checks by AJAX but I've avoided it historically for
speed reasons. Maybe it isn't such a problem with faster broadband speeds
nowadays.

I've been moving towards trying to use list and form definition files (in
perl Data::Dumper format) to make systems more configurable.

Regards,
Peter

-----Original Message-----
From: catalyst-bounces at lists.rawmode.org
[mailto:catalyst-bounces at lists.rawmode.org] On Behalf Of Len Jaffe
Sent: 05 May 2006 14:48
To: opus at b-love.org; The elegant MVC web framework
Subject: Re: [Catalyst] RFC: HTML::Widget / Ajax / Catalyst



> Bryan Roach <opus at b-love.org> wrote:
> That could work, but it also seems quite inefficient
> for larger forms.
> In my opinion, the DRY principle should never be
> used to determine the
> way your application functions. You should determine
> the best way for
> your application to function, and THEN apply DRY to
> implement that
> functionality efficiently. With a careful design,
> you can create a
> single-field AJAX validator function and another
> entire-form validator
> function without ever repeating yourself.

I think we're on the same page, just different
paragraphs, or maybe I'm just staring at the pictures.

I think it makes sense to pre-validate on the client,
and validate on the server.  I think it maksense to be
able to validate the whole form at once & one field at
a time on the server, and one field at a time on the
client.

Now I personally would probably not use ajax to to
server-side-single-field (sssf) validation unless that
validation required some lookup that could only be
performed on the server side (e.g. insuring that the 
entered location is within 5 miles of an expensive
coffee shop).  But I support your right to do so.

So what we need is smart code that can perform sssf as
needed, and also generate client-side-single-field
(cssf) in JS.  Then we need some code to manage
server-side-multiple-field validation. Not just whole
form, but any combination one cares to define.

once you have all that infrastructure, its just the
busy work of the plumbing.  In catalyst terms, an
action to front end each sssf ajax call, one to
front-end each of the ssmf ajax calls including whole
form, and one for whole form, non-ajax.  But the
difference between the the two whole form actions is
in the view. With ajax, you'll render a chunk of xml
or json, without ajax you'll render a whole page.

I'm going to stick with TT, an formvalidator until my
DBIC legs are firmly under me. 

One major component upheaval at atime. That's my
motto. Well, no it isn't, but you get my point.

L.




_______________________________________________
Catalyst mailing list
Catalyst at lists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst