Starting to Build a JavaScript Library

Discussion in 'Javascript' started by dhtml, Feb 16, 2008.

  1. dhtml

    dhtml Guest

    Frustrated with every other Javascript framework, I have decided to
    write something better.

    I want a Javascript library that doesn't get in the way, is easily
    extensible. Just some basic framework to build on for widgets.

    The BAD things of other libraries:
    * Weird "OOP"ish schemes
    * oversimplified interface that does more things behind the scenes
    * Kitchen Sink - too much bloat in the main library file; non-
    cohesive.
    * buggy, with superficial examples that they call "tests"
    * non-modular design
    * core library features are poor, inconsistent across browsers, and
    buggy

    And, to quote Brendan Eich:
    Too many of the JS/DHTML toolkits have the "you must use our APIs for
    everything, including how you manipulate strings" disease.

    I know what I don't want.

    Goals:
    * Minimal Framework, mainly used for AOP and OOP functionality
    * unit tested
    * AOP Event System
    * Namespacing
    * Modularity, Cohesion, Packaging based on REP
    * No browser detection

    TBD:
    * import() - dynamic script insertion? Dependency resolution?
    * Building files to modules is easier to test, but feels weird

    RIA development using javascript, I need widgets (Data Table, Rich
    Editor). Widgets need: DOM adapter functions (style, position,
    className), Event-based ajax (or "deferred" Async's), Form
    serialization, Drag 'n Drop, Animation.
    I
    JavaScript lacks "import" and "extend" which are useful for widgets. I
    use AOP cross cuts even more. I have not seen 1 library that gets
    these things right. It is very important to get this part right.

    The base component is APE.js ->
    http://dhtmlkitchen.com/ape/src/APE.js

    It is too early to be releasing the code, but I want to get some
    feedback sooner rather than later. One pair of eyes on the code isn't
    enough.

    APE, by itself does nothing. I have some tests for what it does,
    http://dhtmlkitchen.com/ape/test/tests/APE-test.html
    dhtml, Feb 16, 2008
    #1
    1. Advertising

  2. dhtml

    timothytoe Guest

    On Feb 16, 1:14 pm, dhtml <> wrote:
    > Frustrated with every other Javascript framework, I have decided to
    > write something better.
    >
    > I want a Javascript library that doesn't get in the way, is easily
    > extensible. Just some basic framework to build on for widgets.
    >
    > The BAD things of other libraries:
    > * Weird "OOP"ish schemes
    > * oversimplified interface that does more things behind the scenes
    > * Kitchen Sink - too much bloat in the main library file; non-
    > cohesive.
    > * buggy, with superficial examples that they call "tests"
    > * non-modular design
    > * core library features are poor, inconsistent across browsers, and
    > buggy
    >
    > And, to quote Brendan Eich:
    > Too many of the JS/DHTML toolkits have the "you must use our APIs for
    > everything, including how you manipulate strings" disease.
    >
    > I know what I don't want.
    >
    > Goals:
    > * Minimal Framework, mainly used for AOP and OOP functionality
    > * unit tested
    > * AOP Event System
    > * Namespacing
    > * Modularity, Cohesion, Packaging based on REP
    > * No browser detection
    >
    > TBD:
    > * import() - dynamic script insertion? Dependency resolution?
    > * Building files to modules is easier to test, but feels weird
    >
    > RIA development using javascript, I need widgets (Data Table, Rich
    > Editor). Widgets need: DOM adapter functions (style, position,
    > className), Event-based ajax (or "deferred" Async's), Form
    > serialization, Drag 'n Drop, Animation.
    > I
    > JavaScript lacks "import" and "extend" which are useful for widgets. I
    > use AOP cross cuts even more. I have not seen 1 library that gets
    > these things right. It is very important to get this part right.
    >
    > The base component is APE.js ->http://dhtmlkitchen.com/ape/src/APE.js
    >
    > It is too early to be releasing the code, but I want to get some
    > feedback sooner rather than later. One pair of eyes on the code isn't
    > enough.
    >
    > APE, by itself does nothing. I have some tests for what it does,http://dhtmlkitchen.com/ape/test/tests/APE-test.html


    It may be possible to improve the performance of your "extend" by
    using Cornford's method in this thread:

    http://groups.google.com/group/comp...5e864536?lnk=gst&q=crockford#38e8a2d75e864536
    timothytoe, Feb 16, 2008
    #2
    1. Advertising

  3. dhtml

    dhtml Guest

    On Feb 16, 1:22 pm, timothytoe <> wrote:
    > On Feb 16, 1:14 pm, dhtml <> wrote:
    >
    >
    >
    > > Frustrated with every other Javascript framework, I have decided to
    > > write something better.

    >
    > > I want a Javascript library that doesn't get in the way, is easily
    > > extensible. Just some basic framework to build on for widgets.

    >
    > > The BAD things of other libraries:
    > > * Weird "OOP"ish schemes
    > > * oversimplified interface that does more things behind the scenes
    > > * Kitchen Sink - too much bloat in the main library file; non-
    > > cohesive.
    > > * buggy, with superficial examples that they call "tests"
    > > * non-modular design
    > > * core library features are poor, inconsistent across browsers, and
    > > buggy

    >
    > > And, to quote Brendan Eich:
    > > Too many of the JS/DHTML toolkits have the "you must use our APIs for
    > > everything, including how you manipulate strings" disease.

    >
    > > I know what I don't want.

    >
    > > Goals:
    > > * Minimal Framework, mainly used for AOP and OOP functionality
    > > * unit tested
    > > * AOP Event System
    > > * Namespacing
    > > * Modularity, Cohesion, Packaging based on REP
    > > * No browser detection

    >
    > > TBD:
    > > * import() - dynamic script insertion? Dependency resolution?
    > > * Building files to modules is easier to test, but feels weird

    >
    > > RIA development using javascript, I need widgets (Data Table, Rich
    > > Editor). Widgets need: DOM adapter functions (style, position,
    > > className), Event-based ajax (or "deferred" Async's), Form
    > > serialization, Drag 'n Drop, Animation.
    > > I
    > > JavaScript lacks "import" and "extend" which are useful for widgets. I
    > > use AOP cross cuts even more. I have not seen 1 library that gets
    > > these things right. It is very important to get this part right.

    >
    > > The base component is APE.js ->http://dhtmlkitchen.com/ape/src/APE.js

    >
    > > It is too early to be releasing the code, but I want to get some
    > > feedback sooner rather than later. One pair of eyes on the code isn't
    > > enough.

    >
    > > APE, by itself does nothing. I have some tests for what it does,http://dhtmlkitchen.com/ape/test/tests/APE-test.html

    >
    > It may be possible to improve the performance of your "extend" by
    > using Cornford's method in this thread:
    >
    > http://groups.google.com/group/comp.lang.javascript/browse_thread/thr...


    Makes sense. Did that.
    dhtml, Feb 16, 2008
    #3
  4. On Feb 16, 1:14 pm, dhtml <> wrote:
    > Frustrated with every other Javascript framework, I have decided to
    > write something better.
    >
    > I want a Javascript library that doesn't get in the way, is easily
    > extensible. Just some basic framework to build on for widgets.


    You may like to look at some of this code

    <URL: http://cljs.michaux.ca/>


    > * import() - dynamic script insertion? Dependency resolution?


    I don't think that level of complexity in production is a good idea.
    Work harder in development and have better performance in production.

    > * Building files to modules is easier to test, but feels weird


    Why? Most programming environments require a build step.

    I don't think the monolith style library is a good idea.

    ------------

    You need a very clear idea of which browsers you are targeting or is
    your code for the general web? Then you need a plan for feature
    detection. David Mark has been going through his system with the group
    for a few months now. I've summarized it as an article just yesterday

    <URL: http://peter.michaux.ca/article/7146>

    Peter
    Peter Michaux, Feb 16, 2008
    #4
  5. On Feb 16, 1:14 pm, dhtml <> wrote:

    > The base component is APE.js ->http://dhtmlkitchen.com/ape/src/APE.js


    I don't think you need the namespace function. One namespace level *at
    most* is sufficient. If you can't manage your namespace collisions in
    a few thousand lines of code you have a big problem that needs to be
    addressed. Emacs-lisp is all in one jumbo namespace and that is at
    least many tens of thousands of lines that has survived decades.

    Your extend function looks like something I thought was a good idea.
    If you do keep it, your library shouldn't be dependent on it. In fact
    your library should depend on itself as little as possible.

    Peter
    Peter Michaux, Feb 16, 2008
    #5
  6. On Feb 16, 1:14 pm, dhtml <> wrote:
    > Frustrated with every other Javascript framework, I have decided to
    > write something better.
    >
    > I want a Javascript library that doesn't get in the way, is easily
    > extensible. Just some basic framework to build on for widgets.
    >
    > The BAD things of other libraries:
    > * Weird "OOP"ish schemes
    > * oversimplified interface that does more things behind the scenes
    > * Kitchen Sink - too much bloat in the main library file; non-
    > cohesive.
    > * buggy, with superficial examples that they call "tests"
    > * non-modular design
    > * core library features are poor, inconsistent across browsers, and
    > buggy
    >
    > And, to quote Brendan Eich:
    > Too many of the JS/DHTML toolkits have the "you must use our APIs for
    > everything, including how you manipulate strings" disease.
    >
    > I know what I don't want.
    >
    > Goals:
    > * Minimal Framework, mainly used for AOP and OOP functionality
    > * unit tested
    > * AOP Event System
    > * Namespacing
    > * Modularity, Cohesion, Packaging based on REP
    > * No browser detection
    >
    > TBD:
    > * import() - dynamic script insertion? Dependency resolution?
    > * Building files to modules is easier to test, but feels weird
    >
    > RIA development using javascript, I need widgets (Data Table, Rich
    > Editor). Widgets need: DOM adapter functions (style, position,
    > className), Event-based ajax (or "deferred" Async's), Form
    > serialization, Drag 'n Drop, Animation.
    > I
    > JavaScript lacks "import" and "extend" which are useful for widgets. I
    > use AOP cross cuts even more. I have not seen 1 library that gets
    > these things right. It is very important to get this part right.
    >
    > The base component is APE.js ->http://dhtmlkitchen.com/ape/src/APE.js



    String.prototype.normalize =


    Really bad. This is a major problem with Prototype and has burned them
    when a browser implements the very same function. If you are keen on
    namespacing then you definitely shouldn't be playing with common
    objects.

    "Don't modify objects you don't own."

    Do this...

    function normalizeString(string) {}



    Peter
    Peter Michaux, Feb 16, 2008
    #6
  7. dhtml

    dhtml Guest

    On Feb 16, 2:27 pm, Peter Michaux <> wrote:
    > On Feb 16, 1:14 pm, dhtml <> wrote:
    >
    >
    >
    > > Frustrated with every other Javascript framework, I have decided to
    > > write something better.

    >
    > > I want a Javascript library that doesn't get in the way, is easily
    > > extensible. Just some basic framework to build on for widgets.

    >
    > > The BAD things of other libraries:
    > > * Weird "OOP"ish schemes
    > > * oversimplified interface that does more things behind the scenes
    > > * Kitchen Sink - too much bloat in the main library file; non-
    > > cohesive.
    > > * buggy, with superficial examples that they call "tests"
    > > * non-modular design
    > > * core library features are poor, inconsistent across browsers, and
    > > buggy

    >
    > > And, to quote Brendan Eich:
    > > Too many of the JS/DHTML toolkits have the "you must use our APIs for
    > > everything, including how you manipulate strings" disease.

    >
    > > I know what I don't want.

    >
    > > Goals:
    > > * Minimal Framework, mainly used for AOP and OOP functionality
    > > * unit tested
    > > * AOP Event System
    > > * Namespacing
    > > * Modularity, Cohesion, Packaging based on REP
    > > * No browser detection

    >
    > > TBD:
    > > * import() - dynamic script insertion? Dependency resolution?
    > > * Building files to modules is easier to test, but feels weird

    >
    > > RIA development using javascript, I need widgets (Data Table, Rich
    > > Editor). Widgets need: DOM adapter functions (style, position,
    > > className), Event-based ajax (or "deferred" Async's), Form
    > > serialization, Drag 'n Drop, Animation.
    > > I
    > > JavaScript lacks "import" and "extend" which are useful for widgets. I
    > > use AOP cross cuts even more. I have not seen 1 library that gets
    > > these things right. It is very important to get this part right.

    >
    > > The base component is APE.js ->http://dhtmlkitchen.com/ape/src/APE.js

    >
    > String.prototype.normalize =
    >
    > Really bad. This is a major problem with Prototype and has burned them
    > when a browser implements the very same function. If you are keen on
    > namespacing then you definitely shouldn't be playing with common
    > objects.
    >
    > "Don't modify objects you don't own."
    >
    > Do this...
    >
    > function normalizeString(string) {}
    >

    I've put a conditional check before each:

    if(!String.prototype.trim)
    String.prototype.trim = function(){...}

    What is the disadvantage?


    > Peter
    dhtml, Feb 16, 2008
    #7
  8. dhtml <> writes:

    > I've put a conditional check before each:
    >
    > if(!String.prototype.trim)
    > String.prototype.trim = function(){...}
    >
    > What is the disadvantage?


    The disadvantage is that *if* some browser implements
    String.prototype.trim in some way that has different semantics it could
    break the script.

    Chances of that happening are probably higher than chances of a browser
    implementing APE.trim() for instance.

    Personally though, I would (and do) take that risk for *some*
    functionality simply because it allows for a straight forward way to do
    polymorphism (which may imply you shouldn't use it for functions that
    have no real polymorphic uses).

    --
    Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
    Joost Diepenmaat, Feb 16, 2008
    #8
  9. dhtml

    dhtml Guest

    On Feb 16, 2:27 pm, Peter Michaux <> wrote:
    > On Feb 16, 1:14 pm, dhtml <> wrote:
    >
    >
    >
    > > Frustrated with every other Javascript framework, I have decided to
    > > write something better.

    >
    > > I want a Javascript library that doesn't get in the way, is easily
    > > extensible. Just some basic framework to build on for widgets.

    >
    > > The BAD things of other libraries:
    > > * Weird "OOP"ish schemes
    > > * oversimplified interface that does more things behind the scenes
    > > * Kitchen Sink - too much bloat in the main library file; non-
    > > cohesive.
    > > * buggy, with superficial examples that they call "tests"
    > > * non-modular design
    > > * core library features are poor, inconsistent across browsers, and
    > > buggy

    >
    > > And, to quote Brendan Eich:
    > > Too many of the JS/DHTML toolkits have the "you must use our APIs for
    > > everything, including how you manipulate strings" disease.

    >
    > > I know what I don't want.

    >
    > > Goals:
    > > * Minimal Framework, mainly used for AOP and OOP functionality
    > > * unit tested
    > > * AOP Event System
    > > * Namespacing
    > > * Modularity, Cohesion, Packaging based on REP
    > > * No browser detection

    >
    > > TBD:
    > > * import() - dynamic script insertion? Dependency resolution?
    > > * Building files to modules is easier to test, but feels weird

    >
    > > RIA development using javascript, I need widgets (Data Table, Rich
    > > Editor). Widgets need: DOM adapter functions (style, position,
    > > className), Event-based ajax (or "deferred" Async's), Form
    > > serialization, Drag 'n Drop, Animation.
    > > I
    > > JavaScript lacks "import" and "extend" which are useful for widgets. I
    > > use AOP cross cuts even more. I have not seen 1 library that gets
    > > these things right. It is very important to get this part right.

    >
    > > The base component is APE.js ->http://dhtmlkitchen.com/ape/src/APE.js

    >
    > String.prototype.normalize =
    >
    > Really bad. This is a major problem with Prototype and has burned them
    > when a browser implements the very same function. If you are keen on
    > namespacing then you definitely shouldn't be playing with common
    > objects.
    >
    > "Don't modify objects you don't own."
    >
    > Do this...
    >
    > function normalizeString(string) {}
    >
    > Peter


    couldn't find a disadvantage.

    I did some analysis and I was only using trim()/normalize() with my
    className functions. I reduced this to one function, normalize, as
    that's all I needed. So I have one fewer function call, I also have
    normalize in the enclosing scope (closure), so it might be faster to
    access (doesn't have to look up the prototype chain.

    I wrote a test for my className functions:
    http://dhtmlkitchen.com/ape/test/tests/dom/classname-f-test.html

    The fully expanded, commented version of APE.js is down to 2.9k.

    I'm happy with the change.

    Garrett
    dhtml, Feb 17, 2008
    #9
  10. dhtml

    David Mark Guest

    On Feb 17, 12:30 am, dhtml <> wrote:
    > On Feb 16, 2:27 pm, Peter Michaux <> wrote:
    >
    >
    >
    >
    >
    > > On Feb 16, 1:14 pm, dhtml <> wrote:

    >
    > > > Frustrated with every other Javascript framework, I have decided to
    > > > write something better.

    >
    > > > I want a Javascript library that doesn't get in the way, is easily
    > > > extensible. Just some basic framework to build on for widgets.

    >
    > > > The BAD things of other libraries:
    > > >  * Weird "OOP"ish schemes
    > > >  * oversimplified interface that does more things behind the scenes
    > > >  * Kitchen Sink - too much bloat in the main library file; non-
    > > > cohesive.
    > > >  * buggy, with superficial examples that they call "tests"
    > > >  * non-modular design
    > > >  * core library features are poor, inconsistent across browsers, and
    > > > buggy

    >
    > > > And, to quote Brendan Eich:
    > > > Too many of the JS/DHTML toolkits have the "you must use our APIs for
    > > > everything, including how you manipulate strings" disease.

    >
    > > > I know what I don't want.

    >
    > > > Goals:
    > > >  * Minimal Framework, mainly used for AOP and OOP functionality
    > > >  * unit tested
    > > >  * AOP Event System
    > > >  * Namespacing
    > > >  * Modularity, Cohesion, Packaging based on REP
    > > >  * No browser detection

    >
    > > > TBD:
    > > >  * import() - dynamic script insertion? Dependency resolution?
    > > >  * Building files to modules is easier to test, but feels weird

    >
    > > > RIA development using javascript, I need widgets (Data Table, Rich
    > > > Editor). Widgets need: DOM adapter functions (style, position,
    > > > className), Event-based ajax (or "deferred" Async's), Form
    > > > serialization, Drag 'n Drop, Animation.
    > > > I
    > > > JavaScript lacks "import" and "extend" which are useful for widgets. I
    > > > use AOP cross cuts even more. I have not seen 1 library that gets
    > > > these things right. It is very important to get this part right.

    >
    > > > The base component is APE.js ->http://dhtmlkitchen.com/ape/src/APE.js

    >
    > > String.prototype.normalize =

    >
    > > Really bad. This is a major problem with Prototype and has burned them
    > > when a browser implements the very same function. If you are keen on
    > > namespacing then you definitely shouldn't be playing with common
    > > objects.

    >
    > > "Don't modify objects you don't own."

    >
    > > Do this...

    >
    > > function normalizeString(string) {}

    >
    > > Peter

    >
    > couldn't find a disadvantage.
    >
    > I did some analysis and I was only using trim()/normalize() with my
    > className functions. I reduced this to one function, normalize, as
    > that's all I needed. So I have one fewer function call, I also have
    > normalize in the enclosing scope (closure), so it might be faster to
    > access (doesn't have to look up the prototype chain.
    >
    > I wrote a test for my className functions:http://dhtmlkitchen.com/ape/test/tests/dom/classname-f-test.html
    >
    > The fully expanded, commented version of APE.js is down to 2.9k.
    >
    > I'm happy with the change.


    Something is very wrong with the style of that test page. I can't see
    the leftmost edge (which makes it impossible to read the results of
    the test) and there is a horizontal scrollbar in IE7.
    David Mark, Feb 17, 2008
    #10
  11. dhtml <> writes:

    > Frustrated with every other Javascript framework, I have decided to
    > write something better.
    >
    > I want a Javascript library that doesn't get in the way, is easily
    > extensible. Just some basic framework to build on for widgets.


    Sounds like the goal of jQuery too. I would at least listen -
    critically- to the author of that, to see what experience can
    be reused.
    http://www.youtube.com/watch?v=0LKDImgRfrg

    I must say he sounds more reasonable in this talk than in Richard
    Cornford's signatures.

    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, Feb 17, 2008
    #11
  12. dhtml

    dhtml Guest

    On Feb 17, 5:24 am, Lasse Reichstein Nielsen <> wrote:
    > dhtml <> writes:
    > > Frustrated with every other Javascript framework, I have decided to
    > > write something better.

    >
    > > I want a Javascript library that doesn't get in the way, is easily
    > > extensible. Just some basic framework to build on for widgets.

    >
    > Sounds like the goal of jQuery too. I would at least listen -
    > critically- to the author of that, to see what experience can
    > be reused.
    > http://www.youtube.com/watch?v=0LKDImgRfrg
    >

    I watched that before. I disagree with most of what he says, I think
    it deserves at least one, if not two threads to go over. It's mostly
    higher-level API design stuff. Though I do agree with some of it. It
    gave me contrast to say: That's what I DON'T want to do.

    API design deserves a thread to discuss all the namespacing, modifying
    built-ins, one file vs build system.

    Going back to my code sample. timothytoe suggested I reuse the
    function. Since I'm working with an Object literal, I am considering
    to make a function property. I don't like this property, but I can
    reuse it in two functions.

    fun : function(){},

    Each call to newApply used create a function, then call extend, which
    created another function. It's inefficient.

    /**
    * @param {Function} fun constructor to be invoked.
    * @param {Array} args arguments to pass to the constructor.
    */
    newApply : function(fun, args) {
    var f = APE.fun;
    f.prototype = fun.prototype;// Copy prototype.
    f.prototype.constructor = f;

    var i = new f;
    fun.apply(i, args); // Apply the original constructor.
    return i;
    },


    What do you think?

    I could instead wrap the whole thing in a closure, just for the sake
    of reusing fun.


    Garrett

    > I must say he sounds more reasonable in this talk than in Richard
    > Cornford's signatures.
    >
    > /L
    > --
    > Lasse Reichstein Nielsen -
    > DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    > 'Faith without judgement merely degrades the spirit divine.'
    dhtml, Feb 17, 2008
    #12
  13. dhtml <> writes:

    >
    > /**
    > * @param {Function} fun constructor to be invoked.
    > * @param {Array} args arguments to pass to the constructor.
    > */
    > newApply : function(fun, args) {
    > var f = APE.fun;


    I wouldn't care about reuse here, unless performance is a problem
    and the problem can be tracked to the creation of empty functions
    here.
    Readability-wise, I have to know here that APE.fun is an empty
    function where it doesn't matter that I clobber its prototype.

    > f.prototype = fun.prototype;// Copy prototype.
    > f.prototype.constructor = f;


    Why change the constructor property?

    I would expect the effect of
    newApply(fun,[arg1,arg2])
    to be equivalent to
    new fun(arg1, arg2)
    and the latter inherits a prototype with .constructor == fun,
    not APE.fun.

    > var i = new f;


    For readability, I would capitalize "f", and use a different variable
    name than "i" (suggests a loop index), e.g., "o" or "newObject".

    > fun.apply(i, args); // Apply the original constructor.
    > return i;
    > },
    >
    >
    > What do you think?


    Neat idea!

    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, Feb 18, 2008
    #13
  14. dhtml

    dhtml Guest

    On Feb 17, 10:17 pm, Lasse Reichstein Nielsen <> wrote:
    > dhtml <> writes:
    >

    <snip>

    > Why change the constructor property?
    >
    > I would expect the effect of
    > newApply(fun,[arg1,arg2])
    > to be equivalent to
    > new fun(arg1, arg2)
    > and the latter inherits a prototype with .constructor == fun,
    > not APE.fun.
    >

    You're right.

    > > var i = new f;

    >
    > For readability, I would capitalize "f", and use a different variable
    > name than "i" (suggests a loop index), e.g., "o" or "newObject".
    >
    > > fun.apply(i, args); // Apply the original constructor.
    > > return i;
    > > },

    >
    > > What do you think?

    >

    You're right about the constructor prop. I'll change f to F. As for |
    i|, well, I'll think about a better variable name. I was thinking
    "instance", but just called it |i| for brevity.


    Now I need a test to make sure the constructor property is set
    correctly.

    > Neat idea!
    >

    Cool! Thanks for the bug rept.


    > /L
    > --
    > Lasse Reichstein Nielsen -
    > DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    > 'Faith without judgement merely degrades the spirit divine.'
    dhtml, Feb 18, 2008
    #14
  15. On Feb 17, 10:51 pm, dhtml <> wrote:

    [snip]

    > Now I need a test to make sure the constructor property is set
    > correctly.


    I don't ever use the constructor property and I doubt many folks do.
    It isn't worth the trouble to keep it "correct".

    Then again, I never overwrite the initial prototype property of a
    function anymore so I'm not screwing up the constructor property in
    the first place.

    Peter
    Peter Michaux, Feb 18, 2008
    #15
  16. dhtml

    RobG Guest

    On Feb 18, 5:07 pm, Peter Michaux <> wrote:
    > On Feb 17, 10:51 pm, dhtml <> wrote:
    >
    > [snip]
    >
    > > Now I need a test to make sure the constructor property is set
    > > correctly.

    >
    > I don't ever use the constructor property and I doubt many folks do.
    > It isn't worth the trouble to keep it "correct".
    >
    > Then again, I never overwrite the initial prototype property of a
    > function anymore so I'm not screwing up the constructor property in
    > the first place.


    Are you persisting with FORK? Or have you decided that the "code
    worth recommending project" (cwrp) will form the basis of a (new?)
    modular FORK?

    Perhaps dhtml can use the cwrp as the basis for a modular library else
    it seem the effort is already forked (gosh, my puns are nearly as bad
    as Linus T's).


    --
    Rob
    RobG, Feb 18, 2008
    #16
  17. dhtml

    dhtml Guest

    On Feb 16, 2:19 pm, Peter Michaux <> wrote:
    > On Feb 16, 1:14 pm, dhtml <> wrote:
    >


    > <URL:http://peter.michaux.ca/article/7146>


    Try the |in| operator.
    var xhr = new ActiveXObject('Microsoft.XMLHTTP');
    'open' in xhr;

    Or, if you don't like |in|, you could use:

    Object.prototype.hasOwnProperty.call(xhr, 'open')

    Garrett

    > Peter
    dhtml, Feb 19, 2008
    #17
  18. On Feb 17, 11:34 pm, RobG <> wrote:
    > On Feb 18, 5:07 pm, Peter Michaux <> wrote:
    >
    > > On Feb 17, 10:51 pm, dhtml <> wrote:

    >
    > > [snip]

    >
    > > > Now I need a test to make sure the constructor property is set
    > > > correctly.

    >
    > > I don't ever use the constructor property and I doubt many folks do.
    > > It isn't worth the trouble to keep it "correct".

    >
    > > Then again, I never overwrite the initial prototype property of a
    > > function anymore so I'm not screwing up the constructor property in
    > > the first place.

    >
    > Are you persisting with FORK? Or have you decided that the "code
    > worth recommending project" (cwrp) will form the basis of a (new?)
    > modular FORK?
    >
    > Perhaps dhtml can use the cwrp as the basis for a modular library else
    > it seem the effort is already forked (gosh, my puns are nearly as bad
    > as Linus T's).


    I don't quite know what will happen yet. David seems to be working on
    a library and I have enjoyed all of the discussion that the code worth
    recommending project prompted. I'm currently using the Fork code in
    work and it has been working fine for me without any changes for a
    year.

    Peter
    Peter Michaux, Feb 19, 2008
    #18
  19. dhtml

    David Mark Guest

    On Feb 18, 9:51 pm, Peter Michaux <> wrote:
    > On Feb 17, 11:34 pm, RobG <> wrote:
    >
    >
    >
    >
    >
    > > On Feb 18, 5:07 pm, Peter Michaux <> wrote:

    >
    > > > On Feb 17, 10:51 pm, dhtml <> wrote:

    >
    > > > [snip]

    >
    > > > > Now I need a test to make sure the constructor property is set
    > > > > correctly.

    >
    > > > I don't ever use the constructor property and I doubt many folks do.
    > > > It isn't worth the trouble to keep it "correct".

    >
    > > > Then again, I never overwrite the initial prototype property of a
    > > > function anymore so I'm not screwing up the constructor property in
    > > > the first place.

    >
    > > Are you persisting with FORK?  Or have you decided that the "code
    > > worth recommending project" (cwrp) will form the basis of a (new?)
    > > modular FORK?

    >
    > > Perhaps dhtml can use the cwrp as the basis for a modular library else
    > > it seem the effort is already forked (gosh, my puns are nearly as bad
    > > as Linus T's).

    >
    > I don't quite know what will happen yet. David seems to be working on


    Things are as they seem in this case. Did you check out the Alpha I
    posted a month back? The Beta should go live this weekend and I will
    invite everybody to try it out (criticism and suggestions will be more
    than welcome.)

    > a library and I have enjoyed all of the discussion that the code worth
    > recommending project prompted. I'm currently using the Fork code in
    > work and it has been working fine for me without any changes for a
    > year.
    >


    I recently surveyed FORK (Fork?) and it looked quite good. Though I
    imagine there are things you would change after all of the various CWR-
    related discussions.
    David Mark, Feb 19, 2008
    #19
  20. On Feb 18, 7:01 pm, David Mark <> wrote:
    > On Feb 18, 9:51 pm, Peter Michaux <> wrote:
    >
    >
    >
    > > On Feb 17, 11:34 pm, RobG <> wrote:

    >
    > > > On Feb 18, 5:07 pm, Peter Michaux <> wrote:

    >
    > > > > On Feb 17, 10:51 pm, dhtml <> wrote:

    >
    > > > > [snip]

    >
    > > > > > Now I need a test to make sure the constructor property is set
    > > > > > correctly.

    >
    > > > > I don't ever use the constructor property and I doubt many folks do.
    > > > > It isn't worth the trouble to keep it "correct".

    >
    > > > > Then again, I never overwrite the initial prototype property of a
    > > > > function anymore so I'm not screwing up the constructor property in
    > > > > the first place.

    >
    > > > Are you persisting with FORK? Or have you decided that the "code
    > > > worth recommending project" (cwrp) will form the basis of a (new?)
    > > > modular FORK?

    >
    > > > Perhaps dhtml can use the cwrp as the basis for a modular library else
    > > > it seem the effort is already forked (gosh, my puns are nearly as bad
    > > > as Linus T's).

    >
    > > I don't quite know what will happen yet. David seems to be working on

    >
    > Things are as they seem in this case. Did you check out the Alpha I
    > posted a month back?


    I have been reading the code which has been a big help. The builder is
    a great feature.

    > The Beta should go live this weekend and I will
    > invite everybody to try it out (criticism and suggestions will be more
    > than welcome.)


    How do you feel about promoting your library? With Fork, I found out
    almost instantly that I didn't want to promote it aggressively. Folks
    that run the YUI, jQuery, Dojo, Prototype libraries go to a lot of
    conferences and have birthday parties, etc. Some of the libraries have
    people designated as evangelists, I believe. I don't have a problem
    with any of that and it is why the libraries are popular.
    Theoretically popular means more people reading the code and reporting
    bugs. Those projects do have bug fix releases and so that part is
    working.

    > > a library and I have enjoyed all of the discussion that the code worth
    > > recommending project prompted. I'm currently using the Fork code in
    > > work and it has been working fine for me without any changes for a
    > > year.

    >
    > I recently surveyed FORK (Fork?) and it looked quite good. Though I
    > imagine there are things you would change after all of the various CWR-
    > related discussions.


    Indeed there are. It is working fine for me because I only use it on a
    site behind login with tech-savvy users. No complaints.

    I like the API in general but would drop the namespacing to just one
    level. I don't know why I can't mentally just go to global functions
    like FORK_addistener. What is wrong with that anyway?

    -----

    By the way, I think I'll be posting the tabbed pane article tonight. I
    just need to have it tested remotely on some very old Safari versions.
    Thanks for all the help. I'm interested to see if people will read it
    and comment.

    Peter
    Peter Michaux, Feb 19, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Vagif Abilov
    Replies:
    2
    Views:
    550
    Vagif Abilov
    Jul 7, 2004
  2. Pedro Mir
    Replies:
    2
    Views:
    431
    Winista
    Jun 20, 2006
  3. Nicolas Lehuen
    Replies:
    3
    Views:
    701
    Nicolas Lehuen
    Jan 28, 2004
  4. Diez B. Roggisch
    Replies:
    0
    Views:
    373
    Diez B. Roggisch
    Jun 10, 2008
  5. DJ Stunks
    Replies:
    0
    Views:
    316
    DJ Stunks
    Feb 10, 2007
Loading...

Share This Page