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 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 ( -> 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="" 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 :)

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_.

Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to