Forum OpenACS Q&A: Re: E-commerce 'category-browse-subcategory.tcl'

The questions you raise are very good ones, and I wouldn't pretend to have all the answers. My first thoughts though are as follows:

1) My understanding was that one of the benefits of using the API layers is that protection against such basic possibilities would be provided. I am certainly not aware of having had any problems caused by that in the code I have used template::form for.

I can see that with a shop where there is the possibility of placing multiple identical orders, or taking multiple payments, that this is very important indeed.

My, probably naive and complacent, assumption has been that as long as every row that you write from a form to a db has a primary key of some sort, then your protection against this happens where it actually should be happening - inside the RDBMS.

There is an article on Jon Griffin's site that provides an example of ad_form use and mentions that double click protection is built-in by pre-constructing the primary key. Is this just another way of saying what I have just said? It would also be possible to put a select query in the form validation step to look in the target table for the relevant primary key before doing the insert.

http://jongriffin.com/articles/10/

It is quite old and talks about ad_form rather than template::form but may still be useful.

If there is a specific issue that I haven't grasped then please let me know so I can research it.

As far as having to process data in sequential files is concerned, I haven't checked yet, but I'd be astonished if there isn't an option to change the default action to point to another tcl file. Failing that you could do an internal re-direct once you establish that the form has been submitted. In the end, failing all else, for specific cases you could fall back to the old way!

2) Funnily enough, the same Jon Griffin article covers diong this:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
File upload widget

ad_form -name upload_test -html {enctype multipart/form-data} -form {
{upload_file:file {label "Enter a filename or use the browse button"}}
} -on_submit {
set filename [template::util::file::get_property filename $upload_file]
set tmp_filename [template::util::file::get_property tmp_filename
$upload_file]
set mime_type [template::util::file::get_property mime_type $upload_file]
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Clearly this needs to be de-constructed and re-coded using template::form semantics but at least the basics are there.

3) I am not sure why this is seen as a problem. I would expect the built-in date widget to serve the purpose. I am not aware of any restriction on the number of date widgets in a form, or on the number of forms on a page.

https://openacs.org/api-doc/proc-view?proc=template::widget::date

4) I should probably break cover here and own up to the fact that I loathe it when lists of things have editable and submittable form fields on them! 😊 YUK!

Dave's suggestion of an Ajax helper is a creative one but I still don't like it. I understand the benefits of minimising clicks, but really, clicking on an edit link in a list is no more effort (or clicks) than clicking in a form field to activate it and give it 'focus'. In any case, on a long list you can end up:

i) with a massive page that is very slow to load

ii) losing track of the fields you've changed as they disappear off the page, and having trouble finding the submit button.

or

iii) if the list is paginated, either having to keep track of pending edits whilst the user pages backwards and forward, or forcing the user to commit edits with one of those horrible 'update cart' links before he can continue paging through the data!

and

iv) where do you stop? Should all fields in all columns be editable? Like a spreadsheet? Over a stateless protocol? This gives your page immense destructive power and makes it very difficult for you to provide a user with a simple and safe way to verify accurately that their intended changes are correctly recorded prior to submission. Your options become quite limited and your user could easily become overloaded and make costly mistakes.

What is wrong with the current design standard where you display a list and provide edit and delete icons on each row for editing them? A simple form is presented which is intuitive, and once dealt with the user is returned to where he came from.

By the way (owning up to vested interest) - I have a 10 year old laptop and am frequently using it on mobile connections, and my browser absolutely hates trying to deal with those mammoth list/form nightmares that I encounter on lots of .asp based websites! 😊

Regards
Richard