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

[A. Pagaltzis]

* Bryan Roach <opus at b-love.org> [2006-05-05 14:45]:
> >• For controls with callbacks or other custom stuff that
> >  cannot be translated to Javascript mechanically, you
> >  generate AJAX hooks. These hooks do not validate an
> >  individual field, they send the entire form to the server as
> >  if it was a regular POST,
> 
> That could work, but it also seems quite inefficient for larger
> forms.

Hardly. Only textareas with lots of text can really push the size
of a POST; consider that checkboxes, radiobuttons, dropdowns and
the like typically add about 10 bytes each to the size of the
POST, and text fields add maybe 30 bytes each on average. Then
you need at least several dozen controls to reach even 1kb of
data that has to be POSTed. It’s just not a huge deal.

What’s costly is making a request in the first place. Once you’ve
expended that sunk cost, there’s little difference between
sending 17 bytes to the server or 728.

> In my opinion, the DRY principle should never be used to
> determine the way your application functions.

Well I’m not doing that. Whether a single form field gets sent to
the server or the entire form is a question of implementation
mechanics; it doesn’t affect how the UI works.

> With a careful design, you can create a single-field AJAX
> validator function and another entire-form validator function
> without ever repeating yourself.

The problem is that in any complex form there are interrelated
fields. You will need a lot of magic on the part of the framework
to automatically decide the minimum set of fields required to be
able to validate a particular field in isolation. And with
custom validation callbacks, which were the point of this entire
excercise, you have to ask the application programmer to specify
the dependencies.

So you spend server CPU cycles, a lot framework developer effort
and some some app developer burden in exchange for a minor gain
of bandwidth efficiency. I dunno, that doesn’t seem like a
particularly wise tradeoff.

For the cases where data volume might be an issue, I suggest
having some mechanism to exclude form fields from AJAX validation
calls when they don’t have a custom validation callback on the
server; f.ex. a textarea with just a length constraint that can
be checked client-side could then be excluded from AJAX POSTs by
the app developer. Fields with this flag would always consider
themselves valid during validation-only POSTs. This would only
require minimal effort on the part of the app developer and could
be implemented with minimal code in the framework.

> I think the nicest design for this module would be to simply
> have config flags for the three types of validation, and then
> you can turn each type on or off according to your preferences.

Validation-only vs submission POSTs should be distinguished
automatically. The app developer should only need to specify his
wishes declaratively and the rest should happen automagically.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>