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
> 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="" />
> <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.
I have considered a number of variations along these lines.
Extracting the ordering information and adding a hidden field is also a
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
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 :)
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -