PDA

View Full Version : Passing variables from JS to ASP


paulafernandes
11-25-2002, 11:56 AM
Hello! I´m new at JavaScript, so I'm sorry if this is a basic question, but I really need your help...

I have in a ASP page a JavaScript that creates two listbox, one (list1) is populated from a database table, and the user selects items from this listbox to the second (list2). I also have a Javascript function that stores in a variable the values selected in list2.
My question is:
How can I pass this variable to ASP so I can store those values in the database?

If someone can help me, please do!!!!

Thank's!
Paula

glenngv
11-25-2002, 12:03 PM
simply put the value of the variable in a hidden textbox;

//store in myVar some values here, then put in the hidden field below
document.formNameHere.hiddenFieldHere.value = myVar;

when the form is submitted using POST method, you can Request.Form this field, then store them in the database

RadarBob
11-25-2002, 04:12 PM
When using <form ... method="POST"> any selected items from a dropdown list automatically go to the server. This is also true for multiple select(ed) items. An intermediate variable, hidden or otherwise, is not needed.

If you have this on the client:
<select multiple name = "myList" >
Then reference it like this on the server (VBScript notation):

for i=1 to request.form("myList").count
someVariable = request.form("myList")(i)
next

Note that the "myList" array in the request.form starts at one, not zero.

glenngv
11-26-2002, 01:08 AM
Since the user adds items from 1 listbox to another, when the form is submitted, the code has to select all items (in case of multiple-select) in the 2nd listbox to be able for the server to read all the items added. But since Paula keeps track of the selected items in a variable, the easiest way is to put it in a hidden field so that she would not have to select all items in the 2nd listbox. In an end-user perspective, if he submits the page, he would see for a split second the highlighting of all the items in the 2nd listbox. That I think is not user-friendly.

Hope that makes sense :)

whammy
11-26-2002, 01:35 AM
Hmm, it doesn't matter what the user sees for a split second, IMHO... as long as it works...

BTW "Paula" is a girl's name. ;)

glenngv
11-26-2002, 01:53 AM
Since Paula keeps track of the selected items in a variable, IMHO, I still think putting it in a hidden field is the best way to go. Plus the fact that selecting all the items programmatically will cause some amount of delay (maybe small or big depending on the items) because you have to loop through all of the items.

I know Paula is a girl's name. I only used "he" when I said "In an end-user perspective" ;)

whammy
11-26-2002, 02:14 AM
;)

RadarBob
11-26-2002, 01:58 PM
Originally posted by glenngv
Since Paula keeps track of the selected items in a variable, IMHO, I still think putting it in a hidden field is the best way to go. Plus the fact that selecting all the items programmatically will cause some amount of delay (maybe small or big depending on the items) because you have to loop through all of the items.


I too have been concerned about how the user would see everything, all of a sudden, selected, as the page was processing. But I've decided to accept that quirk.

Pulling everything over to the server is a significant design feature of my web page. I decided that for the sake of explicit coding, debugging, testing, and data integrity that I would pass all data values, checked/selected/etc. or not. For example a not-checked box is "NO", and I want "NO" to be explicitly passed to the server and into the database.

Otherwise, in the absence of that field, the server-side code must assume what the value for the absent field must be. The immediate question becomes then, "did that bonehead Bob screw up his code again?" IOW, is the field missing on purpose or is it a bug? With my scheme, if the field is missing, it's a bug - no question.

Second, my technique keeps me from having to write code for specific values on the server. If ever I must make changes to a particular field, the changes are minimal, if any, on the server side; primary isolated to the client side (and database). IOW, the server, not concerned if a field may or may not get passed, always looks for it, and in deference to the concern about performance, the server doesn't have to evaluate the field, just pass it to the database.

Overall I think my scheme tends to limit unnecessary code complexity and minimizes the obsfucation factor. I don't have to write for the "it's not here" exception, and I don't have to create extraneous hidden variables, and all that code, to handle the data the rightly belongs in/with another field.

The Performance Factor
Finally, after adding hundreds and hundreds of lines of client-side javascript and hundreds of server side lines to our existing web pages, and getting "that look" from other programmers when they see "how much" code I've written; I've learned one thing. The concern about performance is generally overblown.

Today's GUI interfaces - Windows, MAC OS X, etc. - are what slows things (oh, and 33k & 56k modem connections), not chewing on a 10 element array for cryin' out loud.

My pocket calculator is faster than the IBM mainframe I learned to code on years ago. Quit coding like memory is still measured in kilobytes, CPU cycles are measured in milli-seconds, and compilers don't optimize.

And besides adding more code to handle a hidden variable to handle a variable/field that doen't need extraneous handling goes against that invalid assumption anyway! The <select> object exists, it's data structure exists. The computer had to build all that. SUBMIT processes it anyway, whether you make it get passed or not. You've already paid that overhead (insignificant as it is); why create more?

Code for a near-bullet proof web page interface (nothin's perfetc) and rock-solid data integrity. Code for your users, not a "that looks about right" sense of how much code is enough.

whammy
11-26-2002, 11:55 PM
That's basically my approach... I use the Bruce Li programming method:

"Use what works".

Sometimes the code in place at work may not be the most elegant solution, but it was done fairly quickly, it works very well, and I can move on to the next project before my "IN" box gets filled with stuff. :)

paulafernandes
11-27-2002, 10:59 AM
Hello!
I just want to thank's all the help.
I decided to use the hidden input to store the values and it works just fine!

Thank's!!!!
Paula

P.S.: Yes, I'm a girl!!!!! :o