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 _______________________________________________ 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 )