Forum OpenACS Development: ad_form all over the place?

I don't know if there's a way to tell ad_form to use a different form template (instead of the standard.adp) though.

But for everything else, ad_form (and the form builder) are great.

-Roberto

I didn't word what I meant right. I knew about the formtemplate tag. What I meant was without having to grok through the bunches of things that happen there.

Have you tried editing one of the form templates to get it to do something differently? I wouldn't say that it is easy, but it could be made to be.

-Roberto

ad_form supports and encourges mixing markup with tcl code. This makes changes to the look of the form, or the editing of the tcl file more difficult, increasing maintainance costs. Hopefully if the datasources don't change, you should be able to employ an html crew to maintain a site, but with ad_form you will probably need your tcl programmer to do the job.

Although it might be thought that having input of content and editing handled by the same form/tcl page, in actual practice I doubt it would be generally helpful. Remembering maintainance of current code, it is much easier to track down bugs if pages have a single function. In the event that the enter and edit pages become significantly different, the maintainer has to somehow perform a 'cojoined twin' type separation. I'm trying to imagine tracking down bugs by looking at the error log. What was the state of the form when the error occured on that page? Even with single function pages, errors that occur when users, not developers, visit a page can be baffling.

ad_form can't be used on a form where more than one object is being edited/input/deleted. This severely limits the usefulness of ad_form. These are things that simple html forms, and ad_page_contact handle with ease.

I think ad_form is more useful with admin pages, as there will probably be less mucking with the look of pages over time. However admin pages are more likely to have complex needs for displaying and editing data. Also, if absolute speed in churning out a UI is important, I think it could help quite a bit.

Of course the main problem is that I don't seem to be able to wrap my simple mind around the idea of ad_form. Maybe if the documentation would explain what vars are set and available in the adp page, based on the different parts of ad_form present in the tcl page, I could figure it out. If core packages are going to use ad_form this kind of documentation would be very important for future maintainers. Asking new blood to maintain a package using ad_form is quite a stretch.

You can, if you want, build your custom look-and-feel form using form templating tags rather than use a standard template.  These go into the .adp file and, just like as is true with the rest of the template system, look like augmented HTML.  For input forms that have to meet a particular look and feel that can't be generalized in a template that's shared by many forms in the system, that's the way to go.

It is simply untrue that the form builder - or ad_form - can't handle pages where more than one object is being edited or input.  ad_form's key management stuff (one of the few things it brings to the table that doesn't exist in the form builder per se) can't be used - you have to do that yourself.  But if you don't use ad_form you also have to do it yourself.  The bottom line, though, is that it can be done.

And indeed most of the forms I've built with ad_form do handle more than one object - a content item and its associated content revision.  Two, not one, objects, in the same form.

I've also used it in the homework package where we link two objects together (homework and correction files) with no problem.

As far as getting your head around it ... it helps a *lot* if you understand how the form builder itself works, because after all ad_form is first and foremost a wrapper that simplifies the use of the form builder.

Of course ... no one is forcing you to use the form builder.

I have practical experience with this at Greenpeace, where I was able to shrink several thousands of lines of hand-built HTML that built forms into literally less than a 100 lines of .adp code in a shared form template.  And the Tcl code shrunk by 3/4 to boot.  Now that was extremely poorly written code I was replacing but I doubt you're going to convince the GP people that going back to hand-built forms written in pure HTML is an improvement.

Curiously previous discussion has developed the theme that automatic form building using type metadata to feed the template system's form builder would be adequate for admin forms but in general forms built by hand (but using the form builder/ad_form) would be necessary for more generalized forms.

Don, having used the form builder procs, I can state that ad_form appears to greatly simplify the situation.

When I said that ad_form supports and encourages mixing markup with tcl code, I was referring to the -html arguments to both ad_form and each individual form element. The example given in the documentation also uses these arguments. It seems pretty clear to me that the form builder generates html, and the use is encouraged by every example I have seen. Maybe instead of showing examples of default behavior, some examples of using the vars generated with ad_form in an adp page would help explain the situation.

The default behavior makes it more difficult to read and edit the tcl file, or understand what the adp will generate without reading the tcl file. The example, or examples, should other important details as well:

As usual the problem is time. I will try to add some of the things that I now know as well as some things Dave B has done in the near future.

I get the points about validation and the goal of making forms more user friendly by presenting the same form with errors clearly marked. It seems helpful for code re-use to use some kind of self-submit page.

Since it is obvious that I don't know how to effectively use ad_form or the underlying form builder in every situation, I would like to start some kind of database of examples for myself. I'm not interested in the default behavior of either of these two APIs, since that seems documented already. What I want to figure out is how do more tricky situations. If anyone has examples they would like to share, please email them to me.