[Javascript] JavaScript to PHP variable transfer
David Lovering
dlovering at gazos.com
Thu Aug 21 15:37:23 CDT 2003
Actually, you are quite close to the mark --
Most of the present client/server communication is done by way of the
embedded IFRAME constructs
which contain PHP scripts to update/read the database elements. They
themselves remain hidden by way of 0x0
screen dimensions, no margins, no borders, and a CSS "display: none"
declaration. Considering that POST, GET,
PUT, and cookies are all vigorously disabled, and that data still goes
back-and-forth, I'd say we're doing something
right.
The real problem is not getting PHP to talk to JavaScript (that is easy!),
but rather the reverse. Short
of using JavaScript to "invoke" a piece of PHP script as per the "src="
destination inside a frame, I don't see
any straight-forward mechanism of doing what I need. Even that requires a
fair amount of overhead, but
if it is the only way...
-- Dave Lovering
----- Original Message -----
From: "Roger Roelofs" <rer at datacompusa.com>
To: "[JavaScript List]" <javascript at LaTech.edu>
Sent: Thursday, August 21, 2003 12:09 PM
Subject: Re: [Javascript] JavaScript to PHP variable transfer
> 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
>
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript
>
More information about the Javascript
mailing list