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) :)

Gimme the word, and if I don't hear back soon, I'll commit it.

/Lars

It's been used extensively on a client project for over a month, without any hiccups, but I think the issue would mainly be with widgets that I overlooked, because I didn't happen to use them myself.

I can upload the patch and let you and others try it out before I commit. How's that?

/Lars

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 :)

form create edit \
  -cancel_url $return_url \
  -cancel_label "Cancel"

I used wizard extensively on one of my package.  I can tar it up to you so you can see how its used.  Its damn useful.  I also submitted a very very small patch in the SDM on it.

Just tell me if you want a tar ball of my package and I will email it to you.

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.

When you add stuff such as this to the form builder, does it automatically become available to/from ad_form? I could wade through the code, but...

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.

You didn't commit your changes to ad_form yet, did you?

Because I was planning on rewriting bug-tracker to use these new features, and to use ad_form, today, so I'll be needing them.

/Lars

-Roberto

I missworded my statement here in the forum when I said "support for -section attributes to ad_form".

But I worded it right in my README (http://www.brasileiro.net/code/forms/README-forms.txt) in the tarball I made for 4.6:

"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.

-Roberto

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).

I am envisioning it something like this:

set check [parameter::get_from_package_key -package_key acs-kernel \
               -parameter SpellcheckFormP -default true]


set all_widgets {}
lappend all_widgets \
    [list email_to:text(text) {label "To"} {html {size 30}}] \
    [list email_subject:text(text),spellcheck($check) {label "Subject"} {html {size 40}}] \
    [list email_body:text(textarea),spellcheck($check) {label "Body"} {html {rows 10 cols 50}}]


ad_form -name spell \
    -mode edit \
    -cancel_url / \
    -cancel_label "Get outta here" \
    -confirm_template confirm \
    -spellcheck_template spellcheck \
    -submit_label "Submit" \
    -form $all_widgets \
    -on_submit {

    # send email

}

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.

If you have comments or suggestions, I sure want to hear them now

/Ola

Lars, I *really* like your recent changes to the "standard-lars" template. Truly awesome...

I think it is about time we let that one be the default form template in the toolkit.

(If obligatory fields are left unfilled those entire elements gets a red border when validation fails while the other elements remain purple/background-colored - something like that)

/Ola

I haven't integrated Lars' latest changes to the templates. I will this weekend, when I'm done with my avalanche of homework.

The edit button should take you to the same form, but this time showing it with places for the user to input data.

-Roberto