Various DOM-related wrappers (Code Worth Recommending Project)

On Dec 9, 10:32 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de>
wrote:

Peter Michaux wrote:
[...] David Mark [...] wrote:
[...] Peter Michaux [...] wrote:
[...] David Mark [...] wrote:
[...] Peter Michaux [...] wrote:
[...] David Mark [...] wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
Peter Michaux wrote:
[...]
There is no need to check for the existence of "document" as no
browser, NN4+ and IE4+, missing "document".
There is no need to check that document.getElementById is a callable
since there has never been a known implementation where
document.getElementById that is not callable.
If these are the guidelines for your project, to produce code that is not
interoperable and inherently unreliable, I don't want to contribute.
I somewhat agree with that sentiment,
I would say your codes says otherwise and that you agree that a line
for feature testing should be drawn somewhere.
I was talking about the issue he was referring to (gEBTN for document
vs. element.)

JFTR: I was not referring to that at all.

[...] I think I meant the following.

if (document.getElementById &&
typeof getAnElement != 'undefined' &&
getAnElement().getElementById) {

var getEBI = function(id, d) {
return (d||document).getElementById(id);
};

}

The nonsense gets worse.

I don't see what is wrong with the code above.

Since the getElementById method is specified separately for Document
and Element in the DOM2 spec,

No, it is not.

I think it is. The portion of the spec that you quote below shows it
is specified spearately in the Document and the Element interfaces.

I don't know which DOM 2 Spec you have been reading,
but the one I have been reading specifies only:

,-<http://www.w3.org/TR/DOM-Level-2-Cor...tml#i-Document
|
| [...]
| interface Document : Node {
| [...]
| // Introduced in DOM Level 2:
| Element getElementById(in DOMString elementId);
| };

,-<http://www.w3.org/TR/DOM-Level-2-Cor...l#ID-745549614
|
| [...]
| interface Element : Node {
| readonly attribute DOMString tagName;
| DOMString getAttribute(in DOMString name);
| void setAttribute(in DOMString name,
| in DOMString value)
| raises(DOMException);
| void removeAttribute(in DOMString name)
| raises(DOMException);
| Attr getAttributeNode(in DOMString name);
| Attr setAttributeNode(in Attr newAttr)
| raises(DOMException);
| Attr removeAttributeNode(in Attr oldAttr)
| raises(DOMException);
| NodeList getElementsByTagName(in DOMString name);
| // Introduced in DOM Level 2:
| DOMString getAttributeNS(in DOMString namespaceURI,
| in DOMString localName);
| // Introduced in DOM Level 2:
| void setAttributeNS(in DOMString namespaceURI,
| in DOMString qualifiedName,
| in DOMString value)
| raises(DOMException);
| // Introduced in DOM Level 2:
| void removeAttributeNS(in DOMString namespaceURI,
| in DOMString localName)
| raises(DOMException);
| // Introduced in DOM Level 2:
| Attr getAttributeNodeNS(in DOMString namespaceURI,
| in DOMString localName);
| // Introduced in DOM Level 2:
| Attr setAttributeNodeNS(in Attr newAttr)
| raises(DOMException);
| // Introduced in DOM Level 2:
| NodeList getElementsByTagNameNS(in DOMString namespaceURI,
| in DOMString localName);
| // Introduced in DOM Level 2:
| boolean hasAttribute(in DOMString name);
| // Introduced in DOM Level 2:
| boolean hasAttributeNS(in DOMString namespaceURI,
| in DOMString localName);
| };

The item on the left is the *return type* of the method, not its
(additional) owner.

a feature test for one does not assure the other is present.
A test for both is necessary if the getEBI
function is to be documented as suitable for both.

If what you stated above were the case,

I still think it is the case.

a test on an arbitrary element
object would not be sufficient. But it is not the case, so that point
is rather moot.

I don't understand what you are saying.

If the spec has getElementById in two places then it should be feature
tested in both places. An implementation may have one, the other, none
or both.

--
Peter
Code Worth Recommending Project
http://cljs.michaux.ca

On Dec 9, 1:54 pm, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:
[snip]

I don't see what is wrong with the code above.

As I had never before tried to call gEBI on anything but document
nodes, I was unsure if it was even supported on element nodes. A
quick test confirmed it is not. As is typical, "PointedEars" couldn't
be expected to just say that as such, but instead posted the DOM
phonebook. I propose that in the interest of time management, his
often indecipherable scrutiny should be ignored. He has said he won't
contribute and so far he hasn't. Worse still, he is impeding progress
by constantly confusing the issues at hand.

[Sorry for misquoting you before, it is corrected below.]

Peter Michaux wrote:

[...] Thomas 'PointedEars' Lahn [...] wrote:
Peter Michaux wrote:
[...] I think I meant the following.
if (document.getElementById
&& typeof getAnElement != 'undefined'
&& getAnElement().getElementById)
{
var getEBI = function(id, d)
{
return (d||document).getElementById(id);
};
}
The nonsense gets worse.

I don't see what is wrong with the code above.

I explained that below.

Since the getElementById method is specified separately for Document
and Element in the DOM2 spec,
No, it is not.

I think it is. The portion of the spec that you quote below shows it is
specified spearately in the Document and the Element interfaces.

It shows the exact opposite. Watch closely:

,-<http://www.w3.org/TR/DOM-Level-2-Cor...tml#i-Document
|
| [...]
| interface Document : Node {
| [...]
| // Introduced in DOM Level 2:
| Element getElementById(in DOMString elementId);
| };

[...]
The item on the left is the *return type* of the method, not its
(additional) owner.

a test on an arbitrary element object would not be sufficient. But it
is not the case, so that point is rather moot.

I don't understand what you are saying.

If the spec has getElementById in two places then it should be feature
tested in both places. An implementation may have one, the other, none or
both.

I don't know what anElement() returns, but ISTM you are drawing the false
conclusion that because one object implements the interface the passed one
also has to.


PointedEars

On Dec 9, 11:34 am, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de>
wrote:

[Sorry for misquoting you before, it is corrected below.]



Peter Michaux wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
Peter Michaux wrote:
[...] I think I meant the following.
if (document.getElementById
&& typeof getAnElement != 'undefined'
&& getAnElement().getElementById)
{
var getEBI = function(id, d)
{
return (d||document).getElementById(id);
};
}
The nonsense gets worse.

I don't see what is wrong with the code above.

I explained that below.

Since the getElementById method is specified separately for Document
and Element in the DOM2 spec,
No, it is not.

I think it is. The portion of the spec that you quote below shows it is
specified spearately in the Document and the Element interfaces.

It shows the exact opposite. Watch closely:



,-<http://www.w3.org/TR/DOM-Level-2-Cor...tml#i-Document
|
| [...]
| interface Document : Node {
| [...]
| // Introduced in DOM Level 2:
| Element getElementById(in DOMString elementId);
| };

[...]
The item on the left is the *return type* of the method, not its
(additional) owner.
a test on an arbitrary element object would not be sufficient. But it
is not the case, so that point is rather moot.

I don't understand what you are saying.

If the spec has getElementById in two places then it should be feature
tested in both places. An implementation may have one, the other, none or
both.

I don't know what anElement() returns,

Some element. In any modern browser it will return
document.documentElement

but ISTM you are drawing the false
conclusion that because one object implements the interface the passed one
also has to.

Sorry I've been reading this thread too fast. (I've actually been busy
having more fun making a testing framework for the repository.)

There is no Element getElementById in the spec. My function needs to
revert to

if (document.getElementById) {
var getEBI = function(id, d) {
return (d||document).getElementById(id);
};
}

// id is a string
// d is some optional node that implements the Document interface.

Now, what is wrong with that?

--
Peter
Code Worth Recommending Project
http://cljs.michaux.ca

On Dec 9, 11:27 am, David Mark <dmark.cins... (AT) gmail (DOT) com> wrote:

[snip]

As is typical, "PointedEars" couldn't
be expected to just say that as such, but instead posted the DOM
phonebook. I propose that in the interest of time management,

There is no time line.

his
often indecipherable scrutiny should be ignored.

I think the project must be inclusive to all participation.

He has said he won't
contribute and so far he hasn't.

I think he has. We have five and a half agreements with him so far.

Worse still, he is impeding progress
by constantly confusing the issues at hand.

I'm guilty of that too.

--
Peter
Code Worth Recommending Project
http://cljs.michaux.ca

Peter Michaux wrote:

[...] Thomas 'PointedEars' Lahn [...] wrote:
Peter Michaux wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
a test on an arbitrary element object would not be sufficient. But it
is not the case, so that point is rather moot.
I don't understand what you are saying.
If the spec has getElementById in two places then it should be feature
tested in both places. An implementation may have one, the other, none or
both.
I don't know what anElement() returns,

Some element.

Some element *object*, if that.

In any modern browser it will return document.documentElement

Which would confirm my suspicion below, though. BTW, what will it return in
any not so modern browser?

but ISTM you are drawing the false conclusion that because one object
implements the interface the passed one also has to.

[...] My function needs to revert to

if (document.getElementById) {
var getEBI = function(id, d) {
return (d||document).getElementById(id);
};
}

// id is a string
// d is some optional node that implements the Document interface.

Now, what is wrong with that?

Besides the fact that your code is still lacking the necessary feature test,
you falsely assume that, because `document.getElementById' yields a
true-value, `d.getElementById' has to be callable.


Please, trim your quotes as explained in the FAQ and FAQ Notes. The entire
part about the DOM2 Spec was irrelevant to your followup, or at least could
have been shortened to very few lines.


PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

On Dec 9, 12:42 pm, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de>
wrote:

Peter Michaux wrote:

[snip]

if (document.getElementById) {
var getEBI = function(id, d) {
return (d||document).getElementById(id);
};
}

// id is a string
// d is some optional node that implements the Document interface.

Now, what is wrong with that?

Besides the fact that your code is still lacking the necessary feature test,
you falsely assume that, because `document.getElementById' yields a
true-value, `d.getElementById' has to be callable.

Have you ever seen a host where where document.getElementById is not
callable?

If you are concerned that someone might send a "d" that is not a
document then they will have violated what will be the documentation
saying "d" must be a document.

--
Peter
Code Worth Recommending Project
http://cljs.michaux.ca

On Dec 9, 11:07 pm, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:

I think the project must be inclusive to all participation.

So far it mostly going "wild on the party" :-) as the major
participant s keep making monstrous paranoid all-in-one don't-trust-
anyone snippets of code where each snippet intended to accomplish a
single very primitive task. If the Code Worth project ever gets big
then it will be an army of soldiers where everyone carries on his
armor, food for the whole campaign, all necessary items, 200 pounds of
old family albums and beloved books. And before to ask for fire from
another solder, each one first makes a full scale fortification around
him so taking the lighter through the small hole in the wall after
triple check. Evidently the one who asked does exactly the same before
to get the lighter back: so in order of two to fire their cigars the
army has to make a stop for a day or two each time.

Such snippets may have some limited usability for bookmarklets and
thingies (inline anonymous functions for element event handlers).
God forbids to make a _library_ of all these things together. If one
at least pretending to be on OOP path then one shold start from the
basics: from the modularity. OOP is not about C out of B out of A out
of ground bottom - it is just a possible but not necessary consequence
of OOP approache. OOP is about everyone doing its own thing and this
thing only.
And what an anancastic sub is that so far? Are you trying to make the
resulting lib being able to run only on Cray clusters? First of all
the whole problem is totally artificial, because as of the end of 2007
the options are:
1) use document.getElementById
2) drop the sick sh** someone is using to run your script on.

Being a paranoiac it could be 3 options
1) use document.getElementById
2) use document.all if no 1)
3) drop the sick sh** someone is using to run your script on if
neither 1) nor 2)

So the entire - already paranoid for practical usage - code is:

if (document.getElementById) {
$ = function(id){
return document.getElementById(id);
};
}
else if (document.all) {
$ = function(id){return document.all(id);};
}
else {
$ = function(id){/* undefined */};
}

And then in Help file one writes something like:
com.something.utils.$(String id)
Takes single string argument and returns a reference to DOM element
with specified ID.
No behavior specified for arguments other than string type.
If DOM element with requested ID doesn't exists then returns null
value.
If the page contains several elements with the same ID then returns
the first element on the page going from the top with such ID.
If user agent doesn't support neither standard nor proprietary tools
for DOM element reference retrieval then returns undefined value.

Other words:
1) The main logic is moved to specification, not to runtime method.
Who wants a working program he will read it, who really wants to crash
the program he will do it no matter what.
2) Runtime performance is the King, fall-back protection is the sh** -
as long as no security violation is involved.

On Dec 9, 2:00 pm, VK <schools_r... (AT) yahoo (DOT) com> wrote:

On Dec 9, 11:07 pm, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:

I think the project must be inclusive to all participation.

So far it mostly going "wild on the party" :-) as the major
participant s keep making monstrous paranoid all-in-one don't-trust-
anyone snippets of code where each snippet intended to accomplish a
single very primitive task.

That is what foundational functions do.

I think you've missed the point. There are far bigger issues being
discussed about what things should be feature tested and what can be
assumed. Granularity of a code repository is also a major issue.

If the Code Worth project ever gets big
then it will be an army of soldiers where everyone carries on his
armor, food for the whole campaign, all necessary items, 200 pounds of
old family albums and beloved books. And before to ask for fire from
another solder, each one first makes a full scale fortification around
him so taking the lighter through the small hole in the wall after
triple check. Evidently the one who asked does exactly the same before
to get the lighter back: so in order of two to fire their cigars the
army has to make a stop for a day or two each time.

I think it would be interesting to meet you, VK.

Such snippets may have some limited usability for bookmarklets and
thingies (inline anonymous functions for element event handlers).

A big piece of code would likely use little pieces. The alternative is
one huge function.

God forbids to make a _library_ of all these things together.

The individual pieces need to be quality or the whole thing may as
well be tossed.

If one
at least pretending to be on OOP path then one shold start from the
basics: from the modularity. OOP is not about C out of B out of A out
of ground bottom - it is just a possible but not necessary consequence
of OOP approache. OOP is about everyone doing its own thing and this
thing only.

I don't think OOP comes into this.

And what an anancastic sub is that so far? Are you trying to make the
resulting lib being able to run only on Cray clusters? First of all
the whole problem is totally artificial, because as of the end of 2007
the options are:
1) use document.getElementById
2) drop the sick sh** someone is using to run your script on.

Very creative.

Being a paranoiac it could be 3 options
1) use document.getElementById
2) use document.all if no 1)
3) drop the sick sh** someone is using to run your script on if
neither 1) nor 2)

So the entire - already paranoid for practical usage - code is:

if (document.getElementById) {
$ = function(id){
return document.getElementById(id);
};
}
else if (document.all) {
$ = function(id){return document.all(id);};
}
else {
$ = function(id){/* undefined */};
}

This doesn't address the IE id/name attribute issue.

And then in Help file one writes something like:
com.something.utils.$(String id)

I think you would be the only one in favor of this API.

Takes single string argument and returns a reference to DOM element
with specified ID.
No behavior specified for arguments other than string type.
If DOM element with requested ID doesn't exists then returns null
value.
If the page contains several elements with the same ID then returns
the first element on the page going from the top with such ID.
If user agent doesn't support neither standard nor proprietary tools
for DOM element reference retrieval then returns undefined value.

Even the documentation doesn't address the IE id/name problem.

Other words:
1) The main logic is moved to specification, not to runtime method.

No one has suggested an implementation that makes the
document.getElementById and document.all tests at "runtime".

Who wants a working program he will read it, who really wants to crash
the program he will do it no matter what.
2) Runtime performance is the King, fall-back protection is the sh** -
as long as no security violation is involved.

A tangential thinker, eh?

--
Peter
Code Worth Recommending Project
http://cljs.michaux.ca

On Dec 9, 9:45 am, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:

On Dec 9, 9:13 am, David Mark <dmark.cins... (AT) gmail (DOT) com> wrote:

On Dec 9, 11:20 am, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:

On Dec 9, 4:32 am, David Mark <dmark.cins... (AT) gmail (DOT) com> wrote:

On Dec 9, 12:02 am, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:

[snip]

I realize that the task of finalizing, adding and documenting each is
a bottleneck,

Yes. I am working on an automated testing system now and that will

That's interesting. How will that work?

The interesting part is that the testing framework needs to limit how
much client side scripting is used as it is testing a client side
scripting library. This is so even very old browsers can be tested.

I'm using a series of communications between the client and server.
The server orchestrates everything with a series redirects from test
page to test page using redirects until all test pages have been run.

The client logs test assertions (pass and fail) to the server by
setting (new Image()).src since this is the oldest(?) way to
communicate with the server. There will be extremely old browsers that
can't do this and those browsers will require manual testing if they
are to be tested at all.

The only other requirement is that the browser can set
window.location.

and setTimeout.

The testing framework is in the repository now. It seems to be working
with IE5+ and NN6+. I can't figure out why it doesn't work with IE4
since that browser can do all the things needed. I didn't try NN4.
Regardless even if it only works on IE5+ and NN6+ it will save a huge
amount of time and a very sore index finger.

There is a file trunk/test/README.txt that should contain enough
information to help someone get the automatic testing going. It uses
PHP and I use Apache.

It is good enough for the time being. Now back to the features...

--
Peter
Code Worth Recommending Project
http://cljs.michaux.ca