Object models (OMs) are not part of the ECMAScript language: they
are provided by the host to allow javascript (or other scripting
language) to communicate with the host. An object model may allow
javascript to access a file system, or control a nuclear power
station. The most commonly used object models via javascript are
provided by Active Server Pages, Server Side javascript, and the
Windows Script Host. The most common of all is the
Document Object Model (DOM) provided by web browsers. Other
document types such as SVG also define scriptable DOMs, mostly as
extensions of the W3C Core DOM specification designed for use
with XML documents.
--
Postings such as this are automatically sent once a day. Their
goal is to answer repeated questions, and to offer the content to
the community for continuous evaluation/improvement. The complete
comp.lang.javascript FAQ is at http://jibbering.com/faq/index.html.
The FAQ workers are a group of volunteers. The sendings of these
daily posts are proficiently hosted by http://www.pair.com.
^^^^^^^^ False, that's not true ^^^^^^^^^
> The most common of all is the
> Document Object Model (DOM) provided by web browsers.
That's the correct answer ^^^^^^^
> Other
> document types such as SVG also define scriptable DOMs, mostly as
> extensions of the W3C Core DOM specification designed for use
> with XML documents.
Why not explain it a bit more, for example:
JavaScript by itself lacks any input/output means. To provide input/
output means to a JavaScript program, access/interaction to/with the
hosting environment is required: the run-time environment must present
an API in the form of methods/properties of host-provided object(s).
For example, input/output means in a browser are provided to
JavaScript by the W3C Document Object Model, as methods and properties
of the (global) "window" object. Outside of the browser(s), other
applications of JavaScript provide different objects for that purpose,
for example the "WScript" root object for scripting Windows hosts,
"MacOS" for MacOS OSAX JavaScript scripting, "widget" for scripting
widgets in the OSX's DashBoard, "app" "doc" "util" etc. when scripting
Adobe Acrobat documents, etc.
?
--
Jorge.
I agree with your intent on this one.
The term "object models" is uncommon on this list. Eric Evans' "Domain
Driven Design" or the group "comp.object" would be excellent resources
for studying object modeling. Although both are excellent resources, it
seems off topic and not an answer to a javascript FAQ.
The term "Host object" comes up frequently in answers to questions or
problems that arise from those who are less aware of the difference
between Host object and Native object (e.g. code review: "you are
modifying a host object").
>> The most common of all is the
>> Document Object Model (DOM) provided by web browsers.
>
> That's the correct answer ^^^^^^^
>
It is a more pertinent answer.
The important thing is to distinguish between ECMAScript Native and Host
object.
To avoid discussion of domain modeling, it might be better to have:
Q: What is a Host object?
A: Explains about ECMAScript and host objects in DOM, also brief mention
of other environments ASP, WSH, etc.
>> Other
>> document types such as SVG also define scriptable DOMs, mostly as
>> extensions of the W3C Core DOM specification designed for use
>> with XML documents.
>
> Why not explain it a bit more, for example:
>
> JavaScript by itself lacks any input/output means. To provide input/
> output means to a JavaScript program, access/interaction to/with the
> hosting environment is required: the run-time environment must present
> an API in the form of methods/properties of host-provided object(s).
No, I/O is not at the heart of the answer.
Rough outline:
1: Explain what a Host object is. Example: w3c DOM document. Mention
WSH, [a widget user agent object], etc.
2: Describe w3c DOM:
> For example, input/output means in a browser are provided to
> JavaScript by the W3C Document Object Model, as methods and properties
> of the (global) "window" object.
[Link to #domResources]
3: Mention browser extentions (MSIE DOM).
Outside of the browser(s), other
> applications of JavaScript provide different objects for that purpose,
> for example the "WScript" root object for scripting Windows hosts,
> "MacOS" for MacOS OSAX JavaScript scripting, "widget" for scripting
> widgets in the OSX's DashBoard, "app" "doc" "util" etc. when scripting
> Adobe Acrobat documents, etc.
>
> ?
4: Mention the allowances that the ECMA-262 spec grants Host objects
(why they are not generally trustable).
[Link to #ecmaResources]
Garrett
--
comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >
I'd say that yes, because, what's the use of a program that you can't
pass no input to, and/or provides no output ?
What's it, in your opinion, that's "at the heart of the answer" ?
--
Jorge.
To distinguish between ECMAScript Native and Host object.
I thought that was really clear in the rough outline I wrote.
Did you not understand my meaning or do you disagree or what?
Fine. I'd make it clear that
1.- host-provided-objects such as those in the W3C DOM are *not* part
of JavaScript.
2.- JavaScript is *useless* without the addition of at least one such
(host-provided) object.
3.- Because JavaScript itself lacks any input/output means, a host
object must provide it.
4.- Native objects are OTOH, a part of JavaScript and the ECMAScript
specification, unlike host-objects.
> I thought that was really clear in the rough outline I wrote.
>
> Did you not understand my meaning or do you disagree or what?
Maybe I didn't understand. But I disagree with the sentence "I/O is
not at the heart of the answer". It's the main reason for a DOM. The
DOM is JS's I/O API in a browser: it's what provides the input and
what allows to output.
--
Jorge.
Maybe "Native (and built-in) objects" ?
--
Jorge.
<snip>
>The term "object models" is uncommon on this list.
<snip>
Which "list" ?
John
--
John Harris
An Object Model (OM) is provided by a host system to allow JavaScript
(or another language) to communicate with its host; the ECMAScript
language does not include an OM.
An OM may allow JavaScript to access a document, a file system, or
control a nuclear power station. // QUERY : is the latter legal?
The most commonly used OM of all may be the Document Object Model (DOM)
provided in Web browsers. // web browsers are arachnids.
Other object models commonly used with JavaScript are those provided by
Active Server Pages, Server Side JavaScript, and Windows Script Host.
Other document types, such as SVG, also define scriptable DOMs - mostly
as extensions of the W3C Core DOM specification designed for use with
XML documents.
// Join paragraphs as wished.
// Expand SVG : <http://en.wikipedia.org/wiki/SVG>?
// Presumably W3C & XML are defined higher up?
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk BP7, Delphi 3 & 2006.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.bancoems.com/CompLangPascalDelphiMisc-MiniFAQ.htm> clpdmFAQ;
NOT <URL:http://support.codegear.com/newsgroups/>: news:borland.* Guidelines
Noy "may" but *must*. Must provide JS some input/output means, if not,
JS remains isolated and useless.
> The most commonly used OM of all may be the Document Object Model (DOM)
> provided in Web browsers. // web browsers are arachnids.
>
> Other object models commonly used with JavaScript are those provided by
> Active Server Pages, Server Side JavaScript, Windows Script Host.
And Adobe's Creative Suite, and Acrobat documents, and Mac OSX's
widgets, and...
--
Jorge.
No, "may" is correct, since the list given is manifestly not exhaustive.
Given a suitable OM, one allowing JavaScript to access devices as files,
JavaScript can control anything which can be controlled through a device
interface. Moreover, I don't recall ECMA making utility mandatory
rather than merely expected.
>> The most commonly used OM of all may be the Document Object Model (DOM)
>> provided in Web browsers. // web browsers are arachnids.
>>
>> Other object models commonly used with JavaScript are those provided by
>> Active Server Pages, Server Side JavaScript, Windows Script Host.
>
>And Adobe's Creative Suite, and Acrobat documents, and Mac OSX's
>widgets, and...
In English, using "other" as opposed to "the other" implies a non-
exhaustive list. But using "Some other" may make it clearer to those
whose English is weak (anyone under 40 apart from Danes, Dutch, and
Norwegians) - or changing "are" to "include"..
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Ok.
"An OM may allow JavaScript to access a document, a file system, or
control a nuclear power station", that's right.
But, as well: "An OM *must* provide JS some input/output means because
if not, JS would be isolated and that would render it useless"
Isn't it ?
> Moreover, I don't recall ECMA making utility mandatory rather than merely expected.
You must be joking...
And I'm not saying nor did I say that usefulness/utility was required
by the spec.
That's the whole idea:
(copy-pasted from the spec)
"4 Overview
This section contains a non-normative overview of the ECMAScript
language.
ECMAScript is an object-oriented programming language for performing
computations and manipulating computational objects within a host
environment. ECMAScript as defined here is not intended to be
computationally self-sufficient; indeed, there are no provisions in
this specification for input of external data or output of computed
results.
Instead, it is expected that the computational environment of an
ECMAScript program will provide not only the objects and other
facilities described in this specification but also certain
environment-specific host objects, whose description and behaviour are
beyond the scope of this specification except to indicate that they
may provide certain properties that can be accessed and certain
functions that can be called from an ECMAScript program.
A scripting language is a programming language that is used to
manipulate, customise, and automate the facilities of an existing
system. In such systems, useful functionality is already available
through a user interface, and the scripting language is a mechanism
for exposing that functionality to program control. In this way, the
existing system is said to provide a host environment of objects and
facilities, which completes the capabilities of the scripting
language."
--
Jorge.
No. Change the "must" of compulsion to the "will" of necessity.
>> Moreover, I don't recall ECMA making utility mandatory rather than merely expected.
>
>You must be joking...
>And I'm not saying nor did I say that usefulness/utility was required
>by the spec.
--
(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.
Food expiry ambiguities: <URL:http://www.merlyn.demon.co.uk/date2k-3.htm#Food>
What about "ought" ?
--
Jorge.
Too doubtful. Implies that it often does not.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
"should", then.
--
Jorge.