By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,588 Members | 1,920 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,588 IT Pros & Developers. It's quick & easy.

Which Is The Better Approach To Working With Javascript?

P: n/a

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.
Jul 8 '08 #1
Share this Question
Share on Google+
84 Replies


P: n/a
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*******@attglobal.net
==================

Jul 8 '08 #2

P: n/a
Jerry Stuckle <js*******@attglobal.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.
Jul 8 '08 #3

P: n/a
Patient Guy wrote:
Jerry Stuckle <js*******@attglobal.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*******@attglobal.net
==================

Jul 8 '08 #4

P: n/a
Patient Guy wrote:
Jerry Stuckle <js*******@attglobal.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?
Jul 8 '08 #5

P: n/a
On Tue, 08 Jul 2008 17:27:08 -0400, Jerry Stuckle wrote:
Patient Guy wrote:
>Jerry Stuckle <js*******@attglobal.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.
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!"

Jul 8 '08 #6

P: n/a
..oO(sheldonlg)
>Patient Guy wrote:
>>
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.
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
Jul 8 '08 #7

P: n/a
.oO(sheldonlg)
>
>Patient Guy wrote:
>>>
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.

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.

Jul 9 '08 #8

P: n/a
Ivan Marsh wrote:
On Tue, 08 Jul 2008 17:27:08 -0400, Jerry Stuckle wrote:
>Patient Guy wrote:
>>Jerry Stuckle <js*******@attglobal.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.

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*******@attglobal.net
==================

Jul 9 '08 #9

P: n/a
"Twayne" <no****@devnull.spamcop.netwrote in comp.lang.php:
>.oO(sheldonlg)
>>Patient Guy wrote:

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.

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?
Jul 9 '08 #10

P: n/a
..oO(Twayne)
>I mean no offense here, but I think the original answers based on the
level of the OP were probably good ones
We don't know much about the OP and its level. But his posting and the
one he referred to seem to be worded quite thoroughly, so he might know
what he's talking about.
>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,
Sure, but a lot of people run their own servers or use hosts which might
install additional software if you ask them nicely. Just because such a
setup is quite unusual doesn't mean it's impossible or pointless.
>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.
Nothing wrong with that. As said - it's just another programming
language. Whether you do your server-side scripts in PHP, Perl, Python,
JS, Whitespace, Brainfuck or use executable binaries written with C/C++,
Delphi, whatever doesn't really matter. They all serve their purpose.
>Seems like js could put quite a load on a
server
Not more than any other interpreter. Why should a JS interpreter cause
more load than the PHP interpreter for example? They do exactly the same
work, it's just another syntax and some different semantics.
>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.
Because it's not very popular on servers. But if one prefers that
language to also do server-side stuff - heck, why not.

Micha
Jul 9 '08 #11

P: n/a
Michael Fesser <ne*****@gmx.dewrites:
.oO(Twayne)
>>I got curious so I checked my own servers and they do not provide any
js capability that I could find.

Because it's not very popular on servers. But if one prefers that
language to also do server-side stuff - heck, why not.
It's actually been done. Netscape web servers had a JavaScript
module that parsed some <scriptelements before sending the
page. There was an attribute that indicated which ones were to be
parsed on the server, but I forget what it was.

That said, I haven't seen a Netscape server in use for at least a
decade, and I have no idea who ended up with the rights for their
server products.

sherm--

--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
Jul 9 '08 #12

P: n/a
Jerry Stuckle <js*******@attglobal.netwrites:
What interpreters are available for javascript on the server
There's mod_wxjs for Apache:

<http://www.wxjavascript.net/mod_wxjs/index.html>

I've never actually used it though, so I can't recommend either for or
against it, simply point out its existence. I keep such things in a
folder of "might be handy some day" bookmarks. :-)
and what hosts have it installed?
I suspect none. You'd probably have to lease a dedicated server, so
that you could customize your Apache install with your own modules.

sherm--

--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
Jul 9 '08 #13

P: n/a
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.
Do not assume the client has JavaScript enabled and especially do your
validations on the server. You can do validations on the client as well,
but mainly to provide faster/better feedback to the user.

Best regards,
--
Willem Bogaerts

Application smith
Kratz B.V.
http://www.kratz.nl/
Jul 9 '08 #14

P: n/a
Jerry Stuckle wrote:
Ivan Marsh wrote:
>On Tue, 08 Jul 2008 17:27:08 -0400, Jerry Stuckle wrote:
>>Patient Guy wrote:
Jerry Stuckle <js*******@attglobal.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.

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.
http://en.wikipedia.org/wiki/Server-side_JavaScript
Jul 9 '08 #15

P: n/a
bill wrote:
Jerry Stuckle wrote:
>Ivan Marsh wrote:
>>On Tue, 08 Jul 2008 17:27:08 -0400, Jerry Stuckle wrote:

Patient Guy wrote:
Jerry Stuckle <js*******@attglobal.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.

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.

http://en.wikipedia.org/wiki/Server-side_JavaScript
And how about the second part of the question - what hosts have such
packages installed?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Jul 9 '08 #16

P: n/a
Patient Guy wrote:
Jerry Stuckle <js*******@attglobal.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.
Java SCRIPT (as opposed to java) runs in the browser exclusively. It
makes local decsison without reference to the server. This is great for
speed..you can change screen appearance fast and dynamically, producing
e.g. drop down menus and the like) at the expense of having to download
all the code TO the browser and more data than you probably need.

PHP is EXCLUSIVELY server side, and is used to generate context
sensitive pages, often coupled to a database engine. It takes as much
processing and decsion making out of the brwsers hands as possible,
cincentraying te cde where its more easily maintainable - on teh sever
itself.

Halfway huse s do exist - Ajax - where partial page reloads are done
dynamically, using I think javascipt on e browser and PHP server side.

>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.
Oh, its perfectly possible to pass commands from PHP to some other
engine: teh classic example is the Mysql server, which is interfaced to
PHP with a library ..but no one would ever attempt to execuste java
SCRIPT on the server, because its a bloody awful language, and is only
by and large written for broswers.

Once you are server side you can in principle write in any language you
like, PHP being just a common popular one, but shell script python, C,
C++. PERL Java and so on are perfectly possible.
>
Jul 9 '08 #17

P: n/a
On Tue, 08 Jul 2008 20:41:34 -0400, Jerry Stuckle wrote:
Ivan Marsh wrote:
>On Tue, 08 Jul 2008 17:27:08 -0400, Jerry Stuckle wrote:
>>Patient Guy wrote:
Jerry Stuckle <js*******@attglobal.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.

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.
http://en.wikipedia.org/wiki/Server-side_JavaScript

I've played with some of it back when I was looking for a single language
solution to client and server side scripting. It was much less trouble to
learn to use PHP and Javascript.

--
"Remain calm, we're here to protect you!"

Jul 9 '08 #18

P: n/a
On Wed, 09 Jul 2008 07:59:50 -0400, Jerry Stuckle wrote:
bill wrote:
>Jerry Stuckle wrote:
>>Ivan Marsh wrote:
On Tue, 08 Jul 2008 17:27:08 -0400, Jerry Stuckle wrote:

Patient Guy wrote:
>Jerry Stuckle <js*******@attglobal.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.

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.

http://en.wikipedia.org/wiki/Server-side_JavaScript

And how about the second part of the question - what hosts have such
packages installed?
I'd expect you'd have to be running your own server to use any of it.

--
"Remain calm, we're here to protect you!"

Jul 9 '08 #19

P: n/a

"Twayne" <no****@devnull.spamcop.netwrote in message
news:5q3dk.403$P11.290@trndny06...

<snip>
>Nothing wrong with that. As said - it's just another programming
language. Whether you do your server-side scripts in PHP, Perl,
Python, JS, Whitespace, Brainfuck or use executable binaries written
with C/C++, Delphi, whatever doesn't really matter. They all serve
their purpose.

lol!
why 'LOL'?

>>Seems like js could put quite a load on a
server

Not more than any other interpreter. Why should a JS interpreter cause
more load than the PHP interpreter for example? They do exactly the
same work, it's just another syntax and some different semantics.

Maybe my assumption is wrong, but IME my js is a lot more code bytewise
than the PHP code I use the server for and where reasonable users tend to
minimze server use when it's not advantageous, it seems like running js
there would be slower, more machine intensive and more voluminous code to
run.
interesting. maybe you could provide a sample of js code that is translated
to php so that your argument has a bit more meat. in most source code, the
more verbose the code, the less experienced the author. as it is, having
written my share of source in each i see no way to agree with that
statement.
js being what it is, it seems it could pretty easily put a load on a
server if very many visitors and/or other sites ran it there.
I could easily be wrong; I have no actual experience in that area other
than the little twerps I've run on my local server so I'm not presenting
an arguement as much as I am justifying why I said what I did.
you can't justify what you've claimed based on mere inference or belief,
though i understand the assumption and what it's based on.
>>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.

Because it's not very popular on servers. But if one prefers that
language to also do server-side stuff - heck, why not.

I guess. I might think seriously about it at least but I'm too ignorant
of the nuances to be sure right now. Nuances of the server side use, I
mean.
i would think from a business stand-point that if server-sided js was as
capable and robust as php or asp that using one language in the company's
web development would be a huge, pragmatic plus. imo, ss-js simply isn't
there yet nor is there a developer-based demand for it to be in the near
future.

cheers
Jul 9 '08 #20

P: n/a

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g5**********@registered.motzarella.org...
bill wrote:
>Jerry Stuckle wrote:
>>Ivan Marsh wrote:
On Tue, 08 Jul 2008 17:27:08 -0400, Jerry Stuckle wrote:

Patient Guy wrote:
>Jerry Stuckle <js*******@attglobal.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.

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.

http://en.wikipedia.org/wiki/Server-side_JavaScript

And how about the second part of the question - what hosts have such
packages installed?
i like how you can speak for all web server installations, jerry. further,
when proven wrong about js being client-side only, you just change pace and
say, 'well, no one has that on their server!'. you simply tried to speak
with authority on a topic you obviously know nothing about. why not just say
you were wrong and then move on?
Jul 9 '08 #21

P: n/a
Patient Guy wrote:
"Twayne" <no****@devnull.spamcop.netwrote in comp.lang.php:
>>.oO(sheldonlg)

Patient Guy wrote:
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.
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.
From the Wikipedia reference it appears that only JAXER has any DOM
capabilities, and whether it can deal with MathML you would need to
investigate. I'm thinking not. Most, if not all server side JS
implementations are not concerned with doing client side type stuff,
it's a very different animal than client side JS. Remember that the JS
you are used to using only runs through a browser, that there is no
standalone client side JS.

Now, it seems to me that rather that go through all this to possibly
get nowhere that learning a little more PHP would be easier. It looks a
lot like javascript to me to the point that when I embed javascript in
my php it's hard for me to tell which is which!

Jeff
>
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?
Jul 9 '08 #22

P: n/a
Message-ID: <X6******************************@earthlink.comfro m Jeff
contained the following:
Now, it seems to me that rather that go through all this to possibly
get nowhere that learning a little more PHP would be easier. It looks a
lot like javascript to me to the point that when I embed javascript in
my php it's hard for me to tell which is which!
But easier. I find de-bugging JS a real pain.

--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011
Jul 9 '08 #23

P: n/a
In article <Ll***************@newsfe06.lga>,
"Barry" <no****@example.comwrote:
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g5**********@registered.motzarella.org...
bill wrote:
Jerry Stuckle wrote:
[snip]
>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.
http://en.wikipedia.org/wiki/Server-side_JavaScript
And how about the second part of the question - what hosts have such
packages installed?

i like how you can speak for all web server installations, jerry. further,
when proven wrong about js being client-side only, you just change pace and
say, 'well, no one has that on their server!'. you simply tried to speak
with authority on a topic you obviously know nothing about. why not just say
you were wrong and then move on?
Because he's not wrong in any material sense.
Jul 9 '08 #24

P: n/a
On Wed, 09 Jul 2008 16:15:15 +0100, Geoff Berrow wrote:
Message-ID: <X6******************************@earthlink.comfro m Jeff
contained the following:
> Now, it seems to me that rather that go through all this to possibly
get nowhere that learning a little more PHP would be easier. It looks a
lot like javascript to me to the point that when I embed javascript in
my php it's hard for me to tell which is which!

But easier. I find de-bugging JS a real pain.
It can be a bit like chasing a ghost at times.

--
"Remain calm, we're here to protect you!"

Jul 9 '08 #25

P: n/a
Willem Bogaerts <w.********@kratz.nlwrote 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.

Do not assume the client has JavaScript enabled and especially do your
validations on the server. You can do validations on the client as
well, but mainly to provide faster/better feedback to the user.

Best regards,
Thanks for input.

The basic assumption here has been that the Javascript I intend to use has
been for form validation. That is absolutely not true at all.

This developer decided to write a translator tool, one that converts a
pseudo-math notation in ASCII plaintext to MathML; I need to check the
code to see if the MathML is output as a long string or whether it is
output as XML/MathML-specific DOM objects. He wrote it in Javascript
probably because he ran it all on his browser (client-side) for his own
purposes rather than through a server. Someone else decided to take the
input string on the server side and process on that side, porting the
whole thing to PHP.

At any rate, I will probably just set up a web page that runs it all on
the client side for my own purposes rather than set something up on a
server for others who might have otherwise wanted the changes I made to
the code. At least for the time being.

The general consensus in this group---no surprise---is that I should work
with the PHP ported code (instead of the Javascript/ECMAscript) if I want
to make changes/improvements in server side-based Text->MathML
translations, since anyone like myself who has more than beginner
experience in code development should already know core (typically useful)
PHP or should quickly acquire a facility for it. I will accept this
opinion and move my "learn basic PHP" to-do item to the top of the list.
Jul 9 '08 #26

P: n/a
Rob
On Jul 9, 9:18*am, Willem Bogaerts <w.bogae...@kratz.nlwrote:
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.

Do not assume the client has JavaScript enabled and especially do your
validations on the server. You can do validations on the client as well,
but mainly to provide faster/better feedback to the user.

Best regards,
--
Willem Bogaerts

Application smith
Kratz B.V.http://www.kratz.nl/
Willem's response is correct. You cannot rely on JavaScript being
enabled (or worse, failing to process correctly) on the users browser.
Therefore, you must also validate all input on the server.

Where JavaScript can be used is to drive dynamic content based on the
users input, either pre-loaded and hidden or using AJAX. And to speed
up the validation process, by not having to go off to the server where
something can be easily checked on the browser first.

But, as I said, don't rely on the browser validation.

Rob.
Jul 9 '08 #27

P: n/a

"Tim Streater" <ti**********@dante.org.ukwrote in message
news:ti********************************@news.indiv idual.net...
In article <Ll***************@newsfe06.lga>,
"Barry" <no****@example.comwrote:
>"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g5**********@registered.motzarella.org...
bill wrote:
Jerry Stuckle wrote:

[snip]
>>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.
http://en.wikipedia.org/wiki/Server-side_JavaScript
And how about the second part of the question - what hosts have such
packages installed?

i like how you can speak for all web server installations, jerry.
further,
when proven wrong about js being client-side only, you just change pace
and
say, 'well, no one has that on their server!'. you simply tried to speak
with authority on a topic you obviously know nothing about. why not just
say
you were wrong and then move on?

Because he's not wrong in any material sense.
the 'material sense' would be that he can't know what is installed on every
web server out there. obviously, materially, if development is being done on
products such as LiveWire and other server-side javascripting engines then
there are web servers with such animals installed.

in every sense, he is wrong...and that doesn't even address that servers who
don't have this or that package installed usually do so on request (payment
consideration aside). either way, his arrogance is only upstaged, and
highlighted, by his lack of correctness. :)

cheers.
Jul 9 '08 #28

P: n/a
In article <CG************@newsfe07.lga>, "Barry" <no****@example.com>
wrote:
"Tim Streater" <ti**********@dante.org.ukwrote in message
news:ti********************************@news.indiv idual.net...
In article <Ll***************@newsfe06.lga>,
"Barry" <no****@example.comwrote:
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g5**********@registered.motzarella.org...
bill wrote:
Jerry Stuckle wrote:
[snip]
>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.
http://en.wikipedia.org/wiki/Server-side_JavaScript


And how about the second part of the question - what hosts have such
packages installed?

i like how you can speak for all web server installations, jerry.
further,
when proven wrong about js being client-side only, you just change pace
and
say, 'well, no one has that on their server!'. you simply tried to speak
with authority on a topic you obviously know nothing about. why not just
say
you were wrong and then move on?
Because he's not wrong in any material sense.

the 'material sense' would be that he can't know what is installed on every
web server out there. obviously, materially, if development is being done on
products such as LiveWire and other server-side javascripting engines then
there are web servers with such animals installed.
Of course not, bozo. I hadn't heard about this server side stuff either,
but as it never gets mentioned on comp.lang.javascript it's obviously
close to irrelevant.

My JavaScript book mentions a couple of times in its intro that "...
JavaScript can even be run on a server ..." and then goes on to take
1500 pages to explain about client-side.

Hence my use of the word "material".
Jul 9 '08 #29

P: n/a
..oO(The Natural Philosopher)
>Patient Guy wrote:
>>
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.

Java SCRIPT (as opposed to java) runs in the browser exclusively.
Wrong. Various engines for running JS outside a browser context exist,
as already mentioned in the thread. JS is already incorporated in a
number of applications and document types that have nothing to do with
HTML or a browser.

http://en.wikipedia.org/wiki/Javascr...side_web_pages
>It
makes local decsison without reference to the server. This is great for
speed..you can change screen appearance fast and dynamically, producing
e.g. drop down menus and the like) at the expense of having to download
all the code TO the browser and more data than you probably need.

PHP is EXCLUSIVELY server side
PHP can also run in a browser (a proof-of-concept plugin for IE exists),
on the local machine, as a shell script, with a GUI ... It could even be
used like JS or Python for scripting in standalone applications.
>Halfway huse s do exist - Ajax - where partial page reloads are done
dynamically, using I think javascipt on e browser and PHP server side.
AJAX has nothing to do with either of them, at least not by definition.
It's just an overestimated hype, but in fact it's nothing new. It's just
a slightly different way for sending HTTP requests, but doesn't say
anything about the language(s) to use or the type of data that's sent.

A plugin or even an external application might be able to access the
browser's XHR object directly without any JavaScript, and the data
doesn't have to be in XML format. So what's left from "AJAX" in
practice? Just the "A" for asynchronous.
>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.

Oh, its perfectly possible to pass commands from PHP to some other
engine: teh classic example is the Mysql server, which is interfaced to
PHP with a library ..but no one would ever attempt to execuste java
SCRIPT on the server
There's no reason to not do it. And in fact some do.
>because its a bloody awful language
Depends. It's a totally different way of thinking and programming. You
simply can't compare it with a classical OOP language. But once you've
understood it, you might find prototype-based programming quite useful
in certain situations.
>and is only
by and large written for broswers.
No language is written just for a single environment.
>Once you are server side you can in principle write in any language you
like, PHP being just a common popular one, but shell script python, C,
C++. PERL Java and so on are perfectly possible.
Exactly. You can use _every_ programming language you like. And JS
undoubtly _is_ a programming language.

Micha
Jul 9 '08 #30

P: n/a

"Tim Streater" <ti**********@dante.org.ukwrote in message
news:ti********************************@news.indiv idual.net...
In article <CG************@newsfe07.lga>, "Barry" <no****@example.com>
wrote:
>"Tim Streater" <ti**********@dante.org.ukwrote in message
news:ti********************************@news.indi vidual.net...
In article <Ll***************@newsfe06.lga>,
"Barry" <no****@example.comwrote:

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g5**********@registered.motzarella.org...
bill wrote:
Jerry Stuckle wrote:

[snip]

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.
http://en.wikipedia.org/wiki/Server-side_JavaScript
And how about the second part of the question - what hosts have such
packages installed?

i like how you can speak for all web server installations, jerry.
further,
when proven wrong about js being client-side only, you just change
pace
and
say, 'well, no one has that on their server!'. you simply tried to
speak
with authority on a topic you obviously know nothing about. why not
just
say
you were wrong and then move on?

Because he's not wrong in any material sense.

the 'material sense' would be that he can't know what is installed on
every
web server out there. obviously, materially, if development is being done
on
products such as LiveWire and other server-side javascripting engines
then
there are web servers with such animals installed.

Of course not, bozo. I hadn't heard about this server side stuff either,
but as it never gets mentioned on comp.lang.javascript it's obviously
close to irrelevant.

My JavaScript book mentions a couple of times in its intro that "...
JavaScript can even be run on a server ..." and then goes on to take
1500 pages to explain about client-side.

Hence my use of the word "material".
'material' taken as real, not as *relevant*. as it is, server-side
javascript 'stuff' seems to have been very *relevant* to the OP. jerry
telling the OP that javascript is client-side *only* is wrong. skirting the
error and saying *no one* has a web server set up to do ss-js is likewise
wrong. the 'material', factual matter is that ss-js exists. the *relevancy*
should be given to the OP and not you nor jerry...the OP finds it very
'material' in either case!

btw, my original point was that jerry never has picked up a js book or he
too would have read "...javascript can even be run on a server ...", yet
jerry speaks as if he had.
Jul 9 '08 #31

P: n/a
Ivan Marsh wrote:
On Wed, 09 Jul 2008 07:59:50 -0400, Jerry Stuckle wrote:
>bill wrote:
>>Jerry Stuckle wrote:
Ivan Marsh wrote:
On Tue, 08 Jul 2008 17:27:08 -0400, Jerry Stuckle wrote:
>
>Patient Guy wrote:
>>Jerry Stuckle <js*******@attglobal.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.
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.
http://en.wikipedia.org/wiki/Server-side_JavaScript
And how about the second part of the question - what hosts have such
packages installed?

I'd expect you'd have to be running your own server to use any of it.
Why is that? Servers are expensive for a relatively small site.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Jul 9 '08 #32

P: n/a
Barry wrote:
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g5**********@registered.motzarella.org...
>bill wrote:
>>Jerry Stuckle wrote:
Ivan Marsh wrote:
On Tue, 08 Jul 2008 17:27:08 -0400, Jerry Stuckle wrote:
>
>Patient Guy wrote:
>>Jerry Stuckle <js*******@attglobal.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.
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.

http://en.wikipedia.org/wiki/Server-side_JavaScript
And how about the second part of the question - what hosts have such
packages installed?

i like how you can speak for all web server installations, jerry. further,
when proven wrong about js being client-side only, you just change pace and
say, 'well, no one has that on their server!'. you simply tried to speak
with authority on a topic you obviously know nothing about. why not just say
you were wrong and then move on?
Yes, I was wrong about not being able to do it server side. However, of
course there are great limitations to doing it there.

And I didn't say no one has that on their server. I asked which hosts
have it installed.

Please answer the question.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Jul 9 '08 #33

P: n/a
On Wed, 09 Jul 2008 12:36:39 -0500, Barry wrote:

"Tim Streater" <ti**********@dante.org.ukwrote in message
news:ti********************************@news.indiv idual.net...
>In article <CG************@newsfe07.lga>, "Barry" <no****@example.com>
wrote:
>>"Tim Streater" <ti**********@dante.org.ukwrote in message
news:ti********************************@news.ind ividual.net...
In article <Ll***************@newsfe06.lga>, "Barry"
<no****@example.comwrote:

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g5**********@registered.motzarella.org...
bill wrote:
Jerry Stuckle wrote:

[snip]

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.
http://en.wikipedia.org/wiki/Server-side_JavaScript
And how about the second part of the question - what hosts have
such packages installed?

i like how you can speak for all web server installations, jerry.
further,
when proven wrong about js being client-side only, you just change
pace
and
say, 'well, no one has that on their server!'. you simply tried to
speak
with authority on a topic you obviously know nothing about. why not
just
say
you were wrong and then move on?

Because he's not wrong in any material sense.

the 'material sense' would be that he can't know what is installed on
every
web server out there. obviously, materially, if development is being
done on
products such as LiveWire and other server-side javascripting engines
then
there are web servers with such animals installed.

Of course not, bozo. I hadn't heard about this server side stuff
either, but as it never gets mentioned on comp.lang.javascript it's
obviously close to irrelevant.

My JavaScript book mentions a couple of times in its intro that "...
JavaScript can even be run on a server ..." and then goes on to take
1500 pages to explain about client-side.

Hence my use of the word "material".

skirting the error and saying *no one* has a web server set up to do
ss-js is likewise wrong.
Except that Jerry didn't say that.

Assuming he was unaware that javascript can be run server-side, asking
what hosts provide it is a perfectly reasonable question.

--
"Remain calm, we're here to protect you!"

Jul 9 '08 #34

P: n/a
Patient Guy wrote:
Willem Bogaerts <w.********@kratz.nlwrote 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.
Do not assume the client has JavaScript enabled and especially do your
validations on the server. You can do validations on the client as
well, but mainly to provide faster/better feedback to the user.

Best regards,

Thanks for input.

The basic assumption here has been that the Javascript I intend to use has
been for form validation. That is absolutely not true at all.

This developer decided to write a translator tool, one that converts a
pseudo-math notation in ASCII plaintext to MathML; I need to check the
code to see if the MathML is output as a long string or whether it is
output as XML/MathML-specific DOM objects. He wrote it in Javascript
probably because he ran it all on his browser (client-side) for his own
purposes rather than through a server. Someone else decided to take the
input string on the server side and process on that side, porting the
whole thing to PHP.

At any rate, I will probably just set up a web page that runs it all on
the client side for my own purposes rather than set something up on a
server for others who might have otherwise wanted the changes I made to
the code. At least for the time being.

The general consensus in this group---no surprise---is that I should work
with the PHP ported code (instead of the Javascript/ECMAscript) if I want
to make changes/improvements in server side-based Text->MathML
translations, since anyone like myself who has more than beginner
experience in code development should already know core (typically useful)
PHP or should quickly acquire a facility for it. I will accept this
opinion and move my "learn basic PHP" to-do item to the top of the list.
Since you already know javascript, I don't think you'll find PHP all
that hard to learn. The two are obviously different languages, with
different purposes. But they share much of the same syntax.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Jul 9 '08 #35

P: n/a
On Wed, 09 Jul 2008 13:38:59 -0400, Jerry Stuckle wrote:
Ivan Marsh wrote:
>On Wed, 09 Jul 2008 07:59:50 -0400, Jerry Stuckle wrote:
>>bill wrote:
Jerry Stuckle wrote:
Ivan Marsh wrote:
>On Tue, 08 Jul 2008 17:27:08 -0400, Jerry Stuckle wrote:
>>
>>Patient Guy wrote:
>>>Jerry Stuckle <js*******@attglobal.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.
>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.
http://en.wikipedia.org/wiki/Server-side_JavaScript
And how about the second part of the question - what hosts have such
packages installed?

I'd expect you'd have to be running your own server to use any of it.

Why is that? Servers are expensive for a relatively small site.
I don't know of any public hosts that provide server-side javascript
support. Though I can't say I've ever needed to look for one.

--
"Remain calm, we're here to protect you!"

Jul 9 '08 #36

P: n/a
Jerry Stuckle wrote:
Ivan Marsh wrote:
>On Wed, 09 Jul 2008 07:59:50 -0400, Jerry Stuckle wrote:
>>bill wrote:
Jerry Stuckle wrote:
Ivan Marsh wrote:
>On Tue, 08 Jul 2008 17:27:08 -0400, Jerry Stuckle wrote:
>>
>>Patient Guy wrote:
>>>Jerry Stuckle <js*******@attglobal.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.
>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.
http://en.wikipedia.org/wiki/Server-side_JavaScript
And how about the second part of the question - what hosts have such
packages installed?

I'd expect you'd have to be running your own server to use any of it.

Why is that? Servers are expensive for a relatively small site.
My last one cost me nothing more than a hard disk actually. The PC was
free..too old to run bleeding edge Vista I expect.

I already had a static IP address..just arrange some pass through and I
have my own linux/apache/Mysql/php setup that is under my control.
OK its not got big ISP backup, and only 448kbps upload, but its more
than enough for 'small sites'
Jul 9 '08 #37

P: n/a
The Natural Philosopher wrote:
Jerry Stuckle wrote:
>Ivan Marsh wrote:
>>On Wed, 09 Jul 2008 07:59:50 -0400, Jerry Stuckle wrote:

bill wrote:
Jerry Stuckle wrote:
>Ivan Marsh wrote:
>>On Tue, 08 Jul 2008 17:27:08 -0400, Jerry Stuckle wrote:
>>>
>>>Patient Guy wrote:
>>>>Jerry Stuckle <js*******@attglobal.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.
>>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.
http://en.wikipedia.org/wiki/Server-side_JavaScript
And how about the second part of the question - what hosts have such
packages installed?

I'd expect you'd have to be running your own server to use any of it.

Why is that? Servers are expensive for a relatively small site.
My last one cost me nothing more than a hard disk actually. The PC was
free..too old to run bleeding edge Vista I expect.

I already had a static IP address..just arrange some pass through and I
have my own linux/apache/Mysql/php setup that is under my control.
OK its not got big ISP backup, and only 448kbps upload, but its more
than enough for 'small sites'
And what do you do when you have a power outage? Or your phone line
goes down? Or the server crashes the day after you leave on a two week
vacation?

Of even when your host blocks port 80 because it violates their TOS?

Home hosting can be OK for hobby sites, but even a small business site
needs to be reliable.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Jul 9 '08 #38

P: n/a
Michael Fesser wrote:
.oO(The Natural Philosopher)
>Patient Guy wrote:
>>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.
Java SCRIPT (as opposed to java) runs in the browser exclusively.

Wrong. Various engines for running JS outside a browser context exist,
as already mentioned in the thread. JS is already incorporated in a
number of applications and document types that have nothing to do with
HTML or a browser.

http://en.wikipedia.org/wiki/Javascr...side_web_pages
>It
makes local decsison without reference to the server. This is great for
speed..you can change screen appearance fast and dynamically, producing
e.g. drop down menus and the like) at the expense of having to download
all the code TO the browser and more data than you probably need.

PHP is EXCLUSIVELY server side

PHP can also run in a browser (a proof-of-concept plugin for IE exists),
on the local machine, as a shell script, with a GUI ... It could even be
used like JS or Python for scripting in standalone applications.
>Halfway huse s do exist - Ajax - where partial page reloads are done
dynamically, using I think javascipt on e browser and PHP server side.

AJAX has nothing to do with either of them, at least not by definition.
It's just an overestimated hype, but in fact it's nothing new. It's just
a slightly different way for sending HTTP requests, but doesn't say
anything about the language(s) to use or the type of data that's sent.

A plugin or even an external application might be able to access the
browser's XHR object directly without any JavaScript, and the data
doesn't have to be in XML format. So what's left from "AJAX" in
practice? Just the "A" for asynchronous.
>>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.
Oh, its perfectly possible to pass commands from PHP to some other
engine: teh classic example is the Mysql server, which is interfaced to
PHP with a library ..but no one would ever attempt to execuste java
SCRIPT on the server

There's no reason to not do it. And in fact some do.
>because its a bloody awful language

Depends. It's a totally different way of thinking and programming. You
simply can't compare it with a classical OOP language. But once you've
understood it, you might find prototype-based programming quite useful
in certain situations.
>and is only
by and large written for broswers.

No language is written just for a single environment.
>Once you are server side you can in principle write in any language you
like, PHP being just a common popular one, but shell script python, C,
C++. PERL Java and so on are perfectly possible.

Exactly. You can use _every_ programming language you like. And JS
undoubtly _is_ a programming language.

Micha
Strictly you are correct. In practice for most people I stand by the
original post.

I see almost no reason to use javascript at all except when its the only
option, and that is the case when its the only (well supported) language
a browser can run.

Likewise expecting people to have php plugins for their browsers..is..at
best, expecting a lot.
Oh, and several languages have been written for a single environment: I
wrote one myself in fact.

Jul 9 '08 #39

P: n/a

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g5**********@registered.motzarella.org...
The Natural Philosopher wrote:
>Jerry Stuckle wrote:
>>Ivan Marsh wrote:
On Wed, 09 Jul 2008 07:59:50 -0400, Jerry Stuckle wrote:

bill wrote:
>Jerry Stuckle wrote:
>>Ivan Marsh wrote:
>>>On Tue, 08 Jul 2008 17:27:08 -0400, Jerry Stuckle wrote:
>>>>
>>>>Patient Guy wrote:
>>>>>Jerry Stuckle <js*******@attglobal.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.
>>>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.
>http://en.wikipedia.org/wiki/Server-side_JavaScript
And how about the second part of the question - what hosts have such
packages installed?

I'd expect you'd have to be running your own server to use any of it.
Why is that? Servers are expensive for a relatively small site.
My last one cost me nothing more than a hard disk actually. The PC was
free..too old to run bleeding edge Vista I expect.

I already had a static IP address..just arrange some pass through and I
have my own linux/apache/Mysql/php setup that is under my control.
OK its not got big ISP backup, and only 448kbps upload, but its more than
enough for 'small sites'

And what do you do when you have a power outage? Or your phone line goes
down? Or the server crashes the day after you leave on a two week
vacation?

Of even when your host blocks port 80 because it violates their TOS?

Home hosting can be OK for hobby sites, but even a small business site
needs to be reliable.
what a hair-splitter, jerry! every major host has different level service
plans including small business plans...which are NOT expensive. further,
none of the hosts i've used blocks 80 AND even non-static ip addressed
accounts are 'non-static'. i've had dhcp from charter for 8 years running a
small business. the ONLY time my IP has changed (twice, as a matter of fact)
is because I called them to complain about faulty equipment. changing the
IP, for them, is a manual process that happens upon the initialization of a
modem. that's it. there is NOTHING in the TOS about running your own
website...they just say they won't guarantee your uptime/accessibility. on
the business plan, you simply get faster service response and some roll-over
backup mechanisms when an outage occurs...and a guarantee that your IP won't
change upon device initialization (et. al).

again though, you're simply skirting the fact that you said javascript is
client-side only. you're diverting attention from that fact by bring up over
and over again that few servers support server-side javascript (which you
say doesn't exist in the first place). just own up to the mistake and leave
it at that. sabelotodo!
Jul 9 '08 #40

P: n/a

"Ivan Marsh" <iv*******@yahoo.comwrote in message
news:pa****************************@yahoo.com...
On Wed, 09 Jul 2008 12:36:39 -0500, Barry wrote:

>"Tim Streater" <ti**********@dante.org.ukwrote in message
news:ti********************************@news.indi vidual.net...
>>In article <CG************@newsfe07.lga>, "Barry" <no****@example.com>
wrote:

"Tim Streater" <ti**********@dante.org.ukwrote in message
news:ti********************************@news.in dividual.net...
In article <Ll***************@newsfe06.lga>, "Barry"
<no****@example.comwrote:

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g5**********@registered.motzarella.org.. .
bill wrote:
Jerry Stuckle wrote:

[snip]

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.
>
>
http://en.wikipedia.org/wiki/Server-side_JavaScript
And how about the second part of the question - what hosts have
such packages installed?

i like how you can speak for all web server installations, jerry.
further,
when proven wrong about js being client-side only, you just change
pace
and
say, 'well, no one has that on their server!'. you simply tried to
speak
with authority on a topic you obviously know nothing about. why not
just
say
you were wrong and then move on?

Because he's not wrong in any material sense.

the 'material sense' would be that he can't know what is installed on
every
web server out there. obviously, materially, if development is being
done on
products such as LiveWire and other server-side javascripting engines
then
there are web servers with such animals installed.

Of course not, bozo. I hadn't heard about this server side stuff
either, but as it never gets mentioned on comp.lang.javascript it's
obviously close to irrelevant.

My JavaScript book mentions a couple of times in its intro that "...
JavaScript can even be run on a server ..." and then goes on to take
1500 pages to explain about client-side.

Hence my use of the word "material".

skirting the error and saying *no one* has a web server set up to do
ss-js is likewise wrong.

Except that Jerry didn't say that.

Assuming he was unaware that javascript can be run server-side, asking
what hosts provide it is a perfectly reasonable question.
it is a safe assumption indeed, since he said it (noting the 'NOT'
emphasis)...

"Hint: javascript does NOT run on the server." - stuckle (read his first
response to the op...this was the second sentence)

asking what hosts provides the service was not a question, rather it was his
case in point...

"It is not part of the package of any web server." - stuckle (see above
quote in-line)

the next statement in his following response was...

"...what hosts have such packages installed?"

that's merely baiting his opponent, daring him to name one...i.e. 'if you're
right, then show me one.'. it's a pretty lame tactic loved by those how
cannot debate or know they can't defend their original position and don't
want to come out and say they were wrong.

Jul 9 '08 #41

P: n/a

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g5**********@registered.motzarella.org...
Barry wrote:
>"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g5**********@registered.motzarella.org...
>>bill wrote:
Jerry Stuckle wrote:
Ivan Marsh wrote:
>On Tue, 08 Jul 2008 17:27:08 -0400, Jerry Stuckle wrote:
>>
>>Patient Guy wrote:
>>>Jerry Stuckle <js*******@attglobal.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.
>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.
>
http://en.wikipedia.org/wiki/Server-side_JavaScript

And how about the second part of the question - what hosts have such
packages installed?

i like how you can speak for all web server installations, jerry.
further, when proven wrong about js being client-side only, you just
change pace and say, 'well, no one has that on their server!'. you simply
tried to speak with authority on a topic you obviously know nothing
about. why not just say you were wrong and then move on?

Yes, I was wrong about not being able to do it server side. However, of
course there are great limitations to doing it there.
it's good you can say that. now as for the limitations, that's as irrelevant
as asking who has the server capability. that's outside the scope of the
OP's question.
And I didn't say no one has that on their server.
"It is not part of the package of any web server." - stuckle

so, how are we to have read that?
I asked which hosts have it installed.

Please answer the question.
anyone that is willing to take your money to install one of several ss-js
interpreters. hosts are as reluctant to install them as they are perl (i
think you get the sarcasm there).
Jul 9 '08 #42

P: n/a

"The Natural Philosopher" <a@b.cwrote in message
news:12****************@proxy00.news.clara.net...
Michael Fesser wrote:
>.oO(The Natural Philosopher)
>>Patient Guy wrote:
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.

Java SCRIPT (as opposed to java) runs in the browser exclusively.

Wrong. Various engines for running JS outside a browser context exist,
as already mentioned in the thread. JS is already incorporated in a
number of applications and document types that have nothing to do with
HTML or a browser.

http://en.wikipedia.org/wiki/Javascr...side_web_pages
>>It makes local decsison without reference to the server. This is great
for speed..you can change screen appearance fast and dynamically,
producing e.g. drop down menus and the like) at the expense of having to
download all the code TO the browser and more data than you probably
need.

PHP is EXCLUSIVELY server side

PHP can also run in a browser (a proof-of-concept plugin for IE exists),
on the local machine, as a shell script, with a GUI ... It could even be
used like JS or Python for scripting in standalone applications.
>>Halfway huse s do exist - Ajax - where partial page reloads are done
dynamically, using I think javascipt on e browser and PHP server side.

AJAX has nothing to do with either of them, at least not by definition.
It's just an overestimated hype, but in fact it's nothing new. It's just
a slightly different way for sending HTTP requests, but doesn't say
anything about the language(s) to use or the type of data that's sent.

A plugin or even an external application might be able to access the
browser's XHR object directly without any JavaScript, and the data
doesn't have to be in XML format. So what's left from "AJAX" in
practice? Just the "A" for asynchronous.
>>>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.

Oh, its perfectly possible to pass commands from PHP to some other
engine: teh classic example is the Mysql server, which is interfaced to
PHP with a library ..but no one would ever attempt to execuste java
SCRIPT on the server

There's no reason to not do it. And in fact some do.
>>because its a bloody awful language

Depends. It's a totally different way of thinking and programming. You
simply can't compare it with a classical OOP language. But once you've
understood it, you might find prototype-based programming quite useful
in certain situations.
>>and is only by and large written for broswers.

No language is written just for a single environment.
>>Once you are server side you can in principle write in any language you
like, PHP being just a common popular one, but shell script python, C,
C++. PERL Java and so on are perfectly possible.

Exactly. You can use _every_ programming language you like. And JS
undoubtly _is_ a programming language.

Micha

Strictly you are correct. In practice for most people I stand by the
original post.

I see almost no reason to use javascript at all except when its the only
option, and that is the case when its the only (well supported) language a
browser can run.

Likewise expecting people to have php plugins for their browsers..is..at
best, expecting a lot.
Oh, and several languages have been written for a single environment: I
wrote one myself in fact.
'several' is not 'one'...and i hardly think anyone but you actually uses
your home-brewed version. ;^)

can you name another of the several?
Jul 9 '08 #43

P: n/a
Geoff Berrow wrote:
Message-ID: <X6******************************@earthlink.comfro m Jeff
contained the following:
> Now, it seems to me that rather that go through all this to possibly
get nowhere that learning a little more PHP would be easier. It looks a
lot like javascript to me to the point that when I embed javascript in
my php it's hard for me to tell which is which!

But easier. I find de-bugging JS a real pain.
It's a real hassle in IE.

In a moz flavor browser, you can type:

javascript:

in the location bar and bring up the error window. There's also
FireBug, but I have no experience with that.

Invariably you do the same sorts of things, like dropping in
breakpoints to read out your variables. Of course, IE handles events and
so much else differently than the DOM Standards Model, so you have to
test in more than one browser. That in itself is a hassle.

Jeff

Jul 9 '08 #44

P: n/a
On Wed, 09 Jul 2008 13:54:18 -0500, Barry wrote:

"Ivan Marsh" <iv*******@yahoo.comwrote in message
news:pa****************************@yahoo.com...
>On Wed, 09 Jul 2008 12:36:39 -0500, Barry wrote:

>>"Tim Streater" <ti**********@dante.org.ukwrote in message
news:ti********************************@news.ind ividual.net...
In article <CG************@newsfe07.lga>, "Barry"
<no****@example.comwrote:

"Tim Streater" <ti**********@dante.org.ukwrote in message
news:ti********************************@news.i ndividual.net...
In article <Ll***************@newsfe06.lga>, "Barry"
<no****@example.comwrote:

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g5**********@registered.motzarella.org. ..
bill wrote:
Jerry Stuckle wrote:

[snip]

>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.
>>
>>
http://en.wikipedia.org/wiki/Server-side_JavaScript
>
>
And how about the second part of the question - what hosts have
such packages installed?
>
i like how you can speak for all web server installations, jerry.
further,
when proven wrong about js being client-side only, you just
change pace
and
say, 'well, no one has that on their server!'. you simply tried
to speak
with authority on a topic you obviously know nothing about. why
not just
say
you were wrong and then move on?

Because he's not wrong in any material sense.
>
the 'material sense' would be that he can't know what is installed
on every
web server out there. obviously, materially, if development is being
done on
products such as LiveWire and other server-side javascripting
engines then
there are web servers with such animals installed.

Of course not, bozo. I hadn't heard about this server side stuff
either, but as it never gets mentioned on comp.lang.javascript it's
obviously close to irrelevant.

My JavaScript book mentions a couple of times in its intro that "...
JavaScript can even be run on a server ..." and then goes on to take
1500 pages to explain about client-side.

Hence my use of the word "material".

skirting the error and saying *no one* has a web server set up to do
ss-js is likewise wrong.

Except that Jerry didn't say that.

Assuming he was unaware that javascript can be run server-side, asking
what hosts provide it is a perfectly reasonable question.

it is a safe assumption indeed, since he said it (noting the 'NOT'
emphasis)...

"Hint: javascript does NOT run on the server." - stuckle (read his first
response to the op...this was the second sentence)

asking what hosts provides the service was not a question, rather it was
his case in point...

"It is not part of the package of any web server." - stuckle (see above
quote in-line)

the next statement in his following response was...

"...what hosts have such packages installed?"

that's merely baiting his opponent, daring him to name one...i.e. 'if
you're right, then show me one.'. it's a pretty lame tactic loved by
those how cannot debate or know they can't defend their original
position and don't want to come out and say they were wrong.
I was not aware you can read minds. I apologize for questioning your
omniscience.

--
"Remain calm, we're here to protect you!"

Jul 9 '08 #45

P: n/a

"Ivan Marsh" <iv*******@yahoo.comwrote in message
news:pa****************************@yahoo.com...
On Wed, 09 Jul 2008 13:54:18 -0500, Barry wrote:

>"Ivan Marsh" <iv*******@yahoo.comwrote in message
news:pa****************************@yahoo.com.. .
>>On Wed, 09 Jul 2008 12:36:39 -0500, Barry wrote:
"Tim Streater" <ti**********@dante.org.ukwrote in message
news:ti********************************@news.in dividual.net...
In article <CG************@newsfe07.lga>, "Barry"
<no****@example.comwrote:
>
>"Tim Streater" <ti**********@dante.org.ukwrote in message
>news:ti********************************@news. individual.net...
In article <Ll***************@newsfe06.lga>, "Barry"
<no****@example.comwrote:
>
>"Jerry Stuckle" <js*******@attglobal.netwrote in message
>news:g5**********@registered.motzarella.org.. .
bill wrote:
>Jerry Stuckle wrote:
>
[snip]
>
>>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.
>>>
>>>
>http://en.wikipedia.org/wiki/Server-side_JavaScript
>>
>>
And how about the second part of the question - what hosts have
such packages installed?
>>
>i like how you can speak for all web server installations, jerry.
>further,
>when proven wrong about js being client-side only, you just
>change pace
>and
>say, 'well, no one has that on their server!'. you simply tried
>to speak
>with authority on a topic you obviously know nothing about. why
>not just
>say
>you were wrong and then move on?
>
Because he's not wrong in any material sense.
>>
>the 'material sense' would be that he can't know what is installed
>on every
>web server out there. obviously, materially, if development is being
>done on
>products such as LiveWire and other server-side javascripting
>engines then
>there are web servers with such animals installed.
>
Of course not, bozo. I hadn't heard about this server side stuff
either, but as it never gets mentioned on comp.lang.javascript it's
obviously close to irrelevant.
>
My JavaScript book mentions a couple of times in its intro that "...
JavaScript can even be run on a server ..." and then goes on to take
1500 pages to explain about client-side.
>
Hence my use of the word "material".

skirting the error and saying *no one* has a web server set up to do
ss-js is likewise wrong.

Except that Jerry didn't say that.

Assuming he was unaware that javascript can be run server-side, asking
what hosts provide it is a perfectly reasonable question.

it is a safe assumption indeed, since he said it (noting the 'NOT'
emphasis)...

"Hint: javascript does NOT run on the server." - stuckle (read his first
response to the op...this was the second sentence)

asking what hosts provides the service was not a question, rather it was
his case in point...

"It is not part of the package of any web server." - stuckle (see above
quote in-line)

the next statement in his following response was...

"...what hosts have such packages installed?"

that's merely baiting his opponent, daring him to name one...i.e. 'if
you're right, then show me one.'. it's a pretty lame tactic loved by
those how cannot debate or know they can't defend their original
position and don't want to come out and say they were wrong.

I was not aware you can read minds. I apologize for questioning your
omniscience.
you are forgiven, however related to this, it was merely having reading
comprehension skills. ;^)
Jul 9 '08 #46

P: n/a

"Ivan Marsh" <iv*******@yahoo.comwrote in message
news:pa****************************@yahoo.com...
On Wed, 09 Jul 2008 13:54:18 -0500, Barry wrote:

>"Ivan Marsh" <iv*******@yahoo.comwrote in message
news:pa****************************@yahoo.com.. .
>>On Wed, 09 Jul 2008 12:36:39 -0500, Barry wrote:
"Tim Streater" <ti**********@dante.org.ukwrote in message
news:ti********************************@news.in dividual.net...
In article <CG************@newsfe07.lga>, "Barry"
<no****@example.comwrote:
>
>"Tim Streater" <ti**********@dante.org.ukwrote in message
>news:ti********************************@news. individual.net...
In article <Ll***************@newsfe06.lga>, "Barry"
<no****@example.comwrote:
>
>"Jerry Stuckle" <js*******@attglobal.netwrote in message
>news:g5**********@registered.motzarella.org.. .
bill wrote:
>Jerry Stuckle wrote:
>
[snip]
>
>>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.
>>>
>>>
>http://en.wikipedia.org/wiki/Server-side_JavaScript
>>
>>
And how about the second part of the question - what hosts have
such packages installed?
>>
>i like how you can speak for all web server installations, jerry.
>further,
>when proven wrong about js being client-side only, you just
>change pace
>and
>say, 'well, no one has that on their server!'. you simply tried
>to speak
>with authority on a topic you obviously know nothing about. why
>not just
>say
>you were wrong and then move on?
>
Because he's not wrong in any material sense.
>>
>the 'material sense' would be that he can't know what is installed
>on every
>web server out there. obviously, materially, if development is being
>done on
>products such as LiveWire and other server-side javascripting
>engines then
>there are web servers with such animals installed.
>
Of course not, bozo. I hadn't heard about this server side stuff
either, but as it never gets mentioned on comp.lang.javascript it's
obviously close to irrelevant.
>
My JavaScript book mentions a couple of times in its intro that "...
JavaScript can even be run on a server ..." and then goes on to take
1500 pages to explain about client-side.
>
Hence my use of the word "material".

skirting the error and saying *no one* has a web server set up to do
ss-js is likewise wrong.

Except that Jerry didn't say that.

Assuming he was unaware that javascript can be run server-side, asking
what hosts provide it is a perfectly reasonable question.

it is a safe assumption indeed, since he said it (noting the 'NOT'
emphasis)...

"Hint: javascript does NOT run on the server." - stuckle (read his first
response to the op...this was the second sentence)

asking what hosts provides the service was not a question, rather it was
his case in point...

"It is not part of the package of any web server." - stuckle (see above
quote in-line)

the next statement in his following response was...

"...what hosts have such packages installed?"

that's merely baiting his opponent, daring him to name one...i.e. 'if
you're right, then show me one.'. it's a pretty lame tactic loved by
those how cannot debate or know they can't defend their original
position and don't want to come out and say they were wrong.

I was not aware you can read minds. I apologize for questioning your
omniscience.
btw, aside from having reading comprehension skills, i also rarely
contradict myself...especially so daftly as to do it one sentence after
another...as in:

"I hadn't heard about this server side stuff either."

directly followed by:

"My JavaScript book mentions a couple of times in its intro that '...
JavaScript can even be run on a server ...'"

i hope you can appreciate my amusement on that one as well.
Jul 9 '08 #47

P: n/a
Jerry Stuckle wrote:
Hint: javascript does NOT run on the server.
Actually, server JavaScript was the original language of the
HTML-embedded class now dominated by JSP, ASP, and PHP.

--
John W. Kennedy
"Compact is becoming contract,
Man only earns and pays."
-- Charles Williams. "Bors to Elayne: On the King's Coins"
Jul 9 '08 #48

P: n/a
On Wed, 09 Jul 2008 16:49:01 -0400, John W Kennedy wrote:
Jerry Stuckle wrote:
>Hint: javascript does NOT run on the server.

Actually, server JavaScript was the original language of the
HTML-embedded class now dominated by JSP, ASP, and PHP.
Since Javascript and PHP both originate in 1995 I'm not sure how you can
make that assertion.

--
"Remain calm, we're here to protect you!"

Jul 9 '08 #49

P: n/a
Jerry Stuckle wrote:
>
And how about the second part of the question - what hosts have such
packages installed?
I agree with your point that Javascript makes more sense on the client
side. However, why do you think that there are so many packages without
any hosts installing them?
Jul 9 '08 #50

84 Replies

This discussion thread is closed

Replies have been disabled for this discussion.