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

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

Matt's DOM Utils (Utils): Alpha Release

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

Contents

  Matt's DOM Utils (Utils): Alpha Release Matt McDonald <matt@fortybelow.ca> - 2012-06-06 21:53 -0600
    Re: Matt's DOM Utils (Utils): Alpha Release Andrew Poulos <ap_prog@hotmail.com> - 2012-06-07 14:14 +1000
      Re: Matt's DOM Utils (Utils): Alpha Release Matt McDonald <matt@fortybelow.ca> - 2012-06-09 17:36 -0600

#14378 — Matt's DOM Utils (Utils): Alpha Release

Early last year, I stumbled onto this newsgroup after an
exhaustive search for anti-jQuery resources. While that may be
counter-productive to the purpose of this newsgroup, I have
a great deal of gratitude to extend. Over the passing months,
I spent a substantial amount of time reading discussion of
JavaScript libraries (from David Mark, Richard Cornford,
Thomas Lahn, Garrett Smith et al.). The elucidation of varying
topics has yielded a vast amount of knowledge both in JavaScript
and browser scripting. As a corollary, many people I interact
with online now assert me to be a "dinosaur" or a lunatic
because I test (and write working code for) old-to-ancient
browsers.

I would therefore like to present an Alpha release of my pet
project: a DOM library colloquially named "Utils"[0].

*Utils* takes a great amount of influence from David Mark's
"My Library". However, I've deviated towards focusing on
advanced document tree traversal, particularly recursion.
I've also written a larger "core" than *My Library*, which is
designed to mostly wrap the DOM Core API with some exceptions.
I have confined myself to a stringent programming style to
enhance both the clarity and the cleanliness of the source
code. The browser compatibility of *Utils* is wide, but
not quite that of *My Library*. I remain a hair's breadth
from full support of IE 5, and two stumbling blocks from
a proper test of IE 4.

A fair amount of developers complain about complex traversal
(usually an equally complex "selector" is prescribed). With
the traverse module I've created, complex traversal is as
simple as providing an entry point (context) and a callback.
Non-falsey results are collected (with `true` returning the
passed node-like object) into a linear array. There are also
utilities for getting/setting text, tree retrieval and
array-like object traversal.

Utils also contains a classes module which provides
`Element::classList`-like utilities with some additional
features. The algorithms used for class token parsing are
derived from the HTML 5 specification[1], but fork to the
`classList` object if supported.

The final module I've created is a comprehensive selection
wrapper. All (known) major selection methods are supported along
with a large percentage of known `HTMLCollection`s. There is no
selector "engine"; only `NodeSelector::querySelector` and
`NodeSelector::querySelectorAll` are covered.

No attempts are made to "normalize" results, which has led to a
smaller file size. I believe this to be a major problem with
jQuery and other APIs that have attempted to ape it. Therefore,
the abstraction layer is small, which should help dissipate
the fog around the DOM that so many implicitly speak of.

In conclusion, I seek advice for a fair amount of aspects so
I can provide an attractive beta release. Those aspects
would include:

* API design;
* documentation quality (inline and HTML);
* feature requests;
* (in)formal code reviews;
* web site critiques.

Any advice will be taken with humility and gratitude, as I
owe many of you significantly.

[0]: http://www.fortybelow.ca/projects/JavaScript/Utils/
[1]: http://www.whatwg.org/specs/web-apps/current-work/
multipage/common-microsyntaxes.html#space-separated-tokens

-- 
Matt McDonald: Web/Flash Developer; Edmonton, Alberta, Canada

[toc] | [next] | [standalone]

#14379

On 7/06/2012 1:53 PM, Matt McDonald wrote:
> Early last year, I stumbled onto this newsgroup after an
> exhaustive search for anti-jQuery resources. While that may be
> counter-productive to the purpose of this newsgroup, I have
> a great deal of gratitude to extend. Over the passing months,
> I spent a substantial amount of time reading discussion of
> JavaScript libraries (from David Mark, Richard Cornford,
> Thomas Lahn, Garrett Smith et al.). The elucidation of varying
> topics has yielded a vast amount of knowledge both in JavaScript
> and browser scripting. As a corollary, many people I interact
> with online now assert me to be a "dinosaur" or a lunatic
> because I test (and write working code for) old-to-ancient
> browsers.
>
> I would therefore like to present an Alpha release of my pet
> project: a DOM library colloquially named "Utils"[0].

I haven't even started testing it yet and besides wanting to 
congratulate you on the effort (given how much heat library writers can 
get) I want to make a comment on the documentation. I like having an 
example with each method so I'm sure how its meant to be called.

Andrew Poulos

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

#14428

On 12-06-06 10:14 PM, Andrew Poulos wrote:
> I want to make a comment on the documentation. I like having an
> example with each method so I'm sure how its meant to be called.

Understood. The problem with this idea is that each public
property will require its own page to expound upon its
purpose. When a project is sufficiently large (PHP), one page
per public property *with comments* works. In other cases
(jQuery), it bogs down the project.

My goal with the documentation for *Utils* is to make
each page (the entire project site, really) mobile-friendly.
Adding an example to each public property would surely
encumber the documentation. Currently, only public properties
that form the "dynamic interface" have examples (as part
of a warning).

However, I am working on a HOWTO section which will provide
in-depth tutorials and information; more will come after the
beta release. I'm lucky that I have so much free time on
my hands because they're exhausting.

One implicit purpose of *Utils* is to encourage one to
learn while interacting with it; too many DOM libraries
coddle developers. The expected parameter types are
intentionally vague to boost flexibility. When an
"array-like object" is specified, it means that anything
that passes `Utils.is.arrayLike` gets used (examples of
"false positives" would include Text nodes and String
objects). I even link "foreign" types to their corresponding
entries in the Glossary page. Moreover, the code itself
contains an exhaustive amount of documentation. Every
single function is documented.

I don't put on a sorcerer's hat to turn
`getElementsByTagName("*")` into a dove. Nor do I defer
to `document.all` like David Mark does. I just wrap the method,
then check the parameters and expect one to learn right
from wrong. That's the only way that developers are going to
improve. Half a decade of coddling hasn't helped.

-- 
Matt McDonald: Web/Flash Developer; Edmonton, Alberta, Canada

[toc] | [prev] | [standalone]

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

csiph-web