Forum OpenACS Development: Response to ad_form and ad_page_contract integration

Collapse
Posted by Don Baccus on
I'd personally prefer extending ad_form to allow the use of ad_page_contract filters on submitted form variables.  This would be relatively simple to do.  I caught a bit of the conversation on IRC (lurking) and I think this is a reasonable thing to do.  They'd be applied after form validation.

I guess it is worth asking if things like "trim" should be added to the acs-templating form handling code itself or not.  ad_form currently is meant to be a wrapper around that, though it does do one important thing not found in acs-templating (automated key generation that defaults to the acs_objects sequence).

When I first thought about writing an improved form handling utility I started with the assumption that extending ad_page_contract would be the thing to do.  The problem I ran into was that when considering all the different cases that need to be handled things rapidly become very complicated.

Consider the relatively trivial case of validation blocks.  One could add the necessary bookkeeping to track whether or not the item being validated should result in an error embedded in the form or an error page ala ad_page_contract.  Not the most complex thing in the world but ad_page_contract and ad_form are already fairly complex and I'm not eager to add to it.  We could implement two types of validation blocks and simplify the megaproc but would this be any more clear, really, than two separate calls?

Also there is value in allowing dynamic code before building the form.  This was what really led me to implement ad_form as a separate proc rather than extend ad_page_contract.

Having code before the ad_page_contract code would be worse than ugly - one of the reasons for ad_page_contract is to encourage people to write informative comment blocks that show up at the very top of the script, not buried after some initial code has been executed.

We'd still need ad_form to allow for extension of an already defined form, which is necessary.  Check out the way I use Tcl library procs to build up common form elements in gp-multimedia, for instance.  Think about building forms with a variable number of elements.  One could build the form block dynamically then pass it into ad_form (or ad_page_contract) but using "-extend" is much simpler.  I know because that's what I did when writing gp-multimedia before adding "-extend".

I personally dislike the idea of allowing the declaration of stuff like "html" separate from the form block defining the form element because I like having the form defined in one place.  I can understand a form that's declared in place, I'm not sure I can understand one that's defined helter-skelter in pieces scattered throughout a script.

The form handling portion of acs-templating only gives you one way to define inline messages not associated with a visible form element - you can set an error on a hidden form element and I believe that error will be displayed in the form (haven't tested it, though).

But the paradigm I'd like to encourage for coordinating use of ad_page_contract and ad_form would be to only handle queryvars in ad_page_contract that are controlled by the programmer rather than entered by the user.  In this case, then, failed validation should only be caused by a bug in the code or by someone spoofing form data by generating their own POST requests to the site.  In either case I think an error page is OK ...

These are my thoughts, at least.