Which is the better approach in working with Javascript?
1. Server side processing: Web server gets form input, runs it into the
Javascript module, and PHP collects the output for document prep.
2. Client side processing: Web server gets form input and passes it to PHP
which includes the Javascript written in a way to make the form input
processed on the client side and rendered (probably using DOM function
calls) on that side as well.
I posted this <news:Xn******* ***********@216 .168.3.44in an apparently
less trafficked newsgroup and the post was the TLDR kind, but it has the
background and details of why the code must be in Javascript and why PHP
must work with it somehow. It also gives the details of the server and how
it forks and communicates with processes to parse/generate output.
84  3900 
Patient Guy wrote:
Which is the better approach in working with Javascript?
1. Server side processing: Web server gets form input, runs it into the
Javascript module, and PHP collects the output for document prep.
2. Client side processing: Web server gets form input and passes it to PHP
which includes the Javascript written in a way to make the form input
processed on the client side and rendered (probably using DOM function
calls) on that side as well.
I posted this <news:Xn******* ***********@216 .168.3.44in an apparently
less trafficked newsgroup and the post was the TLDR kind, but it has the
background and details of why the code must be in Javascript and why PHP
must work with it somehow. It also gives the details of the server and how
it forks and communicates with processes to parse/generate output.
3. Try a javascript newsgroup. This one is for PHP.
Hint: javascript does NOT run on the server.
--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attgl obal.net
=============== ===
Jerry Stuckle <js*******@attg lobal.netwrote in comp.lang.php:
Patient Guy wrote:
>Which is the better approach in working with Javascript?
1. Server side processing: Web server gets form input, runs it into
the Javascript module, and PHP collects the output for document prep.
2. Client side processing: Web server gets form input and passes it
to PHP which includes the Javascript written in a way to make the
form input processed on the client side and rendered (probably using
DOM function calls) on that side as well.
I posted this <news:Xn******* ***********@216 .168.3.44in an
apparently less trafficked newsgroup and the post was the TLDR kind,
but it has the background and details of why the code must be in
Javascript and why PHP must work with it somehow. It also gives the
details of the server and how it forks and communicates with
processes to parse/generate output.
3. Try a javascript newsgroup. This one is for PHP.
So, based on your response, you are telling me that a PHP processing
implementation has no interprocess communication capability, or ability to
interface with a (Java)script interpreter.
>
Hint: javascript does NOT run on the server.
A server, or a server-associated process, can start a script host, passing
some form of input to it, and the script host does the script
interpretation, while the calling process waits for output.
However this is achieved, PHP (by design?) has no script interface, based
on your response.
Patient Guy wrote:
Jerry Stuckle <js*******@attg lobal.netwrote in comp.lang.php:
>Patient Guy wrote:
>>Which is the better approach in working with Javascript?
1. Server side processing: Web server gets form input, runs it into
the Javascript module, and PHP collects the output for document prep.
2. Client side processing: Web server gets form input and passes it
to PHP which includes the Javascript written in a way to make the
form input processed on the client side and rendered (probably using
DOM function calls) on that side as well.
I posted this <news:Xn******* ***********@216 .168.3.44in an
apparently less trafficked newsgroup and the post was the TLDR kind,
but it has the background and details of why the code must be in
Javascript and why PHP must work with it somehow. It also gives the
details of the server and how it forks and communicates with
processes to parse/generate output.
3. Try a javascript newsgroup. This one is for PHP.
So, based on your response, you are telling me that a PHP processing
implementation has no interprocess communication capability, or ability to
interface with a (Java)script interpreter.
>Hint: javascript does NOT run on the server.
A server, or a server-associated process, can start a script host, passing
some form of input to it, and the script host does the script
interpretation, while the calling process waits for output.
However this is achieved, PHP (by design?) has no script interface, based
on your response.
That is correct. Javascript runs on the client. Communications between
PHP and javascript is limited. PHP can generate javascript code, and
javascript can submit data to the server for PHP to process.
But there is no javascript interpreter on the server. That is the
browser's job.
--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attgl obal.net
=============== ===
Patient Guy wrote:
Jerry Stuckle <js*******@attg lobal.netwrote in comp.lang.php:
>Patient Guy wrote:
>>Which is the better approach in working with Javascript?
1. Server side processing: Web server gets form input, runs it into
the Javascript module, and PHP collects the output for document prep.
2. Client side processing: Web server gets form input and passes it
to PHP which includes the Javascript written in a way to make the
form input processed on the client side and rendered (probably using
DOM function calls) on that side as well.
I posted this <news:Xn******* ***********@216 .168.3.44in an
apparently less trafficked newsgroup and the post was the TLDR kind,
but it has the background and details of why the code must be in
Javascript and why PHP must work with it somehow. It also gives the
details of the server and how it forks and communicates with
processes to parse/generate output.
3. Try a javascript newsgroup. This one is for PHP.
So, based on your response, you are telling me that a PHP processing
implementation has no interprocess communication capability, or ability to
interface with a (Java)script interpreter.
>Hint: javascript does NOT run on the server.
A server, or a server-associated process, can start a script host, passing
some form of input to it, and the script host does the script
interpretation, while the calling process waits for output.
However this is achieved, PHP (by design?) has no script interface, based
on your response.
Here, try this on for size.
Javascript is run **ONLY** on the client. In any script that puts up a
page, if there is Javascript, that script is run on the client
**BEFORE** anything is sent to the server.
If a php script is invoked, either via a page post or from the href of
an anchor or from an httpRequest, it is invoked on the **SERVER**. It
gathers input from the calling form in one of two ways. It can get that
from $_GET or from $_POST or both, depending upon the method of the
calling form.
PHP can then send HTML back to the client for display. PHP does **NOT**
run Javascript.
Is that clear enough for you?
On Tue, 08 Jul 2008 17:27:08 -0400, Jerry Stuckle wrote:
Patient Guy wrote:
>Jerry Stuckle <js*******@attg lobal.netwrote in comp.lang.php:
>>Patient Guy wrote:
Which is the better approach in working with Javascript?
1. Server side processing: Web server gets form input, runs it into
the Javascript module, and PHP collects the output for document prep.
2. Client side processing: Web server gets form input and passes it
to PHP which includes the Javascript written in a way to make the
form input processed on the client side and rendered (probably using
DOM function calls) on that side as well.
I posted this <news:Xn******* ***********@216 .168.3.44in an
apparently less trafficked newsgroup and the post was the TLDR kind,
but it has the background and details of why the code must be in
Javascript and why PHP must work with it somehow. It also gives the
details of the server and how it forks and communicates with
processes to parse/generate output.
3. Try a javascript newsgroup. This one is for PHP.
So, based on your response, you are telling me that a PHP processing
implementati on has no interprocess communication capability, or ability
to interface with a (Java)script interpreter.
>>Hint: javascript does NOT run on the server.
A server, or a server-associated process, can start a script host,
passing some form of input to it, and the script host does the script
interpretation , while the calling process waits for output.
However this is achieved, PHP (by design?) has no script interface,
based on your response.
That is correct. Javascript runs on the client. Communications between
PHP and javascript is limited. PHP can generate javascript code, and
javascript can submit data to the server for PHP to process.
But there is no javascript interpreter on the server. That is the
browser's job.
Except that you can run server-side javascript... though I don't know why
you would want to.
--
"Remain calm, we're here to protect you!"
..oO(sheldonlg)
>Patient Guy wrote:
>>
So, based on your response, you are telling me that a PHP processing
implementati on has no interprocess communication capability, or ability to
interface with a (Java)script interpreter.
>>Hint: javascript does NOT run on the server.
A server, or a server-associated process, can start a script host, passing
some form of input to it, and the script host does the script
interpretation , while the calling process waits for output.
However this is achieved, PHP (by design?) has no script interface, based
on your response.
Here, try this on for size.
Javascript is run **ONLY** on the client.
Wrong. JavaScript is just a language and can run everywhere if an
interpreter is available. Even PHP can be run in a client's browser if
you have the required plugin (at least for IE such a plugin exists!)
>In any script that puts up a
page, if there is Javascript, that script is run on the client
**BEFORE** anything is sent to the server.
Correct, but now you're talking about a particular implementation of a
JS engine and the most common use of JS. But there are also various JS
engines available that run on a server. http://en.wikipedia.org/wiki/Server-side_JavaScript
>If a php script is invoked, either via a page post or from the href of
an anchor or from an httpRequest, it is invoked on the **SERVER**. It
gathers input from the calling form in one of two ways. It can get that
from $_GET or from $_POST or both, depending upon the method of the
calling form.
PHP can then send HTML back to the client for display. PHP does **NOT**
run Javascript.
If there's a JS engine available, then of course PHP can invoke a Java-
Script like it can call a Perl script, Python, Java ... whatever. A
programming language is never restricted to just a single environment.
Micha
.oO(sheldonlg)
>
>Patient Guy wrote:
>>>
So, based on your response, you are telling me that a PHP processing
implementatio n has no interprocess communication capability, or
ability to interface with a (Java)script interpreter.
Hint: javascript does NOT run on the server.
A server, or a server-associated process, can start a script host,
passing some form of input to it, and the script host does the
script interpretation, while the calling process waits for output.
However this is achieved, PHP (by design?) has no script interface,
based on your response.
Here, try this on for size.
Javascript is run **ONLY** on the client.
Wrong. JavaScript is just a language and can run everywhere if an
interpreter is available. Even PHP can be run in a client's browser if
you have the required plugin (at least for IE such a plugin exists!)
>In any script that puts up a
page, if there is Javascript, that script is run on the client
**BEFORE** anything is sent to the server.
Correct, but now you're talking about a particular implementation of a
JS engine and the most common use of JS. But there are also various JS
engines available that run on a server.
http://en.wikipedia.org/wiki/Server-side_JavaScript
>If a php script is invoked, either via a page post or from the href
of an anchor or from an httpRequest, it is invoked on the
**SERVER**. It gathers input from the calling form in one of two
ways. It can get that from $_GET or from $_POST or both, depending
upon the method of the calling form.
PHP can then send HTML back to the client for display. PHP does
**NOT** run Javascript.
If there's a JS engine available, then of course PHP can invoke a
Java- Script like it can call a Perl script, Python, Java ...
whatever. A programming language is never restricted to just a single
environment.
Micha
I mean no offense here, but I think the original answers based on the
level of the OP were probably good ones; run it client side because the
server likely doesn't provide it?. Perhaps the missed point was simply
that servers would have to be checked to see if they would serve js,
same as checking to see if and what version of PHP they provide, if they
provide it, which almost all do AFAIK. So js is normally intended to be
run on the client side, not the server side.
Or am I all wet? I'm not sure I see any value to running js for the
client on the server side. Seems like js could put quite a load on a
server if many people used it that way, since it's so prevalent in
coding these days.
I got curious so I checked my own servers and they do not provide any
js capability that I could find. I didn't ask support though; I'm
trying to avoid js, but it can be pretty handy for some things, I know.
Ivan Marsh wrote:
On Tue, 08 Jul 2008 17:27:08 -0400, Jerry Stuckle wrote:
>Patient Guy wrote:
>>Jerry Stuckle <js*******@attg lobal.netwrote in comp.lang.php:
Patient Guy wrote:
Which is the better approach in working with Javascript?
>
1. Server side processing: Web server gets form input, runs it into
the Javascript module, and PHP collects the output for document prep.
>
2. Client side processing: Web server gets form input and passes it
to PHP which includes the Javascript written in a way to make the
form input processed on the client side and rendered (probably using
DOM function calls) on that side as well.
>
I posted this <news:Xn******* ***********@216 .168.3.44in an
apparentl y less trafficked newsgroup and the post was the TLDR kind,
but it has the background and details of why the code must be in
Javascrip t and why PHP must work with it somehow. It also gives the
details of the server and how it forks and communicates with
processes to parse/generate output.
>
3. Try a javascript newsgroup. This one is for PHP.
So, based on your response, you are telling me that a PHP processing
implementatio n has no interprocess communication capability, or ability
to interface with a (Java)script interpreter.
Hint: javascript does NOT run on the server.
A server, or a server-associated process, can start a script host,
passing some form of input to it, and the script host does the script
interpretatio n, while the calling process waits for output.
However this is achieved, PHP (by design?) has no script interface,
based on your response.
That is correct. Javascript runs on the client. Communications between
PHP and javascript is limited. PHP can generate javascript code, and
javascript can submit data to the server for PHP to process.
But there is no javascript interpreter on the server. That is the
browser's job.
Except that you can run server-side javascript... though I don't know why
you would want to.
What interpreters are available for javascript on the server, and what
hosts have it installed?
It is not part of the package of any web server.
--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attgl obal.net
=============== ===
"Twayne" <no****@devnull .spamcop.netwro te in comp.lang.php:
>.oO(sheldonl g)
>>Patient Guy wrote:
So, based on your response, you are telling me that a PHP processing
implementati on has no interprocess communication capability, or
ability to interface with a (Java)script interpreter.
Hint: javascript does NOT run on the server.
A server, or a server-associated process, can start a script host,
passing some form of input to it, and the script host does the
script interpretation, while the calling process waits for output.
However this is achieved, PHP (by design?) has no script interface,
based on your response.
Here, try this on for size.
Javascript is run **ONLY** on the client.
Wrong. JavaScript is just a language and can run everywhere if an
interpreter is available. Even PHP can be run in a client's browser if
you have the required plugin (at least for IE such a plugin exists!)
>>In any script that puts up a
page, if there is Javascript, that script is run on the client
**BEFORE** anything is sent to the server.
Correct, but now you're talking about a particular implementation of a
JS engine and the most common use of JS. But there are also various JS
engines available that run on a server.
http://en.wikipedia.org/wiki/Server-side_JavaScript
>>If a php script is invoked, either via a page post or from the href
of an anchor or from an httpRequest, it is invoked on the
**SERVER**. It gathers input from the calling form in one of two
ways. It can get that from $_GET or from $_POST or both, depending
upon the method of the calling form.
PHP can then send HTML back to the client for display. PHP does
**NOT** run Javascript.
If there's a JS engine available, then of course PHP can invoke a
Java- Script like it can call a Perl script, Python, Java ...
whatever. A programming language is never restricted to just a single
environment.
Micha
I mean no offense here, but I think the original answers based on the
level of the OP were probably good ones; run it client side because the
server likely doesn't provide it?. Perhaps the missed point was simply
that servers would have to be checked to see if they would serve js,
same as checking to see if and what version of PHP they provide, if they
provide it, which almost all do AFAIK. So js is normally intended to be
run on the client side, not the server side.
Or am I all wet? I'm not sure I see any value to running js for the
client on the server side. Seems like js could put quite a load on a
server if many people used it that way, since it's so prevalent in
coding these days.
I got curious so I checked my own servers and they do not provide any
js capability that I could find. I didn't ask support though; I'm
trying to avoid js, but it can be pretty handy for some things, I know.
There are several reasons for running it on the server side, which were
all given in the post with message ID
<news:Xn******* ***********@216 .168.3.44>
cited in the original post.
The reason all starts with the need to convert a pseudo-math plaintext
notation into MathML. The parser and generator was originally written in
Javascript, and that was ported to PHP so that string input from a form
textarea control could apparently seamlessly be translated to MathML all
within PHP.
But I want to tweak the code of the parser and generator, and I am quite
familiar with Javascript, and much less so with PHP. It would be no issue
at all if I can work easily with PHP at this very moment, for I would edit
the PHP code rather than the Javascript code.
So given that I would rather make use of the original Javascript code---
and can---then the two ways of making use of the Javascript code was
either to have PHP set up the delivered document to client with the input
string bundled with the Javascript code and have it all done on the client
side, or to run something like wscript or cscript from the server, which
is the host interpreter for J(ava)script, and then run the output to PHP
for deliver (thus, all done on the server side).
Surely both approaches are possible, but which of the two is more
sensible? This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: lawrence |
last post by:
How is it possible that the question "How do I detect which browser
the user has" is missing from this FAQ:
http://www.faqts.com/knowledge_base/index.phtml/fid/125
and is only here on this with a link to old information that suggests
use of "navigator":
http://developer.irt.org/script/43.htm
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it. ...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
