[RESOLVED] Serializing Text and Option value from a select element

[tim042849]

I have developed my own tools for serializing form data for asynchronous calls
to the server (AJAX). I have consider many times that it would be useful that
when a select element has both text and option values to send both values
to the server. I have thought about a couple of different ways of doing
this. But first let me give an example so that there is less chance of
misunderstanding.
Suppose I have a drop-down list that is a select element with an option
list wherein each member of the option list has both a value and a text string.
as in

<select name="state"><option value="1">Alabama</option>...</select>

And suppose I composed my javascript code in such a way that the value
and the code are both included with a separator. Example

&state=1|Alabama&keyfoo=keybar....

and '|' is the separator.
To me that is kind of a 'rigged' solution. I would welcome and solicit any and
all other ideas.
thanks
tim

[rnd me]

change the value attrib to be what you need on the server, or use checkboxes.

[Kor]

I have consider many times that it would be useful that
when a select element has both text and option values to send both values
to the server.

Why? You may set those pairs on the server-side level

[tim042849]

change the value attrib to be what you need on the server, or use checkboxes.

That is not a satisfactory answer. You are proposing that the server-side script
knows what to expect. In my case that is not a solution. It does not
appear that you understand my question. No offense is meant.

[tim042849]

Why? You may set those pairs on the server-side level

Kor, see my answer to rnd me.

[clueful]

I see nothing wrong with using a separator character, although wouldn't it be simpler to ensure that all options have a value as they should have, then the value is always submitted rather than the text?

[tim042849]

I see nothing wrong with using a separator character, although wouldn't it be simpler to ensure that all options have a value as they should have, then the value is always submitted rather than the text?

A practical application, which I have had to deal with numerous times, is
that a value from the option is transmitted, the server-side script has to
provide a review content before committal. The user would want to
see the text associated with the value, as well as having the value itself
stored in a hidden field.
Let's say the use chooses from a dropdown (select) list the following:

<select name="state"><option value="AK">Alaska</option>...</select>

and AK is sent as part of the query. In addition we want the
text to display as in server - side

State:&nbsp;<input type="hidden" value="AK"> Alaska

Personally, I might opt for a non-printing separator.
Thanks for the reply.
tim

[clueful]

Let's say the use chooses from a dropdown (select) list the following:

<select name="state"><option value="AK">Alaska</option>...</select>

and AK is sent as part of the query. In addition we want the
text to display as in server - side

State:&nbsp;<input type="hidden" value="AK"> Alaska

Personally, I might opt for a non-printing separator.

In itself that doesn't explain why the server code can't be coded to 'know' the corresponding text/value. Also it's unwise to allow potentially anything to be sent to an expected parameter.

[tim042849]

In itself that doesn't explain why the server code can't be coded to 'know' the corresponding text/value.

It can be and currently it is.
The purpose of my inquiry is to see how feasible it may be to eliminate something like a lookup-table.

Also it's unwise to allow potentially anything to be sent to an expected parameter.

I don't understand what you mean, but I would like to. Can you explain
the comment above further?
Thank you

[Kor]

That is not a satisfactory answer. You are proposing that the server-side script

That is not a satisfactory answer either. The proposal was the most logical and the best one. In my opinion, of course. No offense is meant. Is there a reason for you can not use a server-side solution? We are eager to listen.

[clueful]

It can be and currently it is.
The purpose of my inquiry is to see how feasible it may be to eliminate something like a lookup-table.

In an earlier post you implied that could not be done.

I don't understand what you mean, but I would like to. Can you explain
the comment above further?
Thank you

Suppose your site reads a parameter in a completely unprotected way like:

if( isset( $_GET[ "s1" ] ) )
 echo "Thank you for selecting " . $_GET['s1'];

Anyone could link to your site and execute code on it:

<a href="http://yoursite.xxx/ownme.php?s1=<script>alert('Owned!')</script>">SAFE</a>

That's easily prevented, but failing to filter anything unexpected could still have undesirable results.

[tim042849]

I'm feeling that the thread started here for a specific reason is moving in
a different direction. Issues of security, unexpected parameters, server-side
vs. client-side are all good issues, addressed by myself or my company or not,
however, I started this with a specific question in mind, and not necessarily for
an implementation but for an intellectual exercise. Actually I am much more
of a server-side kind of fellow and have a good system in place that can easily
manage lookups for values etc... so I want to thank all of you for your replies,
and will now call this solved and unsubscribe.
cheers
tim

[Kor]

Hey, don't take it so hard: Of course you may send both the value and the text of an selected option on using AJAX. You may send them even simply add some hash on the address using location.href method.

But, the best way is to send your data as a JSON object. Just google for AJAX serializing JSON, and you might enlight yourself about that. You can also validate, on the server-side, the possible malicious injections, but this is another subject.