Hi Richard, I think we're on the same page:
1) Implementing this is usually where I get stuck. Something about pre-generating a key versus creating a key when the form is first submitted.. Anyway, this just needs to be certain to work. Again, I'll follow your example.
2) re: file upload widget. Great! I've gotten lost in the code when trying to reverse-engineer core versions that upload files.
3) The problem may have to do with how ad_page_contract represents date/time components as lists making a list of dates complicated. ad_form doesn't use ad_page_contract, so maybe this is avoided? Anyway, I would need a working example on how to deal with forms like this (for example when implementing in ecommerce/www/admin/orders/fulfill* .
3b)
Without ad_page_contract, we need to verify that the current code cannot be manipulated. All variables will need to be initialized to clear out any url based tampering of forms.
4) Regarding lists of editable and submittable form fields:
This is more for product, category management and accounting /bookkeeping possibilities. End-users would not see these, and admins would have an option to use file uploads etc.
4iv) You wrote "where do you stop? Should all fields in all columns be editable? Like a spreadsheet?"
yes, think spreadsheet or maybe project-open dyna fields / openacs AMS editor etc: http://dekka.com/p2/xowiki/spreadsheet
Anyway, no worries for ecommerce. This is something for other packages in development, and I only mention it, because I have to consider it in the overall backend UI for ec-g2.
I agree to keep the pages light weight and streamlined. ecommerce (and ecommerce-g2) should work via mobile surfing.
cheers,
Torben