You don't need Javascript there. The transfer happens in exactly the same way. Maybe you want to learn about the .ajax() or .load() function of jQuery, to make page refreshes keep the "current UI state"?
| [reply]
[d/l]
[select] |
in my case, I want to transfer the data from js to perl in the same script
Note: The js code is generated by the same perl CGI script as well
.ajax() or .load() is to transfer the data to another script/link not transfer data to the same script calls it
do I miss sth here?
| [reply] |
.ajax() or .load() is to transfer the data to another script/link not transfer data to the same script calls it do I miss sth here?
Yes, these methods don't care if you send data to the same script which generated the page in question, you just need a method for dealing with the requests.
| [reply] |
No offense, but by saying "in the same script," you make it clear that you have a fundamental misunderstanding of what's going on.
A CGI script (in any language) runs on a web server. A web browser asks the server for a particular URI by making an HTTP request, and the server runs an instance of the CGI, sending its output to the browser as an HTTP response. This output is typically HTML, but it could be plain text, image data, something else, or as sounds likely in your case, an HTML page that includes some Javascript code.
Your web browser receives this HTML page and executes the Javascript found within it. This Javascript may have been output by the CGI, but it's not "the same script" in any meaningful sense. It's a different script in a different language running on a different machine. This Javascript may now make its own calls back to the server, but these will be new HTTP connections, even if these connections fire up new instances of the same CGI. (Which is possible, since it could send different parameters to get a different response than the browser's initial request got, but it also sounds ugly.) But the CGI instance that was executed to send the page and code to the browser has already finished; there's no way to send data back to it.
To put it another way: HTTP is a one-shot communication method. You ask the server for something, it sends it, and that's the end. You can't talk back and forth with a program on the server end via HTTP. That's why cookies and sessions and other such technologies exist -- to make it possible to maintain state over this stateless protocol, so both ends can "remember" what's going on over multiple requests.
Aaron B.
Available for small or large Perl jobs; see my home node.
| [reply] |