Forum OpenACS Development: ad_form builder comments

Collapse
Posted by Jon Griffin on
I am in the process of updating acs-person to use ad_form and am stuck.

It seems that it is a requirement to grab the next sequence # if you don't pass the key value. If this is the case it is plain wrong. My plsql procs don't need a key value to create a new object. This saves sequence ids (not such a big problem) and is less code for me to write.

Is there a way to tell the form this is a new submission without having to call the sequence? Maybe I am missing something, but if someone could convert notes (as a simple example) to ad_form that would answer many questions.

Here is one example of what needs to be converted:


if {[template::form is_request new_person] && [info exists 
acs_person_id]} {

 template::element create new_person acs_person_id 
    -widget hidden 
    -datatype number 
    -value $acs_person_id
As you can see this only creates the element if it exists.

Also, -select_query_name bombs out. Has anyone used this?

Collapse
Posted by Dave Bauer on
Jon,

If you are not using the same form for new and edit you can use -on_submit instead of -new_data/-edit_data.

-select_query_name should work fine, but again works along with the key field to select the row that is to be updated. The key field ties in with the state-management of ad_form.

Collapse
Posted by Don Baccus on
What are you doing for double-click protection if you're not pre-allocating the sequence ID?  Just trapping on other fields that are restricted to being unique?  What if there are no other columns other than the object_id that are so constrained?  Then without object id preallocation you get no double-click protection, right?

As Dave points you can use an on_submit clause if you decide not to use the built-in key allocation.  But using the built-in key management feature of ad_form shouldn't force you to write extra code - it's done for you automatically.  Among other things it makes it simple to use the same script for both editing existing data and adding new data in many cases.  And this is good because it means the form need only be declared once rather than in two separate scripts.  This should increase maintainability because you only need to make changes to the form in one place ...

-select_query and -select_query_name only work with the built-in key management stuff.  There may be some bugs regarding error checking if you're trying to use it without the built-in key management stuff.  I'll take a look at this.

If I were to rewrite the notes package to use ad_form I'd  use the built-in key management stuff.  The code would be much shorter, very easy to understand and would provide minimal ACS 3.x-style double-click protection, which the current notes package does not.  The current notes package will cheerfully double enter your note if you get bored and double-click the form (or triple click, quadruple click, etc).  This is "functionality" I would happily drop rather than attempt to replicate using ad_form.  While ACS 3.x-style double-click protection isn't perfect it's better than nothing, no?

Another thing ad_form does is to sign and verify the key it generates, giving some protection against bogus POST data.

At one point I had an on_request block implemented but didn't put it into the final ad_form that's in CVS because I didn't think it would be very useful and felt like I'd rather encourage folks to use the built-in key management feature for objects, at least, for consistency and simplicity.

Collapse
Posted by Jon Griffin on
That makes sense. I will try to update acs-person before the code freeze if it hasn't happened already.