[Javascript] JavaScript to PHP variable transfer
David T. Lovering
dlovering at gazos.com
Thu Aug 21 15:09:01 CDT 2003
Cumbersome to the max!
I think you may be right -- but convincing the customer to overhaul their
web services to focus on XML and SOAP might be a tough order.
I was hoping for a "theoretically unsatisfying, but useful" band-aid I could
slap on the sucking chest-wound until the patient was out of triage.
Like, for example --
where "var myVal = 17"; (previously set in JavaScript), and
Given the construct (in PHP): $x = "<script> document.write( myVal ); </script>";
[Where everything between the "<script> and </script> is vanilla JavaScript]...
What kind of transmogrification is necessary to map $x into the two-byte string "17"
such that it remains readable in the PHP domain?
That would keep me happy -- for now!
-- Dave
Mike Dougherty wrote:
>
> Obviously the scope of this problem goes beyond a 'simple' solution
>
> The initial delivery of this forms suite (with all it's dhtml, form
> validation, and state maintenance) must be pretty cumbersome too, right?
>
> Have you looked at using XML with SOAP? I don't know much about it, but
> it sounded to me like "web services" were designed to facilitate exactly
> this kind of communication with the server via http.
>
> I know that's not terribly helpful, but I haven't had a need to learn
> more about it.
>
> -----Original Message-----
> From: javascript-bounces at LaTech.edu
> [mailto:javascript-bounces at LaTech.edu] On Behalf Of David Lovering
> Sent: Thursday, August 21, 2003 12: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
> > > _______________________________________________
> > > Javascript mailing list
> > > Javascript at LaTech.edu
> > > https://lists.LaTech.edu/mailman/listinfo/javascript
> > >
> > >
> >
> >
> > _______________________________________________
> > Javascript mailing list
> > Javascript at LaTech.edu
> > https://lists.LaTech.edu/mailman/listinfo/javascript
> >
> >
> > _______________________________________________
> > Javascript mailing list
> > Javascript at LaTech.edu
> > https://lists.LaTech.edu/mailman/listinfo/javascript
> >
>
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript
>
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript
More information about the Javascript
mailing list