Gaute Amundsen wrote:
Hi Gaute,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 TinoI 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 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 |
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )