Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > [announcement] ISKEET library 0.0.2

Reply
Thread Tools

[announcement] ISKEET library 0.0.2

 
 
Richard Cornford
Guest
Posts: n/a
 
      01-19-2004
"Ekkehard Morgenstern" <(E-Mail Removed)> wrote in
message news:buf1bs$jeh$(E-Mail Removed)...
<snip>
>>>Only things not supported in DOM are passed to the
>>>compatibility layer, in the ISKEET_CompatEncap class.

>>
>>In practice it is the things that the code believes not to be
>>supported that are being passed to the ISKEET_CompatEncap code,
>>without regard for whether the browser in use supports them or
>>not, at least beyond asking implementation.hasFeature if a
>>particular set of DOM standards are fully implemented. And as
>>you have noticed 98% implementation of the HTML DOM Level 2
>>interfaces does not justify having - hasFeature - return true
>>for "HTML", "2.0".

>
>Yeah, I know Opera 7 and IE 6 have partial DOM support.


And if you insist on using implementation.hasFeature to verify their
support you will be declining the opportunity to exploit the features
that those browsers do support.

>If I do feature test for every individual feature, ISKEET will
>get too big.


Which is exactly the problem with the API library concept that I
described. If you insist on encapsulating the interface in one or two
big objects then the code needed to properly exploit the available
features of the browsers and provide suitable notification of their
unavailability will always render an API library that attempts anything
beyond the trivial too bulky for practical use. Forcing pages that only
need a tiny fraction of the features provided to download and initialise
a substantial piece of code, most of which they could happily do
without.

<snip>
>>>Unfortunately, DOM isn't even implemented the same across browsers.

>>
>>At least they are all moving in the same direction and it never
>>will be the same.

>
>Someday, it will. Because it'll slow down feature usage until
>standard implementation is complete.


The W3C DOM, even if fully implemented by everyone, is only a small part
of the scriptable aspects of web browsers and there will always be
features supported by some browsers but not all, and clients will want
to exploit those features where available. And it will always continue
to be the case that desktop browsers will have more of those features
than embedded and PDA browsers.

>There's already XHTML 2.0 and DOM 3.0 in the make, I wonder
>when we'll ever get to see this implemented.


And in the mean-while there may be DOM 4 and 5 and so on.

<snip>
>That standards begin to work after a while has been proven
>by C and C++.

<snip>
>And the same will happen to web programming.


Even when (and if) everyone adheres to the existing published standards
there will still be non-standard features being introduced and used and
later there will be new standards attempting to formalise the best of
those non-standard features.

The only standard that is important for browser scripting is ECMA 262
(and maybe 327) because given consistent language support the
inconsistencies of the object model being scripted can be coped with.

<snip>
>>But why just those 3?

>
>Because I don't have proper environments to test other browsers.
>
>I don't claim my library or website is compatible with something
>when I have not seen it myself.
>
>>That isn't really a problem, unless you want to make decisions about

haw
>>a script is going to act based on inferences instead of direct

testing.
>
>... which is suggested by the W3 consortium ...
>
>In the DOM standard specifications, hasFeature() is declared
>to be the means to find out about feature support.


But making decisions based on hasFeature means not using various parts
of the DOM specs at all until they are fully implemented. That might be
necessary with other languages like Java but JavaScript is more flexible
and can take advantage of what actually exists rather than waiting for
some formal declaration of completeness in a DOM implementation. A good
thing too as there aren't many complete implementations around.

>Just another thing that cannot be relied upon for existing
>implementations. That's really sad, but I'm convinced that'll
>change in the future.


You can be as optimistic as you like but nobody is currently working in
the future. How many clients are going to pay for: "It doesn't do much
now but when the web browsers conform to the standard it will be
spectacular".

<snip>
>>And if there is no fall-back method to implement in
>>CompatEncap? In that case the programmer needs to know.

>
>Up to now, there's always a fallback.


Up to now you have only tested on, at best, a couple of versions of 3
web browsers and you haven't attempted to implement more than half a
dozen features. With the possible exception of standard form validation
code in (exclusively) HTML documents there are no browser features that
are universally supported.

>I don't use any feature without testing for its actual presence,


Yes you do (even in the 0.0.5 code).

<snip>
>>is being scripted and it is the web browsers environment
>>that renders abstract libraries inappropriate.

>
>That's not true. ISKEET proves it and will do so even more in
>the future.


When did implementing an inappropriate technique prove it appropriate?

>>... . Code does not have to be wrapped up in a
>>couple of objects to be easily re-usable.

>
>Copy-and-paste programming problems start when you want to
>change something.
>
>Imagine a script of yours that you've used by copy-and-paste in
>a couple hundred web pages,


So that's one external JS file then.

>and then you find out that you've overlooked some
>browser-specifics that you didn't know about before.


Generally well designed, implemented and tested feature detection based
scripts are extremely resilient to unexpected browser-specific problems.
But in the event, I edit the one external JS file.

>>You keep saying that but you are yet to demonstrate that
>>it is actually the case.


>read the ISKEET manual or some of the other posts here, I just
>posted a detailed reply to someone, don't wanna repeat it
>umpteen times.


I read the manual and the note in the code. Neither state what the
problem is, they just assert that there is a problem, as do all of your
other replies in this thread. But asserting that there is a problem is
not the same as demonstrating that there is a problem. Your belief that
you have seen a problem in your code does not help as your code is
derived from a series of convoluted assumptions and is as likely to be
introducing the error that you are attributing to Opera as it is to be
suffering from it. Demonstrate the problem in isolation and you have a
point, repeatedly assert that there is a problem that you cannot isolate
and you will not be taken seriously.

>>>which I provided a workaround for. So all my pages using ISKEET
>>>0.0.4 are working now unchanged on Opera 7.

>>
>>So you changed your code and now it works "unchanged"?

>
>I modified the library and didn't have to change one iota on
>the actual web page. That's what encapsulation and abstraction
>is all about. Update the library -- done!


The encapsulation and the abstraction are not the problem with the
concept. The problem comes with the attempt to wrap the whole thing up
in a couple of large objects to provide an API for the entire browser
DOM.

Small components providing an abstract interface to particular aspects
of a browser's DOM are entirely sensible. For example, a frequent
requirement that would need to be handled differently of various
browsers might be the need to acquire the amount by which a page was
scrolled. The following function encapsulates the required testing and
returns an object that provides a common interface to the desired
information:-

var getPageScroll = (function(){
var global = this;
var notSetUp = true;
var readScroll = {scrollLeft:NaN,scrollTop:NaN};
var readScrollX = 'scrollLeft';
var readScrollY = 'scrollTop';
var interface = {
getScrollX:function(){
return readScroll[readScrollX];
},
getScrollY:function(){
return readScroll[readScrollY];
}
};
function compatModeTest(obj){
if((document.compatMode)&&
(document.compatMode == 'CSS1Compat')&&
(document.documentElement)&&
(typeof document.documentElement[readScrollX] == 'number')){
return document.documentElement;
}else if((document.body)&&
(typeof document.body[readScrollX] == 'number')){
return document.body;
}else{
return obj;
}
}
function setUp(){
if(typeof global.pageXOffset == 'number'){
readScroll = global;
readScrollY = 'pageYOffset';
readScrollX = 'pageXOffset';
}else{
readScroll = compatModeTest(readScroll);
}
notSetUp = false;
}
return (function(){
if(notSetUp){
setUp();
}
return interface;
});
})(); //Only call getPageScroll after opening BODY tag has been parsed.

// USE:

var commonInterface = getPageScroll();
//Keep the interface reference for repeated use.
var xScroll = commonInterface.getScrollX();
var yScroll = commonInterface.getScrollY();
if(!isNaN(xScroll)){
// scroll values good!
}

Notice the absence of any interest in the type or version of the browser
and the well-defined behaviour (returning NaN, which is testable) in the
face of a failure of the browser to provide any of the scroll value
retrieval mechanisms.

Other versions might include the viewPort or document dimensions in the
interface. The choice of which to use would depend entirely on the
information that was required and the code is totally re-usable. But
when the functionality provided is not required the function is just not
included in the JS file (obviously anyone wanting to use such code still
needs to observe interdependencies, such as a element positioning
interface needing access to this interface in order to do its task, but
appropriate comments serve as sufficient reminder, or speed the
resolution of errors of omission).

Any sufficiently large collection of similar functionality encapsulating
code might be considered a library. Though it would be used by cutting
and pasting only the parts required and so completely avoid burdening
the pages that used the JS file with the download of code that they were
not going to use.

Richard.


 
Reply With Quote
 
 
 
 
Ekkehard Morgenstern
Guest
Posts: n/a
 
      01-19-2004

"Richard Cornford" <(E-Mail Removed)> wrote:
> >In the face of normative efforts by the W3 consortium, I guess
> >I can use hasFeature() tests to reveal the amount of DOM support
> >present in an implementation.

>
> Only within the significant restriction imposed on the hasFeature method
> by the W3C.


which would be??

please point me to the location in the DOM 2.0 standard specification
which explains the restriction you're talking about, because I can't
find any.

> things in your code (including that non-ECMA EventListener interface
> object).


It is perfectly valid in ECMAScript to use an object or array as
associative storage. Point me to the text in the ECMA 262 standard
specification where it is stated that it is not allowed. I couldn't
find anything pertaining to interfaces in it.

Hence, the interface code works with Netscape/Mozilla.

Netscape invented ECMAScript.

But I see the need for a correction of the code, after seeing your
example in another branch of this thread.

> - which is using the presence of window.addEventListener to make
> decisions about the use of event listeners. That is against the DOM
> specs as none of the W3C (HTML related) DOM specs defines any aspects of
> the global object and so a fully conforming browser has no reason for
> having an addEventListener property on the window object. And in
> practice Opera 7 supports addEventListener on every element that the DOM
> specs require but not the window object and so you deny Opera 7 the
> opportunity to exploit this very useful built-in functionality.


I will improve the DOM support in the library in due time, as for now,
on Opera, classic event handling will be used.

(it doesn't accept my interface implementation and hence I have to work
on that to make it more compatible with such browsers)


 
Reply With Quote
 
 
 
 
Richard Cornford
Guest
Posts: n/a
 
      01-19-2004
"Ekkehard Morgenstern" <(E-Mail Removed)> wrote in
message news:bugms6$kn7$(E-Mail Removed)...
>"Richard Cornford" <(E-Mail Removed)> wrote:
>>>In the face of normative efforts by the W3 consortium,
>>>I guess I can use hasFeature() tests to reveal the amount
>>>of DOM support present in an implementation.

>>
>>Only within the significant restriction imposed on the
>>hasFeature method by the W3C.

>
>which would be??
>
>please point me to the location in the DOM 2.0 standard
>specification which explains the restriction you're talking
>about, because I can't find any.


The restriction is that hasFeature is only allowed to report true if the
relevant part of the DOM is fully implemented. When there are so few
complete implementations about that doesn't make it an effective way of
matching browser support for any feature with code that wishes to use it
because for the majority of features in isolation it will report false
negatives.

>>things in your code (including that non-ECMA EventListener
>>interface object).

>
>It is perfectly valid in ECMAScript to use an object or
>array as associative storage. Point me to the text in the
>ECMA 262 standard specification where it is stated that it
>is not allowed. I couldn't find anything pertaining to
>interfaces in it.


It has nothing to do with the capabilities of ECMA objects, your
EventListenre is non-ECMA because it does not conform with the ECMA
Language Binding specification for the EventListener interface. Instead
it conformed with the Java language binding.

>Hence, the interface code works with Netscape/Mozilla.


No hence about it. I would in fact be unexpected for a DOM
implementation intended for use with ECMA script to accept an object
constructed to conform to the Java binding and the fact that Mozilla
does is probably only a coincidence resulting from an implementation
detail. It certainly would be misguided to expect any other DOM events
implementation to function with anything but the ECMA version of
EventListener.

A nice thing about ECMA functions is that they are entirely capable of
simultaneously implementing both the ECMA EventListener definition and
the Java one:-

funcRef.handleEvent = funcRef;

But I doubt that it would be worth the effort (and it would make the -
this - reference unusable within the function as it would mean different
things depending on whether the function was called as a method of
itself or as a method of the element to which it is attached).

>Netscape invented ECMAScript.


?

<snip>
>I will improve the DOM support in the library in due time, as
>for now, on Opera, classic event handling will be used.
>
>(it doesn't accept my interface implementation and hence I have
>to work on that to make it more compatible with such browsers)


Once again, as you clearly didn't read it the first time; the ECMA
Language Binding defines EventListener as:-

<quote cite="http://www.w3.org/TR/2000/
REC-DOM-Level-2-Events-20001113/ecma-script-binding.html">
Object EventListener
This is an ECMAScript function reference. This method has
no return value. The parameter is a Event object.
</quote>

If you implement EventListener as a (non-function) object with a -
handleEvent - property you are not following the ECMA Script binding and
should have no expectation of the result working in DOM events
implementing web browses scripted with ECMA Script.

The correct ECMA implementation is to pass the addEventListener (and
related) method a reference to the function object that is to be
executed when the event happens. That is, the function _is_ the
EventListener interface in ECMA Script.

Richard.


 
Reply With Quote
 
Michael Winter
Guest
Posts: n/a
 
      01-19-2004
On Mon, 19 Jan 2004 14:34:03 +0100, Ekkehard Morgenstern
<(E-Mail Removed)> wrote:

> Netscape invented ECMAScript.


Incorrect. Netscape invented JavaScript.

ECMAScript "is based on several originating technologies, the most well
known being JavaScript (Netscape) and JScript (Microsoft)." (ECMA-262,
Brief History)

Mike

--
Michael Winter
http://www.velocityreviews.com/forums/(E-Mail Removed)d (replace ".invalid" with ".uk" to reply)
 
Reply With Quote
 
Ekkehard Morgenstern
Guest
Posts: n/a
 
      01-19-2004

"Richard Cornford" <(E-Mail Removed)> wrote:
> This is an ECMAScript function reference. This method has
> no return value. The parameter is a Event object.
>
> If you implement EventListener as a (non-function) object with a -
> handleEvent - property you are not following the ECMA Script binding and
> should have no expectation of the result working in DOM events
> implementing web browses scripted with ECMA Script.


The whole stuff has nothing to do with the ECMA standard,
it has something to do with the DOM specification. You should be
more clear about such things to avoid misunderstandings.

But yeah, I looked it up in the DOM implementation reference for
2.0 Event objects, and yeah, you're right, and I have to correct
my implementation to match that.

However, it worked with neither method with Opera (I tried both).


 
Reply With Quote
 
Ekkehard Morgenstern
Guest
Posts: n/a
 
      01-19-2004

"Michael Winter" <(E-Mail Removed)> wrote:
> Netscape invented JavaScript.


Yes, and then passed it to ECMA for standardization.

 
Reply With Quote
 
Michael Winter
Guest
Posts: n/a
 
      01-19-2004
On Mon, 19 Jan 2004 21:36:25 +0100, Ekkehard Morgenstern
<(E-Mail Removed)> wrote:

> "Michael Winter" <(E-Mail Removed)> wrote:
>> Netscape invented JavaScript.

>
> Yes, and then passed it to ECMA for standardization.


You didn't quote the important part of my quote. That was:

ECMAScript "is based on several originating technologies, the most well
known being JavaScript (Netscape) and JScript (Microsoft)." (ECMA-262,
Brief History)

As ECMAScript uses more than one language as its basis, it cannot be
accredited to Netscape alone, even if JavaScript is the major component.
That was my point.

Mike

--
Michael Winter
(E-Mail Removed)d (replace ".invalid" with ".uk" to reply)
 
Reply With Quote
 
Ekkehard Morgenstern
Guest
Posts: n/a
 
      01-19-2004

"Michael Winter" <(E-Mail Removed)> wrote:
> You didn't quote the important part of my quote. That was:
>
> ECMAScript "is based on several originating technologies, the most well
> known being JavaScript (Netscape) and JScript (Microsoft)." (ECMA-262,
> Brief History)
>
> As ECMAScript uses more than one language as its basis, it cannot be
> accredited to Netscape alone, even if JavaScript is the major component.
> That was my point.


Ok, you win!

Now, tell me how to get DOM 2 event listeners to work for Netscape/Mozilla
and Opera!

With my method,

var listener = new Array();
listener.handleEvent = Code;
element.addEventListener( eventtype, listener, false );

it works on Netscape/Mozilla, whereas

element.addEventListener( eventtype, Code, false );

doesn't. Code is guaranteed to refer to a function of the form:

function Code( Event ) {
...
}

Neither method works with Opera.

What I need is an algorithm that supports any of the HTML event types,
like "load", "mouseover" etc.

I need them on window or at least document objects as well.

Or should I replace calls supplying window or document as element
with using the body-tag element?

I'm gonna try this.


 
Reply With Quote
 
Douglas Crockford
Guest
Posts: n/a
 
      01-19-2004
> > ECMAScript "is based on several originating technologies, the most well
> > known being JavaScript (Netscape) and JScript (Microsoft)." (ECMA-262,
> > Brief History)
> >
> > As ECMAScript uses more than one language as its basis, it cannot be
> > accredited to Netscape alone, even if JavaScript is the major component.
> > That was my point.

>
> Ok, you win!


Not so fast. JavaScript was develeped by Brendan Eich as Netscape, back when
Netscape was a web browser company. Microsoft copied it, but changed the name to
JScript to avoid trademark issues with Sun, which controls Java, a different
language.

When Netscape took JavaScript to ECMA for standardization, the trademark issue
came up again, and again the name was changed, this time to ECMAScript. Three
names. One language. This led to JavaScript becoming the world's most
misunderstood programming language. If Netscape had called it LiveScript, as
originally planned, the trademark issue would not have been so difficult, and
things would have been less confusing.

http://www.ecmascript.org/

 
Reply With Quote
 
Michael Winter
Guest
Posts: n/a
 
      01-19-2004
On Mon, 19 Jan 2004 14:55:22 -0800, Douglas Crockford <(E-Mail Removed)>
wrote:

> Not so fast. JavaScript was develeped by Brendan Eich as Netscape, back
> when Netscape was a web browser company. Microsoft copied it, but
> changed the name to JScript to avoid trademark issues with Sun, which
> controls Java, a different language.
>
> When Netscape took JavaScript to ECMA for standardization, the trademark
> issue came up again, and again the name was changed, this time to
> ECMAScript. Three names. One language. This led to JavaScript becoming
> the world's most misunderstood programming language. If Netscape had
> called it LiveScript, as originally planned, the trademark issue would
> not have been so difficult, and things would have been less confusing.


I'm not sure now whether I should eat humble pie, be forgiven for ECMA's
misleading description of the origins of ECMAScript, or be happy that I'm
correct to some extent.

If it's the former, my apologies to Mr Morgenstern.

Mike

--
Michael Winter
(E-Mail Removed)d (replace ".invalid" with ".uk" to reply)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Dynamic Library or Static Library under Linux gouqizi.lvcha@gmail.com C++ 6 05-10-2005 03:16 PM
Re: Difference between Web Control Library and Class Library Alan Ferrandiz [MCT] ASP .Net 0 09-11-2004 01:51 PM
Re: Difference between Web Control Library and Class Library Mythran ASP .Net 0 08-24-2004 05:53 PM
[announcement] ISKEET library 0.0.5 Ekkehard Morgenstern Javascript 0 01-19-2004 12:30 AM
Library in library... Sweep C++ 1 12-09-2003 04:12 AM



Advertisments