[Zope] REQUEST.form variables order

[Gaute Amundsen]

On Thursday 20 April 2006 15:46, Tino Wildenhain wrote:
> Gaute Amundsen schrieb:
> ...
>
> > The order of the form elements that goes into mail headers is ofcourse
> > irelevant. I'ts the rest of the form, you know name, adress, street, etc.
> > that are the problem.
> > It's a purely visual thing, but when you have a form with perhaps 50
> > fields, that the client has carefully grouped and ordered, they can get
> > rather pissed if you try to tell them they can only have it in
> > semi-random or alpabetic in their mail.
>
> ...
>
> > A smiley or two helps, but now I would say you are bordering on arrogant.
> > What more do I have to explain to convince you that I understand what the
> > problem is?
>
> We would have saved time if you provided the very usefull information
> first :-)
>
Well, it's amazing how what seems clear to one can be quite opaque to another.
I will try to be more explicit next time.

> Now you are building some kind of table/list with
> form-field-name: form-field-value  - am I right?
>
> how is it supposed to handle checkboxes, radiobuttons
> and select fields?
>
Hm.. I can't recall how I did that. I just made a reiplemetation of how 
formmail.pl did it.
But anything it does, it does looping thru request.form, so I dont think this 
is relevant. 

> One possible workaround, if you dont want to touch
> ZPublishers form handling would be to run a script
> to not only update the forms target (formmail.pl -> zopeform)

I use apache "proxy rewrite" for that, no update needed.

> but split every form element from
> <input type="text" name="foo" value="" />
>
> into
>
> <input type="hidden" name="body.name:records" value="foo"/>
> <input type="text" name="body.value:records" value="" />
>
> which you easily get as list of name/value pairs in
> the form variable "body".
>
> You can even make this transformation any time a user edits
> her HTML source - save the users source in a property and
> transform this source via some regex or HTML parser
> to what you really want here.
>
> Moderate work and you can even add some sanity checks :-)
>
> If you can provide some typical samples of the HTML you
> are facing I believe you even can get help with the
> transformation script.
>
> Regards
> Tino

I have considered a number of variations along these lines.
Extracting the ordering information and adding a hidden field is also a 
posibilty. 
But the potential for messups, and big pain, with a script altering large 
amounts of user content, is not inconsiderable I would say.

I still think my own idea of adding a small proxy to transparently add that 
"hidden field" is rather more elagant.

I expect I will go with Andrew Milton's idea however, since that keeps us 
inside zope, and seems simpler to implement.

I would have prefered to go to the root of the problem, that allways works 
best in the long run, but it seems I have managed to avoid the effort this 
time. 

I still think it is something zope should handle, but for me it is only a sort 
of medium-term stop-gap measure, so it will do.

Thanks for your attention :)

Gaute