Various DOM-related wrappers (Code Worth Recommending Project)

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 didn't make a time test but I think the simulation of
Array.prototype.filter will be very slow. I made a CSS selector

Considering that the use of the filter wrapper only helps IE5 and
under, it does make sense to duplicate its functionality in the gEBTN
wrapper. But that function and other JS1.6 array method wrappers are
useful for other purposes where speed is less of an issue. I think
that we should deal with those shortly.

Prototype.js focuses heavily on these sort of iterators (e.g. filter,
each, find, etc). The other code in Prototype.js uses these iterators
and this makes the library difficult to use in pieces. The
foundational code is very large and must be included just for a small
piece of higher level functionality. I want to avoid this type of
interdependence. I think that code should be able to stand on it's own
or have very few dependencies.

[snip]

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

Even though the two getEBTN wrappers use different fallbacks for IE4
it looks like they could be combined into one just like I've done here
with no real performance penalty. If some browsers had document.all
and not element.all then that would be a problem but has that ever
been the case?

That one isn't likely. It was the gEBTN inference that I wanted to
avoid. The previous discussion about this stemmed from the fact that
most libraries make similar inferences about addEventListener (which
requires three implementations: window, document and element.) It was
noted that agents do exist that support that method for elements, but
not for window.

Do you have a link to that previous discussion? If so please post it

No.

when we get to events. I didn't know such a case existed.

The source of that piece of information was Richard Cornford. The
discussion concerning splitting up addEventListener and gEBTN wrappers
was in a single thread. A search for "addEventListener" and
"getElementsByTagName" in the last two months or so should find the
posts.

I found it.

<URL: http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/9857be01265be432>

I don't think that thread particularly suggests that a gEBTN wrapper
must be split into two functions although I suppose it could be.

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

On Dec 9, 12:45 pm, 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.

I think this is the ultimate in a low tech automated system for
testing.

Sounds good to me. I have always tested manually and it is time-
consuming.

[snip]

What I'm trying to do is focus which lower level functionality goes in
first. Lower level functionality that is required by the higher level
modules should have priority. The lower level functionality
prerequisite to a particular module will necessarily be included
before or at the time the higher level module is included.

Right. I am basing my recommendations for the initial low-level
functionality based on what is used by my higher-level modules.

[snip]

I no longer think that is even possible and window.onload is the only
option.

URL:http://peter.michaux.ca/article/553

It is impossible to exactly simulate DOMContentLoaded, but that has
never been a goal of mine. I simple stopped using onload by itself
(it is used as a fallback for situations when the DOMContentLoaded
event or simulation fails to work.) In a nutshell, a timeout set at
the bottom of the page calls the listener (and this is always optional
as onload used as a fallback.) As long as a page degrades gracefully
without script, then the split second that the content is visible
without enhancement is not an issue. In cases where the layout
changes dramatically on enhancement, I add style rules to hide certain
content during the page load.

[snip]

I can't keep up on more than is going on right now. I didn't think

This automated testing suite should help that. But if only one person
is handling documentation and everybody else is adding and
scrutinizing code, then a bottleneck will always exist.

think this project would be so popular!

It will certainly fill a glaring need once the basic foundation is in
place. After that, I'm sure the popularity will increase
exponentially.

On Dec 10, 12:48 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 didn't make a time test but I think the simulation of
Array.prototype.filter will be very slow. I made a CSS selector

Considering that the use of the filter wrapper only helps IE5 and
under, it does make sense to duplicate its functionality in the gEBTN
wrapper. But that function and other JS1.6 array method wrappers are
useful for other purposes where speed is less of an issue. I think
that we should deal with those shortly.

Prototype.js focuses heavily on these sort of iterators (e.g. filter,
each, find, etc). The other code in Prototype.js uses these iterators
and this makes the library difficult to use in pieces. The

I tend to avoid using them in low-level modules for performance
reasons, but the code itself is very compact, so I do include it in my
base module. I have considered moving it to its own module, which
would only be required by those higher-level modules that use it.

foundational code is very large and must be included just for a small
piece of higher level functionality. I want to avoid this type of
interdependence. I think that code should be able to stand on it's own
or have very few dependencies.

Depends on what it does. All but a couple of my modules require the
base module. Most have no other dependencies, but the highest level
modules and widgets typically depend on two or three lower level
modules. In general, as granularity is maximized, redundancy is
minimized and dependencies increase accordingly.

On Dec 10, 1:13 am, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:

Even though the two getEBTN wrappers use different fallbacks for IE4
it looks like they could be combined into one just like I've done here
with no real performance penalty. If some browsers had document.all
and not element.all then that would be a problem but has that ever
been the case?

That one isn't likely. It was the gEBTN inference that I wanted to
avoid. The previous discussion about this stemmed from the fact that
most libraries make similar inferences about addEventListener (which
requires three implementations: window, document and element.) It was
noted that agents do exist that support that method for elements, but
not for window.

Do you have a link to that previous discussion? If so please post it

No.

when we get to events. I didn't know such a case existed.

The source of that piece of information was Richard Cornford. The
discussion concerning splitting up addEventListener and gEBTN wrappers
was in a single thread. A search for "addEventListener" and
"getElementsByTagName" in the last two months or so should find the
posts.

I found it.

URL:http://groups.google.com/group/comp....wse_frm/thread...

I don't think that thread particularly suggests that a gEBTN wrapper
must be split into two functions although I suppose it could be.

As I recall, my question was whether it would be excessively paranoid
to do so and the answer was no. As for addEventListener, it was
suggested that that would have to be done in at least two parts if one-
off testing was to be used. I ended up doing it in three parts
(element, document and window.) It didn't result in bloated code as I
used factories to generate the functions. In fact, the base module
that includes add/removeEventListener, gEBTN, gEBI, all of the feature
testing foundation previously discussed, plus iterator code and
several other low level abstractions is less then 10K minified. It
has become an arbitrary rule for me to keep all modules under 10K and
granularity requirements have tended to confirm that as a realistic
limit.

On Dec 9, 5: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

Colorful, but what does it mean?

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.

Even more colorful and even less clear.

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

What snippets?

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

Really?

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.

So far, nothing discussed has involved OOP, though it would be trivial
to add a thin OOP layer over the API functions. It would be a mistake
(often seen in currently popular JS libraries) to encapsulate
everything in objects (or a single object.)

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

Unsurprisingly, I don't follow you on that either. Are you worried
about code size? If so, then you don't understand the basic concept
of the repository, which includes multiple versions of each function,
from the simplest (and least compatible) to the more complicated LCD
approach, which can ostensibly run on anything.

the whole problem is totally artificial, because as of the end of 2007
the options are:

Which "whole problem?"

1) use document.getElementById
2) drop the sick sh** someone is using to run your script on.

The gEBI wrapper is not the only issue at hand.

Being a paranoiac it could be 3 options
1) use document.getElementById
2) use document.all if no 1)

Which adds a couple of extra lines to one version of one function.

3) drop the sick sh** someone is using to run your script on if
neither 1) nor 2)

Right. As the only other approach would be to include support for
NS4. The way the API is designed, anyone who needs such support can
augment the existing LCD wrapper to suit.

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

if (document.getElementById) {
$ = function(id){
return document.getElementById(id);
};
}

That is your code. Nobody else is advocating the use of a $
identifier.

else if (document.all) {
$ = function(id){return document.all(id);};

Though the all object is typically callable, I prefer to reference its
properties.

}
else {

That is basically what I presented as the LCD approach. You left out
the ID check though.

$ = function(id){/* undefined */};
}

This branch is nonsense. You don't create a function that does
nothing, which would break the feature detection of higher level
modules and widgets.

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

No one doesn't. For one, we aren't defining a namespace at the moment
and if we were, I doubt it would resemble that. Personally, I use
relatively flat "namespace" and that is what I recommend for any
future build processes.

Takes single string argument and returns a reference to DOM element
with specified ID.

That is correct.

No behavior specified for arguments other than string type.

No such behavior has been proposed.

If DOM element with requested ID doesn't exists then returns null
value.

Right.

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.

As noted, that would defeat the whole purpose of feature testing.

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

All proposed feature testing so far has been of the one-off variety,
so I don't understand your point.

Who wants a working program he will read it, who really wants to crash
the program he will do it no matter what.

That is another issue. You don't see any argument validation and
exception raising in anything proposed so far and I would be against
such excesses.

2) Runtime performance is the King, fall-back protection is the sh** -
as long as no security violation is involved.

Your "technical writing" is far too colorful. I don't understand half
of what you write. Judging by the other half, I don't think I am
missing out on much.

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

On Dec 10, 12:48 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 didn't make a time test but I think the simulation of
Array.prototype.filter will be very slow. I made a CSS selector

Considering that the use of the filter wrapper only helps IE5 and
under, it does make sense to duplicate its functionality in the gEBTN
wrapper. But that function and other JS1.6 array method wrappers are
useful for other purposes where speed is less of an issue. I think
that we should deal with those shortly.

Prototype.js focuses heavily on these sort of iterators (e.g. filter,
each, find, etc). The other code in Prototype.js uses these iterators
and this makes the library difficult to use in pieces. The

I tend to avoid using them in low-level modules for performance
reasons, but the code itself is very compact, so I do include it in my
base module.

That is a fair choice but very far removed from my choice. The large
base modules are one of my primary gripes with the popular JavaScript
libraries. I've watched a few project's base modules grow and it is a
slippery slope that will *definitely* slip when more than one person
wants to add functions to the base module.

I have considered moving it to its own module, which
would only be required by those higher-level modules that use it.

foundational code is very large and must be included just for a small
piece of higher level functionality. I want to avoid this type of
interdependence. I think that code should be able to stand on it's own
or have very few dependencies.

Depends on what it does. All but a couple of my modules require the
base module. Most have no other dependencies, but the highest level
modules and widgets typically depend on two or three lower level
modules. In general, as granularity is maximized, redundancy is
minimized and dependencies increase accordingly.

As granularity is increased the amount of code served to the client
that is not necessary for a given page is also increased. This is the
bloat problem that all of the popular libraries seem to have.

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

On Dec 10, 9:36 am, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:
[snip]

As granularity is increased the amount of code served to the client
that is not necessary for a given page is also increased. This is the
bloat problem that all of the popular libraries seem to have.

Do you mean when granularity is decreased? By increasing granularity,
I mean breaking the code base up into smaller morsels, thereby
reducing the downloading of unused code.

On Dec 10, 1:57 am, David Mark <dmark.cins... (AT) gmail (DOT) com> wrote:

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

I have always tested manually and it is time-consuming.

Very and especially when testing on a wide set of browsers. I think
the code in this repository should be tested on a wider set than the
following which took me days manually.

<URL: http://forkjavascript.org/welcome/browser_support>

[snip]

I can't keep up on more than is going on right now. I didn't think

This automated testing suite should help that. But if only one person
is handling documentation and everybody else is adding and
scrutinizing code, then a bottleneck will always exist.

I think some pacing is needed anyway. In just couple weeks from now we
can have a full Ajax module and that is a substantial component to any
code base.

Given what we've already discussed in the various threads, I would
like to shoot for the following for the first milestone.

* DHTML
setOpacity
* DOM queries
getEBI
getEBTN
getEBCN (getElementsByClassName)
getEBCS (getElementsByCSSSelector) (a very simple one)
* Ajax
form serialization
XHR
* automated testing
* parsable documentation

We will need to have threads on Ajax and documentation over the next
while when the current threads have died down.

That is sufficient for the first round and enough to reflect on how
the process is going and if things need to be changed.

After that I will certainly make my own build process and start using
the code where I can in my own work.

think this project would be so popular!

It will certainly fill a glaring need once the basic foundation is in
place.

I hope so!

I have already learned enough to justify my time invested.

After that, I'm sure the popularity will increase
exponentially.

I'm not so concerned with that and that requires marketing which I
learned I am not interested in doing.

I'm interested to see if "Code Worth Recommending" is deemed to be
code worth recommending by many comp.lang.javascript contributors.

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

On Dec 10, 2:22 am, David Mark <dmark.cins... (AT) gmail (DOT) com> wrote:

On Dec 10, 1:13 am, Peter Michaux <petermich... (AT) gmail (DOT) com> wrote:



Even though the two getEBTN wrappers use different fallbacks for IE4
it looks like they could be combined into one just like I've done here
with no real performance penalty. If some browsers had document.all
and not element.all then that would be a problem but has that ever
been the case?

That one isn't likely. It was the gEBTN inference that I wanted to
avoid. The previous discussion about this stemmed from the fact that
most libraries make similar inferences about addEventListener (which
requires three implementations: window, document and element.) It was
noted that agents do exist that support that method for elements, but
not for window.

Do you have a link to that previous discussion? If so please post it

No.

when we get to events. I didn't know such a case existed.

The source of that piece of information was Richard Cornford. The
discussion concerning splitting up addEventListener and gEBTN wrappers
was in a single thread. A search for "addEventListener" and
"getElementsByTagName" in the last two months or so should find the
posts.

I found it.

URL:http://groups.google.com/group/comp....wse_frm/thread...

I don't think that thread particularly suggests that a gEBTN wrapper
must be split into two functions although I suppose it could be.

As I recall, my question was whether it would be excessively paranoid

So you recognized it was at least moderately paranoid ;-)

to do so and the answer was no. As for addEventListener, it was
suggested that that would have to be done in at least two parts if one-
off testing was to be used. I ended up doing it in three parts
(element, document and window.) It didn't result in bloated code as I
used factories to generate the functions. In fact, the base module
that includes add/removeEventListener, gEBTN, gEBI, all of the feature
testing foundation previously discussed, plus iterator code and
several other low level abstractions is less then 10K minified. It
has become an arbitrary rule for me to keep all modules under 10K and
granularity requirements have tended to confirm that as a realistic
limit.

I try to keep all source files under 1K. Programmers have a very
difficult time agreeing on granularity.

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