Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #17406 > unrolled thread

form field/spreadsheet question

Back to article view | Back to comp.lang.javascript

Contents

  form field/spreadsheet question "Jon" <no-reply@no-reply.com> - 2012-12-01 23:22 -0500
    Re: form field/spreadsheet question Luuk <luuk@invalid.lan> - 2012-12-02 13:55 +0100
      Re: form field/spreadsheet question Wally W. <ww84wa@aim.com> - 2012-12-02 12:19 -0500
        Re: form field/spreadsheet question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-02 19:06 +0100
          Re: form field/spreadsheet question Wally W. <ww84wa@aim.com> - 2012-12-02 14:29 -0500
            Re: form field/spreadsheet question Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-02 20:10 +0000
              Re: form field/spreadsheet question Wally W. <ww84wa@aim.com> - 2012-12-02 17:18 -0500
            Re: form field/spreadsheet question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-02 21:22 +0100
              Re: form field/spreadsheet question Wally W. <ww84wa@aim.com> - 2012-12-02 17:15 -0500
                Re: form field/spreadsheet question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-03 00:29 +0100
                  Re: form field/spreadsheet question Wally W. <ww84wa@aim.com> - 2012-12-02 19:55 -0500
                  Re: form field/spreadsheet question Dr J R Stockton <reply1249@merlyn.demon.co.uk.invalid> - 2012-12-03 18:30 +0000
                    Re: form field/spreadsheet question Andrew Poulos <ap_prog@hotmail.com> - 2012-12-04 11:26 +1100
              Re: form field/spreadsheet question John G Harris <john@nospam.demon.co.uk> - 2012-12-03 20:18 +0000
                Re: form field/spreadsheet question Andrew Poulos <ap_prog@hotmail.com> - 2012-12-04 07:43 +1100
                  Re: form field/spreadsheet question John G Harris <john@nospam.demon.co.uk> - 2012-12-04 09:10 +0000
                    Re: form field/spreadsheet question Andrew Poulos <ap_prog@hotmail.com> - 2012-12-04 20:31 +1100
                      Re: form field/spreadsheet question Scott Sauyet <scott.sauyet@gmail.com> - 2012-12-04 06:15 -0800
                      Re: form field/spreadsheet question John G Harris <john@nospam.demon.co.uk> - 2012-12-04 14:34 +0000
    Re: form field/spreadsheet question Martin Leese <please@see.Web.for.e-mail.INVALID> - 2012-12-02 11:27 -0700
      Re: form field/spreadsheet question "Jon" <no-reply@no-reply.com> - 2012-12-02 19:01 -0500
        spreadsheet-to-Javascript translator "Jon" <no-reply@no-reply.com> - 2012-12-02 20:06 -0500
          Re: spreadsheet-to-Javascript translator Patricia Shanahan <pats@acm.org> - 2012-12-03 10:26 -0800
      Re: form field/spreadsheet question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-03 02:42 +0000

Page 1 of 2  [1] 2  Next page →

#17406 — form field/spreadsheet question

Please go to my web page and see what I'm trying to do:

http://3d-triangulation-calculator.bravehost.com/

The user enters 12 values into the Input form fields, clicks on "Calculate" 
and the page displays the answer as 6 values in the Output table.

It doesn't do that yet, but it is what I'd like it to do.

The Input values need to automatically enter into D24:F26 and I24:K24 of the 
embedded spreadsheet.  The spreadsheet equations (long and complex) 
calculate the solution and are automatically entered in the Output table 
from D28:F29 on the embedded spreadsheet.

The embedded spreadsheet displayed on the page is a ZOHO spreadsheet linked 
from its site.  Below this are two links to the same spreadsheet in Excel 97 
and Open Office Calc.  Below that are the actual equations used in the 
spreadsheet calculations.

Can anyone help me put this together?  I have been told that there are java 
script programs that already do this.  Can I adapt one for this?  Do I have 
to have the spreadsheet on the server?  I only know a little Borland C++ and 
Microsoft Visual C++.  Is there a tutorial where I can learn javascript for 
this application?  Where can I find an editor/compiler/debugger for 
Javascript? 

[toc] | [next] | [standalone]

#17408

On 02-12-2012 05:22, Jon wrote:
> Where can I find an editor/..../.... for Javascript?

Notepad.exe, or any other text-editor....

> Where can I find an ..../compiler/.... for Javascript?

There is no compiler for Javascript, because it is an interpreted language.

> Where can I find an ..../..../debugger for Javascript?

In IE9: press F12
In Firefox: install Firebug (http://getfirebug.com/)

[toc] | [prev] | [next] | [standalone]

#17411

On Sun, 02 Dec 2012 13:55:39 +0100, Luuk wrote:

>On 02-12-2012 05:22, Jon wrote:
>> Where can I find an editor/..../.... for Javascript?
>
>Notepad.exe, or any other text-editor....
>
>> Where can I find an ..../compiler/.... for Javascript?
>
>There is no compiler for Javascript, 

That is an oversight in the IT world.


>because it is an interpreted language.

One does not follow from the other.

Spreadsheets are also "interpreted." That didn't stop someone from
writing a compiler:
http://en.wikipedia.org/wiki/As_Easy_As


How many would like a compliable web page that has:
1. Embedded javascript
2. A 'save as" capability to write all contents, including entered
values, to a disk file?
3. An "open file" capability to resume work on or print values in a
file placed on disk with the "save as" feature mentioned above?

I know I would like such a compiler.

Ideally, it would accept command line arguments to:
1. Modify the contents of named fields as the 'app' opens.
2. Print the results
3. Close the file after printing


>> Where can I find an ..../..../debugger for Javascript?
>
>In IE9: press F12
>In Firefox: install Firebug (http://getfirebug.com/)
>

[toc] | [prev] | [next] | [standalone]

#17413

Wally W.  wrote:

> On Sun, 02 Dec 2012 13:55:39 +0100, Luuk wrote:
>> On 02-12-2012 05:22, Jon wrote:
>>> Where can I find an editor/..../.... for Javascript?
>>
>> Notepad.exe, or any other text-editor....
>>
>>> Where can I find an ..../compiler/.... for Javascript?
>>
>> There is no compiler for Javascript,
> 
> That is an oversight in the IT world.

Strictly speaking, what was stated is correct, because there is no 
"Javascript" language to begin with: <http://PointedEars.de/es-matrix>

Loosely speaking it is wrong, though, because ECMAScript source code in Web 
browsers and elsewhere is JIT-compiled and _not_ interpreted verbatim.  Most 
of the script engines of ECMAScript implementations compile source code to 
bytecode, executed by a Virtual Machine (this applies to Netscape/Mozilla 
JavaScript and Microsoft JScript).  Google V8 even JIT-compiles source code 
to native machine code, which part of why it is so fast by comparison.
 
>> because it is an interpreted language.
> 
> One does not follow from the other.

And since even the premise is wrong …

> Spreadsheets are also "interpreted."

Spreadsheets are not a programming language.

> That didn't stop someone from
> writing a compiler:
> http://en.wikipedia.org/wiki/As_Easy_As

ISTM you are confusing things.
 
> How many would like a compliable web page that has:
> 1. Embedded javascript

Meaning what exactly?

> 2. A 'save as" capability to write all contents, including entered
> values, to a disk file?

That capability exists already.

> 3. An "open file" capability to resume work on or print values in a
> file placed on disk with the "save as" feature mentioned above?

That too.

> I know I would like such a compiler.

I do not think you know what a compiler is or where you are posting to, 
though.


F'up2 cljs

PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

[toc] | [prev] | [next] | [standalone]

#17418

On Sun, 02 Dec 2012 19:06:27 +0100, Thomas 'PointedEars' Lahn wrote:

>Wally W.  wrote:
>
>> On Sun, 02 Dec 2012 13:55:39 +0100, Luuk wrote:
>>> On 02-12-2012 05:22, Jon wrote:
>>>> Where can I find an editor/..../.... for Javascript?
>>>
>>> Notepad.exe, or any other text-editor....
>>>
>>>> Where can I find an ..../compiler/.... for Javascript?
>>>
>>> There is no compiler for Javascript,
>> 
>> That is an oversight in the IT world.
>
>Strictly speaking, what was stated is correct, 

As was my statement.

>because there is no 
>"Javascript" language to begin with: <http://PointedEars.de/es-matrix>

Your link highlights in incompatibilities between script engines.

A script I develop for my own use in my preferred browser may be
useless in someone else's preferred browser.

With web pages and javascript so prevalent, it is an oversight that
there is no generally available program to "compile" the pages with
*some* version of javascript to a browser-independent EXE file.

>Loosely speaking it is wrong, though, because ECMAScript source code in Web 
>browsers and elsewhere is JIT-compiled and _not_ interpreted verbatim.  Most 
>of the script engines of ECMAScript implementations compile source code to 
>bytecode, executed by a Virtual Machine (this applies to Netscape/Mozilla 
>JavaScript and Microsoft JScript).  Google V8 even JIT-compiles source code 
>to native machine code, which part of why it is so fast by comparison.

Which is of no help to one who wants to convert their web page,
complete with javascript, to a browser-independent EXE file.


>>> because it is an interpreted language.
>> 
>> One does not follow from the other.
>
>And since even the premise is wrong …
>
>> Spreadsheets are also "interpreted."
>
>Spreadsheets are not a programming language.

Missing the point for the semantics.

Functions in spreadsheet cells are, in a practical sense which may not
meet a purist's definition, "interpreted."

Javascript operating on forms in a web page can behave similarly to
simple, or not-so-simple, spreadsheets.


>> That didn't stop someone from
>> writing a compiler:
>> http://en.wikipedia.org/wiki/As_Easy_As
>
>ISTM you are confusing things.
> 
>> How many would like a compliable web page that has:
>> 1. Embedded javascript
>
>Meaning what exactly?

For example, this web page could be converted to a stand-alone EXE
file with all the functionality of its scripting fully implemented:
http://www.pmel.org/unitconv.htm


>> 2. A 'save as" capability to write all contents, including entered
>> values, to a disk file?
>
>That capability exists already.

Where?


>> 3. An "open file" capability to resume work on or print values in a
>> file placed on disk with the "save as" feature mentioned above?
>
>That too.

Where?


>> I know I would like such a compiler.
>
>I do not think you know what a compiler is or where you are posting to, 
>though.

I suppose the software to produce CHM ("compiled HTML") files would
not meet your definition of "compiler."

The "compiler" I would like for web pages with embedded javascript
would be similar, but with more features.

My mention of "embedded javascript" recognizes that web pages do *not*
necessarily need to contain javascript. The ideas seems to be anathema
to some webmasters, but it is true.

[toc] | [prev] | [next] | [standalone]

#17419

On Sun, 02 Dec 2012 14:29:07 -0500, Wally W. wrote:

> For example, this web page could be converted to a stand-alone EXE file
> with all the functionality of its scripting fully implemented:
> http://www.pmel.org/unitconv.htm

For what operating systems?

I really don't think the planet, and certainly that part of it using 
microsoft operating systems, needs another malware delivery vector.

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#17423

On Sun, 2 Dec 2012 20:10:43 +0000 (UTC), Denis McMahon wrote:

>On Sun, 02 Dec 2012 14:29:07 -0500, Wally W. wrote:
>
>> For example, this web page could be converted to a stand-alone EXE file
>> with all the functionality of its scripting fully implemented:
>> http://www.pmel.org/unitconv.htm
>
>For what operating systems?
>
>I really don't think the planet, and certainly that part of it using 
>microsoft operating systems, needs another malware delivery vector.
>
>Rgds
>
>Denis McMahon

Any EXE file can be a malware delivery vector.

Why would a program that can only process and save HTML forms be more
suspect than others?

[toc] | [prev] | [next] | [standalone]

#17420

Wally W.  wrote:
^^^^^^^^
Please fix that.

> On Sun, 02 Dec 2012 19:06:27 +0100, Thomas 'PointedEars' Lahn wrote:
>> Wally W.  wrote:
>>> On Sun, 02 Dec 2012 13:55:39 +0100, Luuk wrote:
>>>> On 02-12-2012 05:22, Jon wrote:
>>>>> Where can I find an editor/..../.... for Javascript?
>>>>
>>>> Notepad.exe, or any other text-editor....
>>>>
>>>>> Where can I find an ..../compiler/.... for Javascript?
>>>>
>>>> There is no compiler for Javascript,
>>> 
>>> That is an oversight in the IT world.
>>
>> Strictly speaking, what was stated is correct,
> 
> As was my statement.

Most certainly not.
 
>> because there is no "Javascript" language to begin with:
>> <http://PointedEars.de/es-matrix>
> 
> Your link highlights in incompatibilities between script engines.

I am comparing the language features supported by different ECMAScript 
implementations there.
 
> A script I develop for my own use in my preferred browser may be
> useless in someone else's preferred browser.

Correct.  This is why it is important to know where implementations differ 
and where not, so that appropriate measures can be taken by the Web 
developer.  I am currently focusing on ECMAScript implementations;
DOM implementations are another matter altogether (and I will probably 
investigate them more thoroughly later).

> With web pages and javascript so prevalent,

There are no "web pages" and there is no "javascript".  As soon as you can 
accept that, and stop talking like you want to sell something, understanding 
can begin.

> it is an oversight that there is no generally available program to
> "compile" the pages with *some* version of javascript

Different ECMAScript implementations are not versions of one imagined 
universally implemented and uniform "javascript" language; they are separate 
programming languages in their own right (with a common root, most of which 
is standardized in ECMAScript).

> to a browser-independent EXE file.

You have overlooked the existence of such programs.  However, such a program 
would not be overly useful with regard to browsers, because ECMAScript 
implementations are scripting languages, which "[are] programming 
language[s] that [are] used to manipulate, customise, and automate the 
facilities of an existing system." (ECMAScript Language Specification, 5.1 
Edition, p. 2).  As such, they are primarily interfacing languages, and APIs 
differ among browsers.  You cannot avoid that; browser vendors will not let 
you.  And if you are honest, you would not want to: this competition is 
*basically* a Good Thing.

>> Loosely speaking it is wrong, though, because ECMAScript source code in
>> Web browsers and elsewhere is JIT-compiled and _not_ interpreted
>> verbatim. 
>> Most of the script engines of ECMAScript implementations compile source
>> code to bytecode, executed by a Virtual Machine (this applies to
>> Netscape/Mozilla JavaScript and Microsoft JScript).  Google V8 even JIT-
>> compiles source code to native machine code, which part of why it is so
>> fast by comparison.
> 
> Which is of no help to one who wants to convert their web page,
> complete with javascript, to a browser-independent EXE file.

Those people should learn to know what they are doing before they are doing 
it, and then might be interested in
<https://developer.mozilla.org/en/docs/GRE> pp.

But that has nothing to do with "web pages" (read: HTML documents) as such.

>>> Spreadsheets are also "interpreted."
>> Spreadsheets are not a programming language.
> 
> Missing the point for the semantics.

I am not sure yet, are you trolling or are you just completely clueless?
 
> Functions in spreadsheet cells are, in a practical sense which may not
> meet a purist's definition, "interpreted."

Yes, but that is a different thing.  Functions in spreadsheet cells are a 
part of an API, which is used with programming languages.

> Javascript operating on forms in a web page can behave similarly to
> simple, or not-so-simple, spreadsheets.

While that is partially true, you still have no clue what you are talking 
about.  There are programming languages, and there are APIs that can be used 
with programming languages.  That is no different with ECMAScript 
implementations and the DOM API.

>>> That didn't stop someone from
>>> writing a compiler:
>>> http://en.wikipedia.org/wiki/As_Easy_As
>>
>> ISTM you are confusing things.
>> 
>>> How many would like a compliable web page that has:
>>> 1. Embedded javascript
>>
>> Meaning what exactly?
> 
> For example, this web page could be converted to a stand-alone EXE
> file with all the functionality of its scripting fully implemented:
> http://www.pmel.org/unitconv.htm

No, it could not.  The functionality of "the scripting" to be cross-browser 
would be lost to begin with.

>>> 2. A 'save as" capability to write all contents, including entered
>>> values, to a disk file?
>> That capability exists already.
> 
> Where?

In all script-capable Web browsers.

>>> 3. An "open file" capability to resume work on or print values in a
>>> file placed on disk with the "save as" feature mentioned above?
>> That too.
> 
> Where?

Same.

>>> I know I would like such a compiler.
>> I do not think you know what a compiler is or where you are posting to,
>> though.
> 
> I suppose the software to produce CHM ("compiled HTML") files would
> not meet your definition of "compiler."

That is correct.  Those files need an executable (HTMLHelp.exe & friends) to 
be displayed, which in turn uses a runtime library, MSHTML.dll.  In short, 
the browser core.  That library supports JScript, Microsoft's ECMAScript 
implementation (through JScript*.dll), and so does Internet Explorer, for 
example, because it is based on MSHTML.dll (which is why I am talking about 
JScript and the MSHTML DOM and not "javascript in Internet Explorer").
.CHM files are not executables themselves, and HTML Help certainly is not a 
programming language.

<http://msdn.microsoft.com/en-
us/library/windows/desktop/ms524402(v=vs.85).aspx>

> The "compiler" I would like for web pages with embedded javascript
> would be similar, but with more features.

Such as?

> My mention of "embedded javascript" recognizes that web pages do *not*
> necessarily need to contain javascript. The ideas seems to be anathema
> to some webmasters, but it is true.

ACK, but your argumentation is inconsistent nevertheless.  You cannot have 
"embedded javascript" without having "javascript".


PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#17422

On Sun, 02 Dec 2012 21:22:18 +0100, Thomas 'PointedEars' Lahn wrote:

>Wally W.  wrote:
>^^^^^^^^
>Please fix that.

Fix what?


>> On Sun, 02 Dec 2012 19:06:27 +0100, Thomas 'PointedEars' Lahn wrote:
>>> Wally W.  wrote:
>>>> On Sun, 02 Dec 2012 13:55:39 +0100, Luuk wrote:
>>>>> On 02-12-2012 05:22, Jon wrote:
>>>>>> Where can I find an editor/..../.... for Javascript?
>>>>>
>>>>> Notepad.exe, or any other text-editor....
>>>>>
>>>>>> Where can I find an ..../compiler/.... for Javascript?
>>>>>
>>>>> There is no compiler for Javascript,
>>>> 
>>>> That is an oversight in the IT world.
>>>
>>> Strictly speaking, what was stated is correct,
>> 
>> As was my statement.
>
>Most certainly not.

Then it should be easy for you to link to a program that converts HTML
documents with forms and scripting into stand-alone EXE files.

 
>>> because there is no "Javascript" language to begin with:
>>> <http://PointedEars.de/es-matrix>
>> 
>> Your link highlights in incompatibilities between script engines.
>
>I am comparing the language features supported by different ECMAScript 
>implementations there.

Which is irrelevant to what I am wanting.

 
>> A script I develop for my own use in my preferred browser may be
>> useless in someone else's preferred browser.
>
>Correct.  This is why it is important to know where implementations differ 
>and where not, so that appropriate measures can be taken by the Web 
>developer.  I am currently focusing on ECMAScript implementations;
>DOM implementations are another matter altogether (and I will probably 
>investigate them more thoroughly later).

I want it to be able to run *apart from* a browser.


>> With web pages and javascript so prevalent,
>
>There are no "web pages" and there is no "javascript".  As soon as you can 
>accept that, and stop talking like you want to sell something, understanding 
>can begin.

What am I trying to sell? Where do you read that I have a program of
the type I seek?


>> it is an oversight that there is no generally available program to
>> "compile" the pages with *some* version of javascript
>
>Different ECMAScript implementations are not versions of one imagined 
>universally implemented and uniform "javascript" language; they are separate 
>programming languages in their own right (with a common root, most of which 
>is standardized in ECMAScript).

Fine. I don't care about all the variations.

I want *one* version of javascript to debug within a browser, and then
to turn the completed effort (form and scripting) into a stand-alone
EXE file.


>> to a browser-independent EXE file.
>
>You have overlooked the existence of such programs.  

Such as?

>However, such a program 
>would not be overly useful with regard to browsers, 

It isn't intended to be useful with regard to browsers.

It is intended to be useful *apart from* browsers.


>because ECMAScript 
>implementations are scripting languages, which "[are] programming 
>language[s] that [are] used to manipulate, customise, and automate the 
>facilities of an existing system." (ECMAScript Language Specification, 5.1 
>Edition, p. 2).  As such, they are primarily interfacing languages, and APIs 
>differ among browsers.  You cannot avoid that; browser vendors will not let 
>you.  And if you are honest, you would not want to: this competition is 
>*basically* a Good Thing.

What competition?

What I seek doesn't exist.


>>> Loosely speaking it is wrong, though, because ECMAScript source code in
>>> Web browsers and elsewhere is JIT-compiled and _not_ interpreted
>>> verbatim. 
>>> Most of the script engines of ECMAScript implementations compile source
>>> code to bytecode, executed by a Virtual Machine (this applies to
>>> Netscape/Mozilla JavaScript and Microsoft JScript).  Google V8 even JIT-
>>> compiles source code to native machine code, which part of why it is so
>>> fast by comparison.
>> 
>> Which is of no help to one who wants to convert their web page,
>> complete with javascript, to a browser-independent EXE file.
>
>Those people should learn to know what they are doing before they are doing 
>it, and then might be interested in
><https://developer.mozilla.org/en/docs/GRE> pp.

One who wants to convert their web page to an EXE file doesn't want to
*write* the program to do it, they want to *use* the program to feed
their HTML file to a "compiler" and obtain a stand-alone EXE file with
the desired functionality.

Creating such a program is more in the purview of those reading
comp.lang than those in comp.lang.javascript. 

>But that has nothing to do with "web pages" (read: HTML documents) as such.

Again, missing the point for the semantics.

>>>> Spreadsheets are also "interpreted."
>>> Spreadsheets are not a programming language.
>> 
>> Missing the point for the semantics.
>
>I am not sure yet, are you trolling or are you just completely clueless?

Your reading skills appear to be quite narrow.

Everyone doesn't insist on such crisp meanings for every word when
discussing a concept.

When paired with the readiness to insult, the lack of read skill makes
quite a combination.


>> Functions in spreadsheet cells are, in a practical sense which may not
>> meet a purist's definition, "interpreted."
>
>Yes, but that is a different thing.  Functions in spreadsheet cells are a 
>part of an API, which is used with programming languages.

Irrelevant.

The point is that a human-written expression is executed by the CPU.

There is no reason why a javascript statement can't be packaged for
use by a portable engine that is not part of a browser.

There is more than one way to accomplish that: API, byte code, or
for-real compiling. I don't care *how* it is done. I would like
something that *does* it.

>> Javascript operating on forms in a web page can behave similarly to
>> simple, or not-so-simple, spreadsheets.
>
>While that is partially true, you still have no clue what you are talking 
>about.  There are programming languages, and there are APIs that can be used 
>with programming languages.  That is no different with ECMAScript 
>implementations and the DOM API.

Actually, you don't seem to understand the request.


>>>> That didn't stop someone from
>>>> writing a compiler:
>>>> http://en.wikipedia.org/wiki/As_Easy_As
>>>
>>> ISTM you are confusing things.
>>> 
>>>> How many would like a compliable web page that has:
>>>> 1. Embedded javascript
>>>
>>> Meaning what exactly?
>> 
>> For example, this web page could be converted to a stand-alone EXE
>> file with all the functionality of its scripting fully implemented:
>> http://www.pmel.org/unitconv.htm
>
>No, it could not.  The functionality of "the scripting" to be cross-browser 
>would be lost to begin with.

Fine. It doesn't need to be cross-browser when it is in a stand-alone
EXE file.


>>>> 2. A 'save as" capability to write all contents, including entered
>>>> values, to a disk file?
>>> That capability exists already.
>> 
>> Where?
>
>In all script-capable Web browsers.

Not so.

Internet explorer does not save the values entered in this form when
the page is save to the local disk:

http://voltaires.org/tech/eformulas.htm


>>>> 3. An "open file" capability to resume work on or print values in a
>>>> file placed on disk with the "save as" feature mentioned above?
>>> That too.
>> 
>> Where?
>
>Same.

See above.

>>>> I know I would like such a compiler.
>>> I do not think you know what a compiler is or where you are posting to,
>>> though.
>> 
>> I suppose the software to produce CHM ("compiled HTML") files would
>> not meet your definition of "compiler."
>
>That is correct.  Those files need an executable (HTMLHelp.exe & friends) to 
>be displayed, which in turn uses a runtime library, MSHTML.dll.  In short, 
>the browser core.  That library supports JScript, Microsoft's ECMAScript 
>implementation (through JScript*.dll), and so does Internet Explorer, for 
>example, because it is based on MSHTML.dll (which is why I am talking about 
>JScript and the MSHTML DOM and not "javascript in Internet Explorer").
>.CHM files are not executables themselves, and HTML Help certainly is not a 
>programming language.
>
><http://msdn.microsoft.com/en-
>us/library/windows/desktop/ms524402(v=vs.85).aspx>

My purpose was to illustrate another use of the word "compile" beyond
the narrow definition you seem to allow.

>> The "compiler" I would like for web pages with embedded javascript
>> would be similar, but with more features.
>
>Such as?

As listed in my first post.


>> My mention of "embedded javascript" recognizes that web pages do *not*
>> necessarily need to contain javascript. The ideas seems to be anathema
>> to some webmasters, but it is true.
>
>ACK, but your argumentation is inconsistent nevertheless.  You cannot have 
>"embedded javascript" without having "javascript".

Others seem to acknowledge the existence of javascript.

Perhaps it doesn't exist in your world of narrow definitions.

Others are able to perceive and use it just fine.

[toc] | [prev] | [next] | [standalone]

#17424

Wally W.  wrote:

> On Sun, 02 Dec 2012 21:22:18 +0100, Thomas 'PointedEars' Lahn wrote:
>>Wally W.  wrote:
>>^^^^^^^^
>>Please fix that.
> 
> Fix what?

Fix your "name".  Basic politeness requires that you use your real and full 
name (first and last suffices) as I am using mine.  That is, if I should 
consider your postings.

>>> On Sun, 02 Dec 2012 19:06:27 +0100, Thomas 'PointedEars' Lahn wrote:
>>>> Wally W.  wrote:
>>>>> On Sun, 02 Dec 2012 13:55:39 +0100, Luuk wrote:
>>>>>> On 02-12-2012 05:22, Jon wrote:
>>>>>>> Where can I find an editor/..../.... for Javascript?
>>>>>>
>>>>>> Notepad.exe, or any other text-editor....
>>>>>>
>>>>>>> Where can I find an ..../compiler/.... for Javascript?
>>>>>> There is no compiler for Javascript,
>>>>> That is an oversight in the IT world.
>>>> Strictly speaking, what was stated is correct,
>>> As was my statement.
>> Most certainly not.
> 
> Then it should be easy for you to link to a program that converts HTML
> documents with forms and scripting into stand-alone EXE files.

No, AISB you have a misconception about what a compiler is.

>>>> because there is no "Javascript" language to begin with:
>>>> <http://PointedEars.de/es-matrix>
>>> Your link highlights in incompatibilities between script engines.
>> I am comparing the language features supported by different ECMAScript
>> implementations there.
> 
> Which is irrelevant to what I am wanting.

No, it is very relevant.  The compiler would have to be of an ECMAScript 
implementation that compiles source code to native machine code, and then 
the program will be limited to the features of that particular 
implementation, and to the features of the particular runtime environment 
provided or emulated by the executable, as opposed to a cross-browser Web 
application.

>>> A script I develop for my own use in my preferred browser may be
>>> useless in someone else's preferred browser.
>>
>> Correct.  This is why it is important to know where implementations
>> differ and where not, so that appropriate measures can be taken by the
>> Web developer.  I am currently focusing on ECMAScript implementations;
>> DOM implementations are another matter altogether (and I will probably
>> investigate them more thoroughly later).
> 
> I want it to be able to run *apart from* a browser.

Which, AISB, is not feasible.  You will have to have some kind of runtime 
environment to make use of an ECMAScript implementation.  For crying out 
loud, without a runtime environment not even basic input and output is 
possible.  Where do you think window.alert() or console.log() come from?  
Not from the programming language (although that was different in Netscape 
JavaScript, versions 1.0 to 1.3.)

>>> With web pages and javascript so prevalent,
>> There are no "web pages" and there is no "javascript".  As soon as you
>> can accept that, and stop talking like you want to sell something,
>> understanding can begin.
> 
> What am I trying to sell? Where do you read that I have a program of
> the type I seek?

You talk as if you were trying to sell me/us some Web application while 
obviously not knowing what you talking about.  You need to be strong now: 
You are preaching to the choir there as I/we do know what I/we are talking 
about.

>>> it is an oversight that there is no generally available program to
>>> "compile" the pages with *some* version of javascript
>> Different ECMAScript implementations are not versions of one imagined
>> universally implemented and uniform "javascript" language; they are
>> separate programming languages in their own right (with a common root,
>> most of which is standardized in ECMAScript).
> 
> Fine. I don't care about all the variations.
> 
> I want *one* version of javascript to debug within a browser, and then
> to turn the completed effort (form and scripting) into a stand-alone
> EXE file.

You don't get it, do you?

>> However, such a program would not be overly useful with regard to
>> browsers,
> It isn't intended to be useful with regard to browsers.
> 
> It is intended to be useful *apart from* browsers.

How so?  The runtime environment would have to be the equivalent of a 
browser, like XULRunner.

>> because ECMAScript implementations are scripting languages, which "[are]
>> programming language[s] that [are] used to manipulate, customise, and
>> automate the facilities of an existing system." (ECMAScript Language
>> Specification, 5.1 Edition, p. 2).  As such, they are primarily
>> interfacing languages, and APIs differ among browsers.  You cannot avoid
>> that; browser vendors will not let you.  And if you are honest, you would
>> not want to: this competition is *basically* a Good Thing.
> 
> What competition?

Among browser vendors.

> What I seek doesn't exist.

You are not very clear about what you seek, which might have to do with the 
fact that you do not understand the underlying technology.  And I am getting 
the impression that I am wasting my time here.

Will you *please* at least stop that mindless crossposting?  F'up2 cljs set 
*again*.

>>> Which is of no help to one who wants to convert their web page,
>>> complete with javascript, to a browser-independent EXE file.
>> Those people should learn to know what they are doing before they are
>> doing it, and then might be interested in
>> <https://developer.mozilla.org/en/docs/GRE> pp.
> One who wants to convert their web page to an EXE file doesn't want to
> *write* the program to do it, they want to *use* the program to feed
> their HTML file to a "compiler" and obtain a stand-alone EXE file with
> the desired functionality.
> 
> Creating such a program is more in the purview of those reading
> comp.lang than those in comp.lang.javascript.

Maybe in comp.lang.misc, but not in comp.programming.

>>But that has nothing to do with "web pages" (read: HTML documents) as
>>such.
> 
> Again, missing the point for the semantics.

Score adjusted.

>>> Javascript operating on forms in a web page can behave similarly to
>>> simple, or not-so-simple, spreadsheets.
>>
>> While that is partially true, you still have no clue what you are talking
>> about.  There are programming languages, and there are APIs that can be
>> used with programming languages.  That is no different with ECMAScript
>> implementations and the DOM API.
> 
> Actually, you don't seem to understand the request.

Actually, you don't seem to understand that you are way off-topic.  This is 
not the North Pole, and I/we am/are not Santa Claus for lusers.  If you are 
not smart enough to hack it yourself, or find it yourself, and are not 
willing to learn how to hack it or find it, go away.  We will both be better 
off without each another.

>>>>> 2. A 'save as" capability to write all contents, including entered
>>>>> values, to a disk file?
>>>> That capability exists already.
>>> Where?
>> In all script-capable Web browsers.
> 
> Not so.
> 
> Internet explorer does not save the values entered in this form when
> the page is save to the local disk:
> 
> http://voltaires.org/tech/eformulas.htm

A pity.  But then I never said that it would suffice to select "Save As" 
from the "File" menu, did I?  We are in comp.lang.javascript (well, most of 
us) here, after all.  Transfer of learning, please …

>>>>> I know I would like such a compiler.
>>>> I do not think you know what a compiler is or where you are posting to,
>>>> though.
>>> 
>>> I suppose the software to produce CHM ("compiled HTML") files would
>>> not meet your definition of "compiler."
>>
>> That is correct.  Those files need an executable (HTMLHelp.exe & friends)
>> to be displayed, which in turn uses a runtime library, MSHTML.dll.  In
>> short, the browser core.  That library supports JScript, Microsoft's
>> ECMAScript implementation (through JScript*.dll), and so does Internet
>> Explorer, for example, because it is based on MSHTML.dll (which is why I
>> am talking about JScript and the MSHTML DOM and not "javascript in
>> Internet Explorer"). .CHM files are not executables themselves, and HTML
>> Help certainly is not a programming language.
>>
>> <http://msdn.microsoft.com/en-
>> us/library/windows/desktop/ms524402(v=vs.85).aspx>
> 
> My purpose was to illustrate another use of the word "compile" beyond
> the narrow definition you seem to allow.

Which is irrelevant in newsgroups dealing with programming.  Here we 
understand a compiler to be a program that transforms code into another 
executable form, not merely one that compacts code.
 
>>> The "compiler" I would like for web pages with embedded javascript
>>> would be similar, but with more features.
>> Such as?
> 
> As listed in my first post.

I have no time and could not care less to re-read the whole discussion.
I have better things to do than considering your petty requests (for 
example, I might just be thinking about writing the software you are looking 
for).  I have asked you a simple question and if you are not willing to 
answer it, that is your problem and your loss.

>>> My mention of "embedded javascript" recognizes that web pages do *not*
>>> necessarily need to contain javascript. The ideas seems to be anathema
>>> to some webmasters, but it is true.
>>
>> ACK, but your argumentation is inconsistent nevertheless.  You cannot
>> have "embedded javascript" without having "javascript".
> 
> Others seem to acknowledge the existence of javascript.

There are many people in this field who do not know what they are talking 
about (but think they do).  But that is beside the point.

> Perhaps it doesn't exist in your world of narrow definitions.

Or perhaps I am one of the few who know what they are talking about.
 
> Others are able to perceive and use it just fine.

Let's eat sh*t, because a million flies can't be wrong?

-- 
PointedEars

[toc] | [prev] | [next] | [standalone]

#17426

On Mon, 03 Dec 2012 00:29:45 +0100, Thomas 'PointedEars' Lahn wrote:

>Wally W.  wrote:
>
>> On Sun, 02 Dec 2012 21:22:18 +0100, Thomas 'PointedEars' Lahn wrote:
>>>Wally W.  wrote:
>>>^^^^^^^^
>>>Please fix that.
>> 
>> Fix what?
>
>Fix your "name".  Basic politeness requires that you use your real and full 
>name (first and last suffices) as I am using mine.  That is, if I should 
>consider your postings.

As you wish.

>>>> On Sun, 02 Dec 2012 19:06:27 +0100, Thomas 'PointedEars' Lahn wrote:
>>>>> Wally W.  wrote:
>>>>>> On Sun, 02 Dec 2012 13:55:39 +0100, Luuk wrote:
>>>>>>> On 02-12-2012 05:22, Jon wrote:
>>>>>>>> Where can I find an editor/..../.... for Javascript?
>>>>>>>
>>>>>>> Notepad.exe, or any other text-editor....
>>>>>>>
>>>>>>>> Where can I find an ..../compiler/.... for Javascript?
>>>>>>> There is no compiler for Javascript,
>>>>>> That is an oversight in the IT world.
>>>>> Strictly speaking, what was stated is correct,
>>>> As was my statement.
>>> Most certainly not.
>> 
>> Then it should be easy for you to link to a program that converts HTML
>> documents with forms and scripting into stand-alone EXE files.
>
>No, AISB you have a misconception about what a compiler is.

You are fixated on a narrow definition.

>>>>> because there is no "Javascript" language to begin with:
>>>>> <http://PointedEars.de/es-matrix>
>>>> Your link highlights in incompatibilities between script engines.
>>> I am comparing the language features supported by different ECMAScript
>>> implementations there.
>> 
>> Which is irrelevant to what I am wanting.
>
>No, it is very relevant.  The compiler would have to be of an ECMAScript 
>implementation that compiles source code to native machine code, and then 
>the program will be limited to the features of that particular 
>implementation, and to the features of the particular runtime environment 
>provided or emulated by the executable, as opposed to a cross-browser Web 
>application.

Not at all.

The following are the contents of a complete HTML file. It contains
functionality in a script. It runs fine in my browser. If it doesn't
run fine in another browser, I don't want to use that browser.

<html>
<head>
<script type="text/javascript">
function test(){alert("Hello World!");}
</script>
</head>
<body>
<button text="Press here for message." type="button"
 onclick="test()">Click here for greeting.</button><br>
</body>
</html>

It is conceivable to use the exact text stream above as input to a
program that will output a stand-alone EXE file to provide equivalent
functionality.

Then, no browser is needed at all to achieve the functionality
provided above.

You may not see a need for such a "compiler," or whatever you care to
call it. That doesn't mean others would not find it to be useful.

>>>> A script I develop for my own use in my preferred browser may be
>>>> useless in someone else's preferred browser.
>>>
>>> Correct.  This is why it is important to know where implementations
>>> differ and where not, so that appropriate measures can be taken by the
>>> Web developer.  I am currently focusing on ECMAScript implementations;
>>> DOM implementations are another matter altogether (and I will probably
>>> investigate them more thoroughly later).
>> 
>> I want it to be able to run *apart from* a browser.
>
>Which, AISB, is not feasible.  

It is not convenient.

That is different from feasible.

>You will have to have some kind of runtime 
>environment to make use of an ECMAScript implementation.  

That is *one* way to do it.

>For crying out 
>loud, without a runtime environment not even basic input and output is 
>possible.  

Ridiculous.

How did I/O happen before runtime packages?

Have you programmed in assembly language?

Did you need a runtime package for I/O in assembly language?

>Where do you think window.alert() or console.log() come from?
>Not from the programming language (although that was different in Netscape 
>JavaScript, versions 1.0 to 1.3.)

Of course it is not "from the programming language" any more than
laughter comes from a spoken language. A language is a conveyance.
Nothing comes "from" a language.

>>>> With web pages and javascript so prevalent,
>>> There are no "web pages" and there is no "javascript".

Then you have your own private language.

Many people make money writing web pages and javascript.

>  As soon as you
>>> can accept that, and stop talking like you want to sell something,
>>> understanding can begin.
>> 
>> What am I trying to sell? Where do you read that I have a program of
>> the type I seek?
>
>You talk as if you were trying to sell me/us some Web application while 
>obviously not knowing what you talking about.  You need to be strong now: 
>You are preaching to the choir there as I/we do know what I/we are talking 
>about.

Apparently not as good at listening, however.

>>>> it is an oversight that there is no generally available program to
>>>> "compile" the pages with *some* version of javascript
>>> Different ECMAScript implementations are not versions of one imagined
>>> universally implemented and uniform "javascript" language; they are
>>> separate programming languages in their own right (with a common root,
>>> most of which is standardized in ECMAScript).
>> 
>> Fine. I don't care about all the variations.
>> 
>> I want *one* version of javascript to debug within a browser, and then
>> to turn the completed effort (form and scripting) into a stand-alone
>> EXE file.
>
>You don't get it, do you?

Sure. Compatibility with *everything* is not necessary if I am
composing javascript, or whatever you care to call it, for *one*
target that will use it in making a stand-alone EXE file.

>>> However, such a program would not be overly useful with regard to
>>> browsers,
>> It isn't intended to be useful with regard to browsers.
>> 
>> It is intended to be useful *apart from* browsers.
>
>How so?  The runtime environment would have to be the equivalent of a 
>browser, like XULRunner.

It would need *some* of the functionality of a browser. It would not
need to follow links, launch Flash, support the entire scope of HTML
5, etc.


>>> because ECMAScript implementations are scripting languages, which "[are]
>>> programming language[s] that [are] used to manipulate, customise, and
>>> automate the facilities of an existing system." (ECMAScript Language
>>> Specification, 5.1 Edition, p. 2).  As such, they are primarily
>>> interfacing languages, and APIs differ among browsers.  You cannot avoid
>>> that; browser vendors will not let you.  And if you are honest, you would
>>> not want to: this competition is *basically* a Good Thing.
>> 
>> What competition?
>
>Among browser vendors.

Not necessary.

Marry an HTML engine with a javascript engine (any variety of either)
and let all other browser vendors spew about how great *their* engine
is.

I won't care about *any* of the other engines when running my
stand-alone EXE file, or sharing it (and the data I entered into the
form) with others.

>> What I seek doesn't exist.
>
>You are not very clear about what you seek, which might have to do with the 
>fact that you do not understand the underlying technology.  And I am getting 
>the impression that I am wasting my time here.

I am trying to bypass the "underlying technology." There are ways to
interpret HTML and execute javascript without relying on any existing
browser vendor or software package.

It would be easier to use existing software packages to the extent
possible, maybe including the HH.EXE file (or its underlying
technology) that ships with Windows for the HTML engine.

>Will you *please* at least stop that mindless crossposting?  F'up2 cljs set 
>*again*.
>
>>>> Which is of no help to one who wants to convert their web page,
>>>> complete with javascript, to a browser-independent EXE file.
>>> Those people should learn to know what they are doing before they are
>>> doing it, and then might be interested in
>>> <https://developer.mozilla.org/en/docs/GRE> pp.
>> One who wants to convert their web page to an EXE file doesn't want to
>> *write* the program to do it, they want to *use* the program to feed
>> their HTML file to a "compiler" and obtain a stand-alone EXE file with
>> the desired functionality.
>> 
>> Creating such a program is more in the purview of those reading
>> comp.lang than those in comp.lang.javascript.
>
>Maybe in comp.lang.misc, but not in comp.programming.
>
>>>But that has nothing to do with "web pages" (read: HTML documents) as
>>>such.
>> 
>> Again, missing the point for the semantics.
>
>Score adjusted.
>
>>>> Javascript operating on forms in a web page can behave similarly to
>>>> simple, or not-so-simple, spreadsheets.
>>>
>>> While that is partially true, you still have no clue what you are talking
>>> about.  There are programming languages, and there are APIs that can be
>>> used with programming languages.  That is no different with ECMAScript
>>> implementations and the DOM API.
>> 
>> Actually, you don't seem to understand the request.
>
>Actually, you don't seem to understand that you are way off-topic.  This is 
>not the North Pole, and I/we am/are not Santa Claus for lusers.  

Who said the program needs to be free?

Someone who has an idea you can't grasp is a luser?


>If you are 
>not smart enough to hack it yourself, or find it yourself, and are not 
>willing to learn how to hack it or find it, go away.  

Most of the world is "not willing to learn how to hack it." Which is
part of the reason programmers have jobs.

>We will both be better 
>off without each another.

The OP sought a javascript compiler. I observed that the lack of a
javascript compiler is an oversight in the IT world.

That remains the case.

You took exception to the wording, missed the point, and have not
helped correct the oversight in the IT world.


>>>>>> 2. A 'save as" capability to write all contents, including entered
>>>>>> values, to a disk file?
>>>>> That capability exists already.
>>>> Where?
>>> In all script-capable Web browsers.
>> 
>> Not so.
>> 
>> Internet explorer does not save the values entered in this form when
>> the page is save to the local disk:
>> 
>> http://voltaires.org/tech/eformulas.htm
>
>A pity.  But then I never said that it would suffice to select "Save As" 
>from the "File" menu, did I?  We are in comp.lang.javascript (well, most of 
>us) here, after all.  Transfer of learning, please …

You surely implied it:
= >>> 2. A 'save as" capability to write all contents, 
= >>>including entered values, to a disk file?
= >> That capability exists already.
= > 
= > Where?
=
= In all script-capable Web browsers.

>>>>>> I know I would like such a compiler.
>>>>> I do not think you know what a compiler is or where you are posting to,
>>>>> though.
>>>> 
>>>> I suppose the software to produce CHM ("compiled HTML") files would
>>>> not meet your definition of "compiler."
>>>
>>> That is correct.  Those files need an executable (HTMLHelp.exe & friends)
>>> to be displayed, which in turn uses a runtime library, MSHTML.dll.  In
>>> short, the browser core.  That library supports JScript, Microsoft's
>>> ECMAScript implementation (through JScript*.dll), and so does Internet
>>> Explorer, for example, because it is based on MSHTML.dll (which is why I
>>> am talking about JScript and the MSHTML DOM and not "javascript in
>>> Internet Explorer"). .CHM files are not executables themselves, and HTML
>>> Help certainly is not a programming language.
>>>
>>> <http://msdn.microsoft.com/en-
>>> us/library/windows/desktop/ms524402(v=vs.85).aspx>
>> 
>> My purpose was to illustrate another use of the word "compile" beyond
>> the narrow definition you seem to allow.
>
>Which is irrelevant in newsgroups dealing with programming.  Here we 
>understand a compiler to be a program that transforms code into another 
>executable form, not merely one that compacts code.

Again, missing the point, which was in this case: communication is
greatly hindered by your insistence that *only* your interpretations
of words have any meaning.

<snip remainder of irrelevance and self-aggrandizement>

[toc] | [prev] | [next] | [standalone]

#17442

In comp.lang.javascript message <2849679.h3O7fUuJbZ@PointedEars.de>,
Mon, 3 Dec 2012 00:29:45, Thomas 'PointedEars' Lahn <PointedEars@web.de>
posted:

>Actually, you don't seem to understand that you are way off-topic.  This is
>not the North Pole, and I/we am/are not Santa Claus for lusers.  If you are
>not smart enough to hack it yourself, or find it yourself, and are not
>willing to learn how to hack it or find it, go away.  We will both be better
>off without each another.


It would be more effective if you were to go away; I often see you
invited to do that in other newsgroups.  Let other, nicer people return
to answer the questions.

If you do not like an article, just ignore it.  That is the Usenet
custom.

-- 
(c) John Stockton, nr London UK.  ???@merlyn.demon.co.uk  Turnpike v6.05  MIME.
 Web  <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
     Check boilerplate spelling -- error is a public sign of incompetence.
    Never fully trust an article from a poster who gives no full real name.

[toc] | [prev] | [next] | [standalone]

#17446

On 4/12/2012 5:30 AM, Dr J R Stockton wrote:
> In comp.lang.javascript message <2849679.h3O7fUuJbZ@PointedEars.de>,
> Mon, 3 Dec 2012 00:29:45, Thomas 'PointedEars' Lahn <PointedEars@web.de>
> posted:
>
>> Actually, you don't seem to understand that you are way off-topic.  This is
>> not the North Pole, and I/we am/are not Santa Claus for lusers.  If you are
>> not smart enough to hack it yourself, or find it yourself, and are not
>> willing to learn how to hack it or find it, go away.  We will both be better
>> off without each another.
>
>
> It would be more effective if you were to go away; I often see you
> invited to do that in other newsgroups.  Let other, nicer people return
> to answer the questions.
>
> If you do not like an article, just ignore it.  That is the Usenet
> custom.

I read your posts about PE (and his about you) and I wonder if you are 
not both actually the same person.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#17430

On Sun, 2 Dec 2012 at 21:22:18, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:
>Wally W.  wrote:

  <snip>
>But that has nothing to do with "web pages" (read: HTML documents) as such.
  <snip>

So, when a publisher uses an SGML file at some stage in producing a new
book, you insist that the book does not have pages. It's an SGML
document, or collection of documents, that customers buy.

  John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#17431

On 4/12/2012 7:18 AM, John G Harris wrote:
> On Sun, 2 Dec 2012 at 21:22:18, in comp.lang.javascript, Thomas
> 'PointedEars' Lahn wrote:
>> Wally W.  wrote:
>
>    <snip>
>> But that has nothing to do with "web pages" (read: HTML documents) as such.
>    <snip>
>
> So, when a publisher uses an SGML file at some stage in producing a new
> book, you insist that the book does not have pages. It's an SGML
> document, or collection of documents, that customers buy.

For my child a book does not have 'pages' but 'paper'.

So what are you arguing?

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#17451

On Tue, 4 Dec 2012 at 07:43:41, in comp.lang.javascript, Andrew Poulos
wrote:
>On 4/12/2012 7:18 AM, John G Harris wrote:
>> On Sun, 2 Dec 2012 at 21:22:18, in comp.lang.javascript, Thomas
>> 'PointedEars' Lahn wrote:
>>> Wally W.  wrote:
>>
>>    <snip>
>>> But that has nothing to do with "web pages" (read: HTML documents) as such.
>>    <snip>
>>
>> So, when a publisher uses an SGML file at some stage in producing a new
>> book, you insist that the book does not have pages. It's an SGML
>> document, or collection of documents, that customers buy.
>
>For my child a book does not have 'pages' but 'paper'.
>
>So what are you arguing?

Didn't you notice? Thomas says if what you are looking at is a rendering
of an HTML document then you must *not* call what you are looking at a
web page.

Likewise, if your child is looking at a paper rendering of an SGML
document you mustn't call it a 'book', it seems.

  John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#17452

On 4/12/2012 8:10 PM, John G Harris wrote:
> On Tue, 4 Dec 2012 at 07:43:41, in comp.lang.javascript, Andrew Poulos
> wrote:
>> On 4/12/2012 7:18 AM, John G Harris wrote:
>>> On Sun, 2 Dec 2012 at 21:22:18, in comp.lang.javascript, Thomas
>>> 'PointedEars' Lahn wrote:
>>>> Wally W.  wrote:
>>>
>>>     <snip>
>>>> But that has nothing to do with "web pages" (read: HTML documents) as such.
>>>     <snip>
>>>
>>> So, when a publisher uses an SGML file at some stage in producing a new
>>> book, you insist that the book does not have pages. It's an SGML
>>> document, or collection of documents, that customers buy.
>>
>> For my child a book does not have 'pages' but 'paper'.
>>
>> So what are you arguing?
>
> Didn't you notice? Thomas says if what you are looking at is a rendering
> of an HTML document then you must *not* call what you are looking at a
> web page.
>
> Likewise, if your child is looking at a paper rendering of an SGML
> document you mustn't call it a 'book', it seems.

What you are doing is often referred to as a straw man.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#17454

Andrew Poulos wrote:
> John G Harris wrote:

>> Didn't you notice? Thomas says if what you are looking at is a rendering
>> of an HTML document then you must *not* call what you are looking at a
>> web page.
>
>> Likewise, if your child is looking at a paper rendering of an SGML
>> document you mustn't call it a 'book', it seems.
>
> What you are doing is often referred to as a straw man.

And at other times called a parody.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#17456

On Tue, 4 Dec 2012 at 20:31:34, in comp.lang.javascript, Andrew Poulos 
wrote:

   <snip>
>What you are doing is often referred to as a straw man.

Only by people who don't know what a 'straw man' is.

I'm commenting on something actually written by an actual Thomas 'There 
are no "web pages"' Lahn in an actual Usenet article.

   John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#17415

Jon wrote:
> Please go to my web page and see what I'm trying to do:
> 
> http://3d-triangulation-calculator.bravehost.com/
> 
> The user enters 12 values into the Input form fields, clicks on 
> "Calculate" and the page displays the answer as 6 values in the Output 
> table.
> 
> It doesn't do that yet, but it is what I'd like it to do.
> 
> The Input values need to automatically enter into D24:F26 and I24:K24 of 
> the embedded spreadsheet.  The spreadsheet equations (long and complex) 
> calculate the solution and are automatically entered in the Output table 
> from D28:F29 on the embedded spreadsheet.
> 
> The embedded spreadsheet displayed on the page is a ZOHO spreadsheet 
> linked from its site.  Below this are two links to the same spreadsheet 
> in Excel 97 and Open Office Calc.  Below that are the actual equations 
> used in the spreadsheet calculations.
> 
> Can anyone help me put this together?  I have been told that there are 
> java script programs that already do this.  Can I adapt one for this?  
> Do I have to have the spreadsheet on the server?  I only know a little 
> Borland C++ and Microsoft Visual C++. 

I would suggest that what you are attempting
is too ambitious.  As I understand it, your
process flow is:

1.  User inputs values into HTML webpage and
     hits "Calculate".
2.  HTML form is submitted to your Web
     server (although, at the moment, you do
     not have a form).
3.  Web server enters values into ZOHO
     spreadsheet, and saves ZOHO spreadsheet.
4.  Web server converts ZOHO spreadsheet to
     an Excel spreadsheet and saves that.
5.  Web server converts ZOHO spreadsheet to
     an Open Office spreadsheet and saves
     that.
6.  Web server extracts output values from
     the spreadsheet and sends them back to
     the browser (it is not clear whether
     these would be pushed or pulled).
7.  Output values are written into HTML
     table and displayed in the webpage.

Only item 7 requires JavaScript.  Most of
the work is done by the server, and you give
no details of this.  Clearly, JavaScript is
not the panacea you seem to think it is.

One way to simplify things would be to dump
the ZOHO spreadsheet and, instead, do the
calculations in JavaScript in the browser.
This would avoid the server stuff (items 2
through 6, inclusive).

Unfortunately, you are using PageBreeze to
create your webpage, and this is producing
HTML code that is messy.  This makes item 7
more difficult than it should be.  Therefore,
you might want to also dump PageBreeze and,
instead, learn HTML.

> Is there a tutorial where I can 
> learn javascript for this application?  Where can I find an 
> editor/compiler/debugger for Javascript?

I bought JavaScript: The Definitive Guide by
David Flanagan, and found it most useful.
However, JavaScript is not the panacea you
seek.

-- 
Regards,
Martin Leese
E-mail: please@see.Web.for.e-mail.INVALID
Web: http://members.tripod.com/martin_leese/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web