I want to use the value of the html_p form element to determine how to
validate the body element.

I am having trouble with this because the html_p element is not
created until after the body element.

First I was just going to move the html_p widget, but people seemed to
this it more logically should be after the message body.

Is there any other way to check the value of the html_p element?
I could possibly check this in ad_page_contract, but then I don't get
nice inline error messages.

I could write the entire form template by hand, but that seems
extreme. Is there any way to access the form contents before form
element create is called for the html_p element?

Is it just me or is anyone else concerned with the chunking over the side of ad_page_contract in favor of the form builder procs? My opinion is the .tcl page should be setting up vars for use in an .adp template. If you want to use a different template than the default, just specify the location in the call to ad_return_template. Some parts of the form builder procs are very poorly written. Specifically, template::form get_values calls ns_getform for each value it is asked to get. This requires parsing the entire query set for each value. For a novice like me it takes forever to figure out where the form template is located and to figure out the spagetti code created by this bunch of procs. Sorry for venting, but this approach to coding has so far failed to save me any time on debugging other people's code, an unfortunately necessary past time. Then you get suggestions like Jeff just made to call ns_queryget half way down a page. This is nice and convenient for the developer, but inconvenient for future maintainers. Wasn't there a standard way of doing stuff like this at some point? Why is ad_page_contract even being used in these cases?

The kinds of questions that have arisen lately over the use of this set of procs indicates to me that they are far from convenient to use in anything but the most simple situation.

I will upload it tomorrow as I am not at home now. I will also build a mega form with every option I can think of to show some of the more (shall I say) obscure uses.

Of course I'm just complaining about something I don't know everything about, which isn't exactly fair. I understand Jeff's point about the ugly complaints you get from ad_page_contract. However relegating this proc to a documentation role seems really to chunk good code overboard for no good reason. Maybe ad_page_contract could be given a new switch 'nocomplain' for each var. New status vars could be set for each var/filter that is run. These status vars could be made available to the tcl/adp to control output. ad_form can still be used in this case, it is just that the request processing is handled efficiently at the top of the page.

I'm not going to deal with the seeming mess that is created by having one page perform multiple functions, I guess the developer can choose to do this. Again the main problem is not in developing with this system, but with maintaining it. I get the feeling this code was written for tcl'ers so they can quickly bang out a UI for a simple data model. We (I guess I'm one of 'em) don't really like writing the adp files: they don't do anything!

Why am I complaining? Because maintainers are having trouble maintaining code using this stuff.

Thanks alot.

I actually reverted to using the form builder native procs in forums because it made more sense with the 2 step confirm/add options page flow that forums uses.

Maybe someday it will be rewritten with ad_form, but for now the code works and is checked in using the recommendation from Jeff.

My examples are always self-submit scripts because that means you only have to define or change form element definitions in one place. This is also why I tried to make it easy to write single scripts that handle editing of existing data and the insertion of new data.

Shared code is good ... if it's not overwhelmingly complex, and my hope is that the ad_form wrapper simplifies stuff to the point where this style is simpler than the alternative.

Jeff ... yes, single-value validation is done as you describe. I was assuming that Dave tried writing an ad_form validation block, checking the html_p widget and if set true then transforming the data string to HTML (which doees a html security check) otherwise transforming it to text.

ad_form's validation block is executed from within ad_form, not the form builder itself ...

In ad_form the way you pin an error to a particular form element when you're doing a composite check is to give that form element's name as the tag to the validation snippet. Simple datatype validation errors are handled by the form builder and of course pinned to the element that triggers it.

    {end_date
        { [template::util::date::compare $end_date $start_date] > 0 }
        "End date must be after the start date"
    }

Dave ... I looked at the ad_form code that executes the validation block and all form element values are set before that block is executed.

Can you e-mail me or post here the code that failed?

i am trying to figure out various ways to validate form input data in openacs.

1) via ad_page_contract: this one displays a brief error message and instructs user to use the back button;

2) ad_form validate flag, does this one actually invoke form::element validate, or does it's own validation?

3) form::element validate flag;

finally, i am looking at
http://openacs.org/doc/acs-templating/demo/sandwich,
where the form has inline validation, ie the form is redisplayed with specific error messages.  yet, looking at the code, none of the above options are being used.  what i have noticed that the only field that doesn't generate a validation error when not populated, vitamins, has a -optional flag to from::element.

hence my questions:
1) in the acs-template docs the form::element actually is not documented as having such a flag available; the form::request, however, does...  out-of-date documentation, or does form::element pass the flag onto request (just guessing here, without detailed knowledge of the code).

2) if ad_form is just a wrapper around form templ. functions, is the -optional flag getting set for all elements by default?  in other words, it seems like no validation takes place in ad_form unless i explicitly create validation blocks.  so, i am trying to figure out how the -optional flag factors into this (as in the sandwich example above).

thanks for all your help and patience,

--sasha