[Zope] REQUEST.form variables order

[David H]

Gaute Amundsen wrote:

>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
>  
>
Hi Gaute,

I saw this in a Goodman Javascript book "Elements:  A collection of all 
elements w/in a form ... Collection members are sorted in source code 
order".  So, you could standardize a javascript <process> function that 
loops thru the elements naming each one? 

If such a thing could work that you just need to include the ../javascript.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/zope/attachments/20060420/d246bde7/attachment.htm