[Javascript] JavaScript to PHP variable transfer
Roger Roelofs
rer at datacompusa.com
Thu Aug 21 14:09:38 CDT 2003
Dave,
My head is swimming. What data transfer mechanisms _does_ the server
allow? If you can't GET with a querystring and you can't POST, how do
you get any data from the client to the server?
If you _can_ do either of these, then you can create a hidden iframe to
manage the transfer of data back and forth. I have a situation where I
have a hidden form with one field that I populate with javascript and
submit to the server. It is targeted at a hidden frame, so the user's
page is never disturbed. Will this model work? If not, why not?
On Thursday, August 21, 2003, at 02:44 PM, David Lovering wrote:
> It is a bit more complicated than that. For example, if field
> "Protocol" is "Frame Relay", then a whole raft of fields on a side pane
> for frame-relay parameters suddenly become meaningful -- yet at
> the same time some fields related to "circuit-id" remain applicable, as
> they would for situations where "Protocol" was "TCP/IP". Anyway,
> the cross-over between which fields do or do-not apply between
> all these complicated scenarios makes it impossible to separate out
> the "common" variables from the "special" ones.
>
> Also, POST variables don't work with the current security paradigm.
> Sigh.
>
> -- Dave
>
> ----- Original Message -----
> From: "John Warner" <john at jwarner.com>
> To: "'[JavaScript List]'" <javascript at LaTech.edu>
> Sent: Thursday, August 21, 2003 11:10 AM
> Subject: RE: [Javascript] JavaScript to PHP variable transfer
>
>
>> What tells the client that the form is to be used for transaction type
>> '1' vs type '2' etc? Could you draw your Form on the fly based on
>> that,
>> client side document.write ... code to create a 'limited' form and
>> thus
>> reduce the number of fields needing to go back to the server? Then in
>> your server code figure out what the client is doing. This way you
>> ought
>> to be able to share values via post and still limit bandwidth
>> requirements.
>>
>> John Warner
>> mailto:john at jwarner.com
>>
>>> -----Original Message-----
>>> From: javascript-bounces at LaTech.edu
>>> [mailto:javascript-bounces at LaTech.edu] On Behalf Of David Lovering
>>> Sent: Thursday, August 21, 2003 1:49 PM
>>> To: [JavaScript List]
>>> Subject: Re: [Javascript] JavaScript to PHP variable transfer
>>>
>>>
>>> Firstly, the client and the server are on opposite sides of a
>>> secured pipe -- and CGI/BIN stuff and cookies have both been
>>> shut off. Completely. Non-negotiably, and forever. I barely
>>> have the means to do session-variables (sans cookies), and
>>> can't rely on it because they are talking about shutting
>>> session-variables down on the server. Anyway,
>>> session-variables without cookies is pretty much a useless gesture.
>>>
>>> Secondly, there are several thousand miles between the client
>>> machines and the server(s), so latency can be an issue -- and
>>> a full-fledged forms dump typically takes longer than merely
>>> porting one or two variables back and forth. Multipled by
>>> tens of thousands of forms transactions per-day, this would be bad.
>>>
>>> Thirdly, there are many different scenarios governing what
>>> fields will be selected for transfer, and some of the fields
>>> (if sent empty) will have radical and wrong interpretations
>>> at the other end. In essence, the same "form" is used for
>>> about twenty different and very complex purposes. Simply
>>> doing a "submit" sends everything in one hellacious mass. If
>>> these fields could be subdivided into neat little clumps for
>>> each scenario, I could make lots of little forms --
>>> but the
>>> overlap is about 86%, and the customer spec won't tolerate
>>> reloading new frames with "appropriate" forms for each scenario.
>>>
>>> Fourthly, the nature of the pipe driving the server has some
>>> rather stringent bandwidth issues (which we are trying to
>>> deal with). Not only are we trying to move as much of the
>>> validation and forms pre-processing as possible onto the
>>> clients (using JavaScript and Java), but also working
>>> vigorously to limit the amount of back-and-forth transfers
>>> the ordinary sort of transactions might require.
>>>
>>> Lastly, we are trying to improve the speed of the
>>> transactions -- and forms processing on the scale we are
>>> talking about exceeds our specifications for turn-around.
>>> Wish it weren't so, but it is.
>>>
>>> Now you know what kind of mess I'm dealing with.
>>>
>>> One of the key sticking points that this picture causes is a
>>> need to follow the JavaScript DOM chains from window to
>>> window, pulling key bits off of different panes and then
>>> presenting them in an acceptable form to the server PHP
>>> functions for accessing the various database(s) this
>>> application is built around. Having a relatively painless
>>> way for PHP to interrogate JavaScript for both the DOM
>>> mapping and the field values on-the-fly would be a tremendous
>>> help, particularly as the screen content can be selectively
>>> varied on a rather massive scale.
>>>
>>> Capiche?
>>>
>>> -- Dave Lovering
>>>
>>> ----- Original Message -----
>>> From: "Mike Dougherty" <mdougherty at pbp.com>
>>> To: "'[JavaScript List]'" <javascript at LaTech.edu>
>>> Sent: Thursday, August 21, 2003 9:54 AM
>>> Subject: RE: [Javascript] JavaScript to PHP variable transfer
>>>
>>>
>>>> Why are you attempting to do this? I don't understand why you
>>>> wouldn't submit your value back to the server over a normal
>>> transport
>>>> mechanism (either post, or via cookie) and have the receiving page
>>>> process that value in the usual way. Knowing the intended
>>> use might
>>>> help solve this problem, or propose a more easily implemented
>>>> solution.
>>>>
>>>> -----Original Message-----
>>>> From: javascript-bounces at LaTech.edu
>>>> [mailto:javascript-bounces at LaTech.edu] On Behalf Of David Lovering
>>>> Sent: Thursday, August 21, 2003 11:30 AM
>>>> To: [JavaScript List]
>>>> Subject: Re: [Javascript] JavaScript to PHP variable transfer
>>>>
>>>>
>>>> Well, maybe not. "x$" becomes an implicit executable, and not a
>>>> regular string. Not good! I'm still looking for a way to take the
>>>> output of a JavaScript directive and pipe it (or use I/O
>>> redirection,
>>>> or something
>>>> similar) in order to plant it in a regular, editable PHP
>>> variable. I've
>>>> tried various flavors of the PHP routine eval, and so far
>>> there is no
>>>> joy.
>>>>
>>>> Help! Mind growing numb!
>>>>
>>>> -- Dave Lovering
>>>>
>>>> ----- Original Message -----
>>>> From: "David T. Lovering" <dlovering at gazos.com>
>>>> To: "[JavaScript List]" <javascript at LaTech.edu>
>>>> Sent: Wednesday, August 20, 2003 3:20 PM
>>>> Subject: [Javascript] JavaScript to PHP variable transfer
>>>>
>>>>
>>>>>
>>>>> In regards to my previous posting, I tried something so
>>> simple that
>>>>> it
>>>> had
>>>> earlier eluded my consideration, and lo and behold, it worked! The
>>>> method (if done elegantly) requires two routines -- one in
>>> JavaScript,
>>>> and one in
>>>> PHP:
>>>>>
>>>>> <html>
>>>>> <head>
>>>>> <title> bogus </title>
>>>>> <script language='JavaScript'>
>>>>> <!--
>>>>> var myVal = 'happy, happy!';
>>>>>
>>>>> function getvariable(val) {
>>>>> var dummy = eval(val);
>>>>> document.write(dummy);
>>>>> }
>>>>> // -->
>>>>> </script>
>>>>> <?php
>>>>> function get_JS_var($js_var_name) {
>>>>> $x = "<script> getvariable('" . $js_var_name . "');
>>> </script>";
>>>>> return $x;
>>>>> }
>>>>> ?>
>>>>> </head>
>>>>> <body>
>>>>> <form name='myForm' action='javascript:void(null)'>
>>>>> <?php
>>>>> $abc = get_JS_var("document.forms[0].name");
>>>>> $def = get_JS_var("myVal");
>>>>> ?>
>>>>> <center><?php print "abc: " . $abc; ?></center><br>
>>>>> <center><?php print "def: " . $def; ?></center><br>
>>>>> </form>
>>>>> </body>
>>>>> </html>
>>>>>
>>>>> As you can see should you try it, the method works fine
>>> -- both for
>>>> static
>>>> variables,
>>>>> and for JavaScript objects. I imagine something similar could be
>>>>> made
>>>> to
>>>> work for
>>>>> PERL, Python, etc.
>>>>>
>>>>> -- Dave Lovering ________
Roger,
Roger Roelofs Phone 616 574-0480 x246
Datacomp Appraisal Services Fax 616 574-0486
3215 Eaglecrest Drive, NE Suite 100 email rer at datacompusa.com
Grand Rapids, MI 49525-4593 web www.datacompusa.com
More information about the Javascript
mailing list