Forum OpenACS Development: ad_form Questions

Collapse
Posted by Roberto Mello on
Hi all,

While working on the classified-ads package and using ad_form, I came around a couple things that are puzzling me.

The first thing is that in my tests it seems that the -on_request block is executed every time, even if the form is being submitted. Is that true? If so, we should update the documentation to reflect that, because to my understanding it says otherwise.

Second issue:

classified-ads used form-builder calls directly. I changed some user and admin pages to use ad_form for several reasons. The package allows for custom fields, so there are a couple procs that grab those custom fields from acs_attributes and company and generate template::element::create calls.

I called these custom field procs from the -on_request block. ad_form happily displays and gets the values for these extra fields, but their variables are never made available in the other ad_form blocks (edit_request, edit_data, etc.).

Also, if I call template::element::exists those elements are not found. Reading ad_form's code, it seems that only the elements declared in the ad_form spec are made available. Is that true?

If so, is this an ad_form shortcoming that can be fixed? Or am I wrong and I should just modify the custom field procs to generate ad_form -extend calls outside any ad_form blocks (they are being executed every time anyways, because of the -on_request thing).

Thanks in advance.

-Roberto

Collapse
2: Re: ad_form Questions (response to 1)
Posted by Dave Bauer on
From what I can see in the code, when the edit_request code is run in a seperate level. The ad_form code upvars a variable for each form element defined inside of ad_form to the same level. One solution would be to look through the form element array instead of the internally maintained list of elements in ad_form.

This might make ad_form behave differently but I can't think of a situation when it would.

Collapse
3: Re: ad_form Questions (response to 1)
Posted by Roberto Mello on
A few more questions...

Why do the element flags multiple, to_sql, to_html, optional, from_sql have to be in the element's name intead of with other ad_form element flags (e.g. label, value, etc.) ?

If I declare: {foo:text(text)  {label "Foo"} {optional}} it won't be optional, for example. Only if I do {foo:text(text),optional}.

This looks like inconsistent behavior to me, hence confusing. Of course, I may be missing something fundamental. Right now I don't understand _why_ ad_form has this sintax, so I don't really know if it's broken (in the consistent behavior sense).

But if it is it appears to be an easy fix (and I'm volunteering to do it). We'd have to leave the current behavior valid for at least another release to give time for others to change their code.

Thanks,

-Roberto

Collapse
5: Re: ad_form Questions (response to 3)
Posted by Tom Jackson on

Isn't the declare {foo:text(text),optional} just following somewhat the ad_page_contract filter syntax?

Collapse
4: Re: ad_form Questions (response to 1)
Posted by Mark Aufflick on
Roberto - I agree, that partcular syntax is frustrating. Even if it had to be at the start, at least the list of options coul be a TCL list, and not a comma separated list!
Collapse
6: Re: ad_form Questions (response to 1)
Posted by Don Baccus on
Tom's right ... I just picked the ad_page_contract notation for stuff ad_form needs to know about each variable definition for the element create command.

The stuff you pass along as part of the second element in the declaration are the values for the "-options" flag to the template system's element create command.

This makes sense if you know how the template system works.  ad_form's a *wrapper* only and you really need to study the template system to understand it.  That's unfortunate but without an entire rewrite of a bunch of template code and template client code this is about as good as it will get.

Roberto, to add the custom fields use ad_form -extend.  First define the static part of the form, then ad_form -extend to add the attribute-generated elements, then when you're done with all that call ad_form with your edit_request etc blocks.

I'll take a look at the on_request issue soon.  However, you must create form elements for both the request and submit state anyway (ad_form does this automatically) so validation (an integer is really an integer etc) can be done, the values set in the proper scope, etc.