Forum OpenACS Development: Form-builder display/edit modes

I've made an enhancement to form-builder, which I'm ready to commit
to the repository.

What it does is let you add a "-mode display" switch to your form,
in which case it'll be displayed in "display" mode, meaning that
instead of an input/select/whatever widget, the value is displayed
in straight HTML. You can also set "-mode edit" or "-mode display"
on each individual element in a form, thus overruling the default
for the form.

I developed it for a client project, but it's also very useful for
applications like the bug-tracker (http://clients.museatech.net/bug-
tracker/), where I like to display the bug form with different
fields enabled, depending on the action you're taking.

It's better than using inform widgets (which is what I did for bug-
tracker) because it's annoying when you have a select widget where
the value isn't the same as the label. The enhancements I've made
changes each widget to display itself differently depending on
whether it's in display or edit mode.

Another small change is the ability to add control the number, name,
and labels on the buttons below the form, instead of only having one
with a hard-coded label of "submit". You do this by saying "-buttons
{ { "OK" ok } { "Cancel" cancel } }" when you create the form. If
you don't say -buttons, the default submit button will be created.

This is useful if you like the OK Cancel convention that I happen to
like. Or if you need more buttons as in the bug-tracker (Edit,
Resolve, Close, Reopen, etc.). Handling what happens when you click
those other buttons is entirely up to you and how you handle your
form submits.

This touches a lot of places in the form builder code, so there
might be unintended side-effects that I didn't test for, e.g. with
dotLRN, or with Don's ad_form stuff.

The question is: Any objections to me committing this now? Should I
wait a bit to not obstruct any development efforts going on? Or will
you be able to handle it allright? I know, we're using a version
control system, but it's always annoying when things inadvertently
break (not that I think they will) :)

dotLRN's supposed to deploy in a couple of weeks and OF and furfly are working actively on the OpenACS tip so if your code were to break things a few of us might be unhappy. OF uses the form builder heavily (yay!) and furfly has too in our two packages.

How well has this been tested?

I've got some trivial commits of my own to make to acs-templating, including making "date" a real type rather than simply a funky widget (it uses the same widget so everything's backwards compatible). I need these for my (modest) dotLRN work.

I like the "-mode display" addition. ad_form currently supports "-confirm_template" which allows you to specify a template in the "OK Cancel" style displayed for confirmation before ad_form executes the "-new_data" or "-edit_data" clauses. Your "-mode display" gives ad_form a way to generate confirm pages without the need for the user to write their own confirmation template, and that's cool. A user will then be able to use "-confirm" if they're lazy/satisfied with the automatically generated page, "-confirm_template" if they want more control. Yeah, sounds pretty cool alright!

"-buttons" is good, too. I did something similar for Greenpeace but made a "button" datatype with widget instead of adding a special switch. We might want to compare notes before deciding which approach is best. Something that allows us to generate multiple buttons is certainly needed.

The only advantage of having it as a type is that the user can insert it anywhere in the form, and can use it with standard element stuff like "html" (think JavaScript).

But my Greenpeace code for this is a bit of a hack, IIRC ...

Maybe you and I can test this a bit more, decide which "button" approach is best, and I can add some integration with ad_form and then we can commit it? In (say) the next week or so?

buttons ... hmmm ... one reason I went the type/widget approach is that the form builder already had a "submit" widget (or type? I need to look). I think this approach fits in as they really are form elements.

Anyway I'll try to spend a little time this weekend looking at my GP button type/widget hack to see just how ugly it is :)

where cancel_label would be "Cancel" by default or the i18n-ised default, and the button would only appear if cancel_url is specified? This would fit in better with the self-describing api of the form builder IMHO.

Where's this patch you submitted to the SDM? I looked for it but couldn't find it (didn't look very far, admittedly).

-Roberto

P.S: I found out why the images for checked/unchecked were not being shown in display mode: they are not in 4.6, so I had to copy them from HEAD.

P.S2: I modified ad_form so it works with Lars' -mode switch to the form builder, and also so elements accept the "section" attribute. They are both one-liners. Should I commit this to HEAD or submit a patch?

Jeff Davis has accepted it, should be in 4.6 already. Its just a simple html bug. That should display the wizard steps/progress on right side properly.

Also if you would notice in my wizards I resuse the forms in the steps. For example on wizards that needs to pick a content folder. I just use folder-list.tcl on it. So picking an image, page, file or folder uses the same ad_form over and over again. Almost all ad_form are reused, so I have to be careful not to duplicate the state variables names. If I 2 or more ad_forms that sets the same state var then the lastest form to set it will overwrite the previous ones.

The form builder wizard, well its not actually restricted to forms. The wizard gives you nice good api to make a series of pages in sequence. Normally the page contains the forms built by either ad_form or the normal template calls.

You can define the state variables that you want to keep across the steps. The way it technical does things is this way:

step 1 is a form... it submits the form and it gets processed, if you are using ad_form on_submit may define to tell the wizard to step to the next step, which is step 2. It then returns a redirect to the next step together with any state variables that was set on the previous steps.

I modified ad_form so that it could take advantage of Lars' latest modifications, and also backported his mods to 4.6.

I also modified ad_form so it'd take section attributes to form elements. These were really small changes, but they work nicely. I'll be providing the patches as soon as I finish the Changelog for 4.6.

No, I had not committed my changes to ad_form yet because I wanted to make sure they were working right, and to make them available for OpenACS 4.6.

I made a tar ball with all my changes, and everything one needs to get all of this to a stock OpenACS 4.6 tree. It includes your recent additions (which rock, btw), DanW's recent modification to ad_form (set form vars from edit_request block, which is also very nice), and support for -section attributes to ad_form (full README on my web site).

I also made screenshots, ad_form'ized your display-edit.tcl/adp, modified stardand-lars.adp to use CSS and to display multiple checkboxes in a better way.

This has a little less typing to it when there are many elements in a section, but it's just a matter of taste.
The oter way of specifying sections is Roberto's new way - http://brasileiro.net/code/forms/ .

"Added support for the templating system's -section attribute to form elements, to ad_form"

which is accurate. ad_form's 1.1 implementation of -section may be interpreted differently in the future from the element attribute -section that I added support for.

The non-element-attribute section would be (in my view) a way to generate a separation between elements. Whereas the element attribute -section could be interpreted as a way to group elements together, even if there's no visible separation row like the current standard.adp template for forms generates.

In summary, I think they serve different purposes, but maybe Lars should answer that as he can explain what was in his mind.

Apologies to all, but in the process of upgrading bug-tracker to make use of the new form builder display/edit mode feature, and the new button features, I realized that I hadn't designed the quite right the first time.

So now I've committed a new version.

It's mostly the same, but:

- The form builder now handles the logic of which buttons to display, e.g. when you say -have_submit, or when you switch between display and edit modes, etc.

- There's a new "action" feature, where you can have buttons for actions on the "display" version, which cause the form to go into "edit" mode, and to pass on the action using a "form:action" hidden variable. See the latest version of bug-tracker on HEAD for an example of how this works.

FYI, I am working on integrating a spellchecking facility into the form builder/ad_form which is going to use aspell/ispell and be based on (3.x) work done by Jin Choi and Eve Anderson from aD.

I hope to have this working within a few days or so if all goes well ...

My current idea (but I'm open to other suggestions) is to add some switches to ad_form; "-spellcheck_template foo" and "-spellcheck_label {Check Spelling}" (plus a "-submit_label {Blah}" and possibly a "-confirm_label {Confirm Forum Posting}" while I'm at it - but that is unrelated to spellchecking). Even though the spellcheck_template (which takes care of all the spellchecking) in a way permitts confirmation of the submitted text(s), I think we should be able to specify a confirm_template at the same time as spellchecking is specified, and that it should jump in after you're happy with the spelling (if indicated by the script, that is).

Many elements can be spellchecked (I'm hoping) but not all have to be. The developer can choose only some of the text/textarea elements as s/he sees fit. The site administrator can enable/disable spellchecking on a whole site via a kernel parameter (if the developer uses the technique showed above when setting vars).

From the user perspective:

The user faces a big form - now, if the developer has specified spellchecking on one text field and on one textarea, say, and has also specified a spellcheck_template that is working, the user will not just see a single "OK" submit button but will also see a "Check Spelling" button (and maybe also a "Cancel" button which will be the button farthest to the right). When the user hits the spell button s/he is sent off to the spellcheck_template and, after eventual spelling correction, sent back again (or to the confirm_template) ...

I think it would be possible to make this feature available to the form builder (and not only to ad_form) or that it is at least something to strive towards.

Either I have a completly hosed system or your patch is missing something.

As a test I took the code off of your site and when I run it, again the edit code doesn't work. Can you please try this on an upgraded system (if possible) and let me know. Or send me a know working file set .adp,.tcl and I will try it again.