Clear all optgroups and options from a select list

Discussion in 'Javascript' started by Brian D, Aug 4, 2006.

  1. Brian D

    Brian D Guest

    I have a multiple select list that is created dynamically based on a
    previous selection on an asp page. The first thing I do is to clear
    the curent option list by

    document.form1.itemcross.length = 0;

    The only problem is that it leaves the optgroups. How do I also get
    rid of the optgroups?

    Thanks
    BrianD
     
    Brian D, Aug 4, 2006
    #1
    1. Advertising

  2. Brian D

    darwinist Guest

    Brian D wrote:
    > I have a multiple select list that is created dynamically based on a
    > previous selection on an asp page. The first thing I do is to clear
    > the curent option list by
    >
    > document.form1.itemcross.length = 0;
    >
    > The only problem is that it leaves the optgroups. How do I also get
    > rid of the optgroups?
    >
    > Thanks
    > BrianD


    You need an id for the object or a reference to it:

    <script>
    // delete an object by reference
    function del(element){element.parentNode.removeChild(element);}
    // Get a reference to an object by id:
    function $(id){return document.getElementById(id);}
    // Delete an object by id:
    function $del(id){x=$(id); del(x);}
    </script>

    hope this helps

    ---
    http://darwinist.googlepages.com/htmldesktop.html
    (lots of working examples)
     
    darwinist, Aug 5, 2006
    #2
    1. Advertising

  3. Brian D

    RobG Guest

    Brian D wrote:

    > I have a multiple select list that is created dynamically based on a
    > previous selection on an asp page. The first thing I do is to clear
    > the curent option list by
    >
    > document.form1.itemcross.length = 0;
    >
    > The only problem is that it leaves the optgroups. How do I also get
    > rid of the optgroups?


    The usual way:

    var sel = document.form1.itemcross;
    while (sel.firstChild) {
    sel.removeChild(sel.firstChild);
    }


    --
    Rob
     
    RobG, Aug 5, 2006
    #3
  4. Brian D

    RobG Guest

    darwinist wrote:

    > Brian D wrote:
    > > I have a multiple select list that is created dynamically based on a
    > > previous selection on an asp page. The first thing I do is to clear
    > > the curent option list by
    > >
    > > document.form1.itemcross.length = 0;
    > >
    > > The only problem is that it leaves the optgroups. How do I also get
    > > rid of the optgroups?
    > >
    > > Thanks
    > > BrianD

    >
    > You need an id for the object or a reference to it:


    The OP has already indicated how he's doing that, and may be using
    either an ID or a NAME attribute.


    > <script>


    Please don't recommend using invalid HTML. Do it in your own library
    if you wish, but don't encourage it here.


    > // delete an object by reference
    > function del(element){element.parentNode.removeChild(element);}


    The OP is attempting to remove the child nodes, not the element itself.


    --
    Rob
     
    RobG, Aug 5, 2006
    #4
  5. Brian D

    darwinist Guest

    RobG wrote:
    > darwinist wrote:
    >
    > > Brian D wrote:
    > > > I have a multiple select list that is created dynamically based on a
    > > > previous selection on an asp page. The first thing I do is to clear
    > > > the curent option list by
    > > >
    > > > document.form1.itemcross.length = 0;
    > > >
    > > > The only problem is that it leaves the optgroups. How do I also get
    > > > rid of the optgroups?
    > > >
    > > > Thanks
    > > > BrianD

    > >
    > > You need an id for the object or a reference to it:

    >
    > The OP has already indicated how he's doing that, and may be using
    > either an ID or a NAME attribute.
    >
    >
    > > <script>

    >
    > Please don't recommend using invalid HTML. Do it in your own library
    > if you wish, but don't encourage it here.
    >
    >
    > > // delete an object by reference
    > > function del(element){element.parentNode.removeChild(element);}

    >
    > The OP is attempting to remove the child nodes, not the element itself.


    Isn't an optgroup an element that you can remove like any other?
    http://www.w3schools.com/tags/tag_optgroup.asp

    >
    > --
    > Rob
     
    darwinist, Aug 6, 2006
    #5
  6. Brian D

    RobG Guest

    darwinist wrote:
    > RobG wrote:
    >> darwinist wrote:
    >>
    >>> Brian D wrote:
    >>>> I have a multiple select list that is created dynamically based on a
    >>>> previous selection on an asp page. The first thing I do is to clear
    >>>> the curent option list by
    >>>>
    >>>> document.form1.itemcross.length = 0;
    >>>>
    >>>> The only problem is that it leaves the optgroups. How do I also get
    >>>> rid of the optgroups?


    [...]

    >>> You need an id for the object or a reference to it:

    >> The OP has already indicated how he's doing that, and may be using
    >> either an ID or a NAME attribute.


    [...]

    >>> // delete an object by reference
    >>> function del(element){element.parentNode.removeChild(element);}

    >> The OP is attempting to remove the child nodes, not the element itself.

    >
    > Isn't an optgroup an element that you can remove like any other?


    Yes. Your response was essentially to give every option an ID, then
    remove them one by one using getElementById. That is not a reasonable
    method given the question.


    --
    Rob
     
    RobG, Aug 6, 2006
    #6
  7. Brian D

    darwinist Guest

    RobG wrote:
    > darwinist wrote:
    > > RobG wrote:
    > >> darwinist wrote:
    > >>
    > >>> Brian D wrote:
    > >>>> I have a multiple select list that is created dynamically based on a
    > >>>> previous selection on an asp page. The first thing I do is to clear
    > >>>> the curent option list by
    > >>>>
    > >>>> document.form1.itemcross.length = 0;
    > >>>>
    > >>>> The only problem is that it leaves the optgroups. How do I also get
    > >>>> rid of the optgroups?

    >
    > [...]
    >
    > >>> You need an id for the object or a reference to it:
    > >> The OP has already indicated how he's doing that, and may be using
    > >> either an ID or a NAME attribute.

    >
    > [...]
    >
    > >>> // delete an object by reference
    > >>> function del(element){element.parentNode.removeChild(element);}
    > >> The OP is attempting to remove the child nodes, not the element itself.

    > >
    > > Isn't an optgroup an element that you can remove like any other?

    >
    > Yes. Your response was essentially to give every option an ID, then
    > remove them one by one using getElementById. That is not a reasonable
    > method given the question.


    I said "or a reference to it", and gave commented, working examples of
    how to deal with both. What's your problem?

    Javascript's native methods use a lot of codespace for common things
    that don't take much time. This rigid structure is important to the
    integrity of the platform but when you are putting it to any actual
    purpose you need short, clear, purpose-specific functions that reflect
    what your application, not the language, is doing.

    For example:
    http://darwinist.googlepages.com/htmldesktop.html

    Feel free to criticise or contribute.

    >
    > --
    > Rob
     
    darwinist, Aug 7, 2006
    #7
  8. Brian D

    RobG Guest

    darwinist wrote:
    > RobG wrote:
    > > darwinist wrote:
    > > > RobG wrote:
    > > >> darwinist wrote:
    > > >>
    > > >>> Brian D wrote:
    > > >>>> I have a multiple select list that is created dynamically based on a
    > > >>>> previous selection on an asp page. The first thing I do is to clear
    > > >>>> the curent option list by
    > > >>>>
    > > >>>> document.form1.itemcross.length = 0;
    > > >>>>
    > > >>>> The only problem is that it leaves the optgroups. How do I also get
    > > >>>> rid of the optgroups?

    > >
    > > [...]
    > >
    > > >>> You need an id for the object or a reference to it:
    > > >> The OP has already indicated how he's doing that, and may be using
    > > >> either an ID or a NAME attribute.

    > >
    > > [...]
    > >
    > > >>> // delete an object by reference
    > > >>> function del(element){element.parentNode.removeChild(element);}
    > > >> The OP is attempting to remove the child nodes, not the element itself.
    > > >
    > > > Isn't an optgroup an element that you can remove like any other?

    > >
    > > Yes. Your response was essentially to give every option an ID, then
    > > remove them one by one using getElementById. That is not a reasonable
    > > method given the question.

    >
    > I said "or a reference to it", and gave commented, working examples of
    > how to deal with both. What's your problem?


    The OP already had a reference to the select element and just wanted to
    remove all the child nodes. To use your proposed solution, the OP
    would have looped through all the child nodes, then called the 'del'
    function which used the child node to reference back to the parent node
    to delete itself.

    That may have lead to a few characters less in the for loop, but also
    an extra unnecessary function object plus an extra couple of loop-ups
    for parent and child nodes. So appart from obfuscation, you also make
    the whole process less efficient.

    The function I posted was perhaps 3 lines of code and could (had the OP
    wanted) be wrapped in a separate 'deleteAllChildNodes' function. I
    think it actually required fewer keystrokes, not that it matters.

    Incidentally, the fastest way I've seen to delete all the child nodes
    of an element is to replace it with a shallow clone of itself.
    Unfortunately, a few scarce browsers don't like doing that with all
    elements so it's not useful on the web. But for an intranet... ;-)


    > Javascript's native methods use a lot of codespace for common things
    > that don't take much time. This rigid structure is important to the
    > integrity of the platform but when you are putting it to any actual
    > purpose you need short, clear, purpose-specific functions that reflect
    > what your application, not the language, is doing.


    I don't see how adding an ID to every element you want to delete makes
    life easier. It also suggests managing all those IDs and some
    algorithm to work out which ones are of interest.

    Creating single-line functions purely for the sake of reducing the
    number of keystrokes for a programmer to type a method will not lead to
    any great advantage in reducing software development times (that
    discussion is being hosted in another thread I think). If it did, such
    widely used environments as VB wouldn't have names that approach the
    length of short sentences (please don't assume I think VB is some
    paragon of programming excellence - it's just an example) and brevity
    would be a fundamental principle of coding standards everywhere. It
    isn't - clarity is.

    If you've ever tried to maintain some one else's code (say C or C++)
    you'd know why.


    --
    Rob
     
    RobG, Aug 7, 2006
    #8
  9. darwinist wrote:
    > RobG wrote:
    >> darwinist wrote:
    >>>> darwinist wrote:

    <snip>
    >>>>> You need an id for the object or a reference to it:

    <snip>
    >>> Isn't an optgroup an element that you can remove like
    >>> any other?

    >>
    >> Yes. Your response was essentially to give every option
    >> an ID, then remove them one by one using getElementById.
    >> That is not a reasonable method given the question.

    >
    > I said "or a reference to it", and gave commented, working
    > examples of how to deal with both. What's your problem?


    The example you gave was an example that required each optgroup element
    to have and ID, that would be the wrong thing to do.

    <snip>
    > For example:
    > http://darwinist.googlepages.com/htmldesktop.html
    >
    > Feel free to criticise


    You have never actually said what this thing is supposed to be for. It
    looks like it is indented to be the bases for an in-browser windowing
    system for web-applications. It doesn't look capable enough for any
    actual example of such, but I suppose could be extended for specific
    applications. However, as it is only really suited for Mozilla/Gecko
    browsers as it stands I don't see it being of much practical benefit in
    a world where IE support is normally expected (and sometimes
    sufficient).

    > or contribute.


    You don't appear to be someone who takes advice, so anything approaching
    collaboration is out of the question.

    Richard.
     
    Richard Cornford, Aug 7, 2006
    #9
  10. Brian D

    darwinist Guest

    RobG wrote:
    > darwinist wrote:
    > > RobG wrote:
    > > > darwinist wrote:
    > > > > RobG wrote:
    > > > >> darwinist wrote:
    > > > >>
    > > > >>> Brian D wrote:
    > > > >>>> I have a multiple select list that is created dynamically based on a
    > > > >>>> previous selection on an asp page. The first thing I do is to clear
    > > > >>>> the curent option list by
    > > > >>>>
    > > > >>>> document.form1.itemcross.length = 0;
    > > > >>>>
    > > > >>>> The only problem is that it leaves the optgroups. How do I also get
    > > > >>>> rid of the optgroups?
    > > >
    > > > [...]
    > > >
    > > > >>> You need an id for the object or a reference to it:
    > > > >> The OP has already indicated how he's doing that, and may be using
    > > > >> either an ID or a NAME attribute.
    > > >
    > > > [...]
    > > >
    > > > >>> // delete an object by reference
    > > > >>> function del(element){element.parentNode.removeChild(element);}
    > > > >> The OP is attempting to remove the child nodes, not the element itself.
    > > > >
    > > > > Isn't an optgroup an element that you can remove like any other?
    > > >
    > > > Yes. Your response was essentially to give every option an ID, then
    > > > remove them one by one using getElementById. That is not a reasonable
    > > > method given the question.

    > >
    > > I said "or a reference to it", and gave commented, working examples of
    > > how to deal with both. What's your problem?

    >
    > The OP already had a reference to the select element and just wanted to
    > remove all the child nodes. To use your proposed solution, the OP
    > would have looped through all the child nodes, then called the 'del'
    > function which used the child node to reference back to the parent node
    > to delete itself.
    >
    > That may have lead to a few characters less in the for loop, but also
    > an extra unnecessary function object plus an extra couple of loop-ups
    > for parent and child nodes. So appart from obfuscation, you also make
    > the whole process less efficient.
    >
    > The function I posted was perhaps 3 lines of code and could (had the OP
    > wanted) be wrapped in a separate 'deleteAllChildNodes' function. I
    > think it actually required fewer keystrokes, not that it matters.


    You're right to empty an object it's more efficient to have a function
    that does just that, instead of a generic delete one and another loop
    for every object you want to empty.

    > Incidentally, the fastest way I've seen to delete all the child nodes
    > of an element is to replace it with a shallow clone of itself.
    > Unfortunately, a few scarce browsers don't like doing that with all
    > elements so it's not useful on the web. But for an intranet... ;-)
    >
    >
    > > Javascript's native methods use a lot of codespace for common things
    > > that don't take much time. This rigid structure is important to the
    > > integrity of the platform but when you are putting it to any actual
    > > purpose you need short, clear, purpose-specific functions that reflect
    > > what your application, not the language, is doing.

    >
    > I don't see how adding an ID to every element you want to delete makes
    > life easier. It also suggests managing all those IDs and some
    > algorithm to work out which ones are of interest.


    That was an argument for short single-word functions that have meaning
    in the contenxt of a partiuclar application. The overuse of the ID tag
    is just my ignorance of javascript and not related in any way.

    > Creating single-line functions purely for the sake of reducing the
    > number of keystrokes for a programmer to type a method will not lead to
    > any great advantage in reducing software development times (that
    > discussion is being hosted in another thread I think). If it did, such
    > widely used environments as VB wouldn't have names that approach the
    > length of short sentences (please don't assume I think VB is some
    > paragon of programming excellence - it's just an example) and brevity
    > would be a fundamental principle of coding standards everywhere. It
    > isn't - clarity is.


    Brevity is not neutral with regards to clarity. Mashing a lot of words
    together with hungarian notation isn't necessarily more clear than
    single word sentences, but it is more precise for a framework or
    toolkit. Using lots of convoluted code structures and peforming too
    many operations in a single statement is also not clear, although it
    may be brief.

    Complete words, individual words, are what we read best, and how we
    think.

    > If you've ever tried to maintain some one else's code (say C or C++)
    > you'd know why.


    Funny you should mention it I've been doing precisely that for the last
    few months.

    >
    > --
    > Rob
     
    darwinist, Aug 7, 2006
    #10
  11. Brian D

    darwinist Guest

    Richard Cornford wrote:
    > darwinist wrote:
    > > RobG wrote:
    > >> darwinist wrote:
    > >>>> darwinist wrote:

    > <snip>
    > >>>>> You need an id for the object or a reference to it:

    > <snip>
    > >>> Isn't an optgroup an element that you can remove like
    > >>> any other?
    > >>
    > >> Yes. Your response was essentially to give every option
    > >> an ID, then remove them one by one using getElementById.
    > >> That is not a reasonable method given the question.

    > >
    > > I said "or a reference to it", and gave commented, working
    > > examples of how to deal with both. What's your problem?

    >
    > The example you gave was an example that required each optgroup element
    > to have and ID, that would be the wrong thing to do.


    It did not require an ID, it required either an id or a reference,
    (which was the first thing i said to the OP). The first actual example
    I gave was:

    // delete an object by reference
    function del(element){element.parentNode.removeChild(element);}


    In case no id was present or necessary.

    > <snip>
    > > For example:
    > > http://darwinist.googlepages.com/htmldesktop.html
    > >
    > > Feel free to criticise

    >
    > You have never actually said what this thing is supposed to be for.


    It's to demonstrate all you need to know to start making your own
    web-based desktop system, or any subset thereof (a windowed-based
    application, for example). It's far from perfect but it includes all
    basic functionality required, plus an "immediate" box, and a manual.

    > It
    > looks like it is indented to be the bases for an in-browser windowing
    > system for web-applications. It doesn't look capable enough for any
    > actual example of such,


    Under Help->Examples there are several working examples for making
    windows, making objects draggable, a hello world program, etc.

    Also the windowing system itself works, as does the desktop.

    > but I suppose could be extended for specific
    > applications. However, as it is only really suited for Mozilla/Gecko
    > browsers as it stands


    There isn't any browser-specific code, and although it's not coded to
    an apparently well-known ie bug, it's fairly lightweight and quite
    responsive in either major browser.

    > I don't see it being of much practical benefit in
    > a world where IE support is normally expected (and sometimes
    > sufficient).


    It's meant as a free codebase. I've seen nothing really that does all
    desktop-environment stuff in a short, free, clear fashion. Most is
    heavy or proprietary, or both, and most try to reinvent the wheel.

    > > or contribute.

    >
    > You don't appear to be someone who takes advice, so anything approaching
    > collaboration is out of the question.


    I appreciate your advice, even if you don't like what I do with it. I
    happen to consider that what "works" is very important. Javsacript
    specs are what browsers should implement, but actual browser support is
    what programmers need to worry about.

    It seems that moving windows around by reference rather than ID would
    be a speed improvement and probably slightly less code, so you can
    rest-assured my application will reflect this when I next have a play
    with it.

    I don't respond to authority though. Never have, never will (unless
    you're paying me).

    > Richard.
     
    darwinist, Aug 7, 2006
    #11
  12. Brian D

    RobG Guest

    darwinist wrote:
    > RobG wrote:

    [...]
    > > Creating single-line functions purely for the sake of reducing the
    > > number of keystrokes for a programmer to type a method will not lead to
    > > any great advantage in reducing software development times (that
    > > discussion is being hosted in another thread I think). If it did, such
    > > widely used environments as VB wouldn't have names that approach the
    > > length of short sentences (please don't assume I think VB is some
    > > paragon of programming excellence - it's just an example) and brevity
    > > would be a fundamental principle of coding standards everywhere. It
    > > isn't - clarity is.

    >
    > Brevity is not neutral with regards to clarity.


    I did not say that brevity and clarity are mutually exclusive, but that
    brevity does not infer clarity - e.g. jargon is great shorthand for
    those 'in the know', but is greatly disliked for its ability to
    confound.


    > Mashing a lot of words
    > together with hungarian notation isn't necessarily more clear than
    > single word sentences,


    Yes, verbosity is just as bad - but I'm not promoting that either.

    You may note that single word sentences only ever make sense in the
    context of surrounding text. A programmer seeing your $make() function
    would first need to look at the source to see what it does, only to
    find that it is a simple wrapper for document.createElement.

    If in fact $make() was say 100 lines of code, you then either need to
    provide precise documentation to say what it does and doesn't do or
    assume the programmer will know exactly that from reading the code.

    The rub is that if the programmer can infer precisely what the code
    does just by reading it, they likely have their own library or can
    write a project-specific one that better suits their requirements. If
    the programmer isn't that knowledgeable, they will likely misuse the
    library (e.g. a recent post which asked 'why do I get this error on
    line 1502 of prototype.js').


    > but it is more precise for a framework or
    > toolkit. Using lots of convoluted code structures and peforming too
    > many operations in a single statement is also not clear, although it
    > may be brief.


    That is not an argument either way - obfuscated code is obfuscated
    code, brevity (a weapon employed by obfuscation tools) is just as
    obfuscatory as verbosity and 'tight' code.

    Which is clearer:

    dom_deleteElement();

    or

    $del();


    I think most JavaScript programmers could say with reasonable certainty
    what the first function does, but would be guessing about the second.
    Very few would guess that the second *only* deletes DOM elements.

    For the sake of a few extra characters for a programmer to type, the
    code becomes much clearer. If code bulk is a serious problem, use a
    minifier before sending code to the client.

    The bottom line is that code for a project can nearly always be better
    optimised for bulk by writing concise, project-specific code than
    including 2,000 line libraries to save a few characters in function
    calls.


    > Complete words, individual words, are what we read best, and how we
    > think.


    I think you are crossing over into literary comprehension, which is a
    field well outside the scope of this news group.

    I don't think in sentences of one word, nor can I conceive that single
    words (and occasionally abbreviated single words) are always sufficient
    to describe the functionality of everything. What does $del() imply?
    It means something to you because you have the context of the library
    that you wrote it to fit into. As noted above, single work sentences
    *only* make sense when taken in context with surrounding text.

    Hello.


    --
    Rob
     
    RobG, Aug 7, 2006
    #12
  13. Brian D

    darwinist Guest

    RobG wrote:
    > darwinist wrote:
    > > RobG wrote:

    > [...]
    > > > Creating single-line functions purely for the sake of reducing the
    > > > number of keystrokes for a programmer to type a method will not lead to
    > > > any great advantage in reducing software development times (that
    > > > discussion is being hosted in another thread I think). If it did, such
    > > > widely used environments as VB wouldn't have names that approach the
    > > > length of short sentences (please don't assume I think VB is some
    > > > paragon of programming excellence - it's just an example) and brevity
    > > > would be a fundamental principle of coding standards everywhere. It
    > > > isn't - clarity is.

    > >
    > > Brevity is not neutral with regards to clarity.

    >
    > I did not say that brevity and clarity are mutually exclusive, but that
    > brevity does not infer clarity - e.g. jargon is great shorthand for
    > those 'in the know', but is greatly disliked for its ability to
    > confound.
    >
    >
    > > Mashing a lot of words
    > > together with hungarian notation isn't necessarily more clear than
    > > single word sentences,

    >
    > Yes, verbosity is just as bad - but I'm not promoting that either.
    >
    > You may note that single word sentences only ever make sense in the
    > context of surrounding text. A programmer seeing your $make() function
    > would first need to look at the source to see what it does, only to
    > find that it is a simple wrapper for document.createElement.
    >
    > If in fact $make() was say 100 lines of code, you then either need to
    > provide precise documentation to say what it does and doesn't do or
    > assume the programmer will know exactly that from reading the code.
    >
    > The rub is that if the programmer can infer precisely what the code
    > does just by reading it, they likely have their own library or can
    > write a project-specific one that better suits their requirements. If
    > the programmer isn't that knowledgeable, they will likely misuse the
    > library (e.g. a recent post which asked 'why do I get this error on
    > line 1502 of prototype.js').
    >
    >
    > > but it is more precise for a framework or
    > > toolkit. Using lots of convoluted code structures and peforming too
    > > many operations in a single statement is also not clear, although it
    > > may be brief.

    >
    > That is not an argument either way - obfuscated code is obfuscated
    > code, brevity (a weapon employed by obfuscation tools) is just as
    > obfuscatory as verbosity and 'tight' code.
    >
    > Which is clearer:
    >
    > dom_deleteElement();
    >
    > or
    >
    > $del();
    >
    >
    > I think most JavaScript programmers could say with reasonable certainty
    > what the first function does, but would be guessing about the second.
    > Very few would guess that the second *only* deletes DOM elements.


    They don't need to "guess". Function names are one part of their
    description, but not the only one. Comments and context, for example
    are two others. If they take arguments then they are another.

    > For the sake of a few extra characters for a programmer to type, the
    > code becomes much clearer. If code bulk is a serious problem, use a
    > minifier before sending code to the client.
    >
    > The bottom line is that code for a project can nearly always be better
    > optimised for bulk by writing concise, project-specific code than
    > including 2,000 line libraries to save a few characters in function
    > calls.


    I agree, but that doesn't mean you can't write concise project specific
    code, that happens to include a library of common actions, with short
    and simple names, even if some of them are just wrappers to more
    verbose, platform-specific method calls.

    My point is that separating the application from the language,
    conceptually, is a good thing.

    >
    > > Complete words, individual words, are what we read best, and how we
    > > think.

    >
    > I think you are crossing over into literary comprehension, which is a
    > field well outside the scope of this news group.
    >
    > I don't think in sentences of one word, nor can I conceive that single
    > words (and occasionally abbreviated single words) are always sufficient
    > to describe the functionality of everything.


    Sorry I meant single word "functions" (or as few words as practicable).
    Of course sentences need at least a verb and a noun, almost always.

    > What does $del() imply?
    > It means something to you because you have the context of the library
    > that you wrote it to fit into. As noted above, single work sentences
    > *only* make sense when taken in context with surrounding text.
    >
    > Hello.
    >
    >
    > --
    > Rob
     
    darwinist, Aug 7, 2006
    #13
  14. Brian D

    Brian D Guest

    RobG wrote:

    >
    > The usual way:
    >
    > var sel = document.form1.itemcross;
    > while (sel.firstChild) {
    > sel.removeChild(sel.firstChild);
    > }


    RobG. Thanks! It was exactly what I needed!
    -Brian
     
    Brian D, Aug 7, 2006
    #14
  15. darwinist wrote:
    > Richard Cornford wrote:

    <snip>
    >> The example you gave was an example that required each
    >> optgroup element to have and ID, that would be the
    >> wrong thing to do.

    <snip>

    So you did, sorry. Weren't we discussing the clarity/readability of
    javascript source code recently?

    <snip>
    >>> For example:
    >>> http://darwinist.googlepages.com/htmldesktop.html
    >>>
    >>> Feel free to criticise

    >>
    >> You have never actually said what this thing is supposed to
    >> be for.

    >
    > It's to demonstrate all you need to know to start making
    > your own web-based desktop system, or any subset thereof
    > (a windowed-based application, for example).


    Now there is a frightening notion. I didn't look at your actual code too
    much, I just verified that it did have the serious memory leak I was
    expecting on IE, did not address the select element issue, and that you
    could not drag one window over the contents of another because the mouse
    co-ordinates were not available in the containing frame (that is, it
    failed on the three primary issues of an in browser 'windowing' system
    in IE). I suspect that much else that would be useful in any actual
    application would also be missing, such as an ability for code executing
    in a 'window' to respond to window dragging, re-sizing, closing and
    focusing (moving to the front) actions.

    > It's far from perfect but it includes all
    > basic functionality required, plus an "immediate"
    > box, and a manual.
    >
    >> It looks like it is indented to be the bases for an
    >> in-browser windowing system for web-applications. It
    >> doesn't look capable enough for any actual example of
    >> such,

    >
    > Under Help->Examples there are several working examples
    > for making windows, making objects draggable, a hello
    > world program, etc.


    There is quite a gap between 'hello world' and a web application
    multi-facetted enough to warrant a windowing GUI.

    > Also the windowing system itself works, as does the
    > desktop.
    >
    >> but I suppose could be extended for specific
    >> applications. However, as it is only really suited
    >> for Mozilla/Gecko browsers as it stands

    >
    > There isn't any browser-specific code, and although it's
    > not coded to an apparently well-known ie bug,


    At least two well known IE bugs, but the number doesn't matter as any
    one is sufficient to make the result viable for use on Windows IE only
    Intranets, or multi-browser Intranets that include IE (i.e. the actual
    market) for as long as your "I'm not particularly interested in coding
    to the bugs of a product whose manufacturers don't even pretend it's
    good anymore" stands.

    > it's fairly lightweight and quite
    > responsive in either major browser.


    Maybe as it stands, but an actual application would be expected to have
    something going on in those windows, which is what will slow the total
    down.

    (Incidentally "either major browser" sounds like the 'both browsers'
    attitude prevalent at the end of the last century.)

    >> I don't see it being of much practical benefit in
    >> a world where IE support is normally expected (and
    >> sometimes sufficient).

    >
    > It's meant as a free codebase. I've seen nothing really
    > that does all desktop-environment stuff in a short, free,
    > clear fashion. Most is heavy or proprietary, or both, and
    > most try to reinvent the wheel.


    There is the dilemma; if you attempt to anticipate and provide all that
    an application may need the result will be 'heavy', and much of what is
    included will be unnecessary in any real application, but so long as it
    is omitted all you have is a demonstration that it is possible to drag
    and re-size IFRAMEs in a container of some sort on a particular set of
    browsers.

    >> > or contribute.

    >>
    >> You don't appear to be someone who takes advice, so
    >> anything approaching collaboration is out of the question.

    >
    > I appreciate your advice, even if you don't like what I do
    > with it. I happen to consider that what "works" is very
    > important.


    My long experience of people declaring that something "works" or
    "doesn't work" on this group has diminished the significance of the
    word. So many things "work", by some criteria or another, that 'works'
    is barely the starting point for a choice of implementation strategies.

    Much of the time people are declaring things to 'work' only because they
    have not tested them vigorously/seriously. Indeed you don't seem to have
    tried stressing your code much, as the two megabyte memory leak in IE
    per window instance should have become evident once you had opened and
    closed 100 windows or so.

    > Javsacript specs are what browsers should implement, but
    > actual browser support is what programmers need to worry
    > about.


    The two are far too interrelated for the specifications to be dismissed
    in favour of studying implementations (assuming you had access to, and
    time to study, all browser implications). As far as the javascript
    specification is concerned the implementations that assert that they
    comply with ECMA 262 actually have very few deviations from the
    specification (and mostly insignificant ones) so knowing how a
    javascript engine should be expected to behave is a very good guide to
    99%+ of the actual behaviour of implementations, including the ones that
    are unavailable for actual testing.

    > It seems that moving windows around by reference rather
    > than ID would be a speed improvement and probably slightly
    > less code,


    As in general whenever you can pass, access or store a string value you
    can also pass, access or store an object reference the use of string
    references just adds a layer of needless complexity and a runtime
    overhead.

    > so you can rest-assured my application will reflect this
    > when I next have a play with it.


    OK, but doesn't that make you suspect "all you need to know to ..."

    > I don't respond to authority though. Never have, never will


    Not even to listen?

    > (unless you're paying me).


    In the event of needing more javascript programmers I would be looking
    for someone with more practical experience (though it would not be me
    paying anyway, just interviewing).

    Richard.
     
    Richard Cornford, Aug 10, 2006
    #15
  16. Brian D

    darwinist Guest

    Richard Cornford wrote:
    > darwinist wrote:
    > > Richard Cornford wrote:

    > <snip>
    > >> The example you gave was an example that required each
    > >> optgroup element to have and ID, that would be the
    > >> wrong thing to do.

    > <snip>
    >
    > So you did, sorry. Weren't we discussing the clarity/readability of
    > javascript source code recently?
    >
    > <snip>
    > >>> For example:
    > >>> http://darwinist.googlepages.com/htmldesktop.html
    > >>>
    > >>> Feel free to criticise
    > >>
    > >> You have never actually said what this thing is supposed to
    > >> be for.

    > >
    > > It's to demonstrate all you need to know to start making
    > > your own web-based desktop system, or any subset thereof
    > > (a windowed-based application, for example).

    >
    > Now there is a frightening notion.


    Then you are easily frightened.

    > I didn't look at your actual code too
    > much,


    This much is obvious from the rest of the post. Your criticisms have
    some merit, but they would have taken as long to write (even for a fast
    typist, which I assume you are), as reading the majority of the
    application in question. There is no need for you to read it, except
    that your arguments would have better aim, and probably would have been
    shorter as a result.

    > I just verified that it did have the serious memory leak I was
    > expecting on IE, did not address the select element issue, and that you
    > could not drag one window over the contents of another because the mouse
    > co-ordinates were not available in the containing frame (that is, it
    > failed on the three primary issues of an in browser 'windowing' system
    > in IE). I suspect that much else that would be useful in any actual
    > application would also be missing, such as an ability for code executing
    > in a 'window' to respond to window dragging, re-sizing, closing and
    > focusing (moving to the front) actions.


    Those could be useful and aren't precluded or made overly difficult by
    imposing a complex framework, like some html windowing packages do. As
    I said it is to demonstrate all you need to know to start making one
    yourself. A lot of people who want to make web applications don't have
    the encyclopedic knowledge of the specifications that you do, and
    access to an encyclopedia isn't quite the same thing.

    > > It's far from perfect but it includes all
    > > basic functionality required, plus an "immediate"
    > > box, and a manual.
    > >
    > >> It looks like it is indented to be the bases for an
    > >> in-browser windowing system for web-applications. It
    > >> doesn't look capable enough for any actual example of
    > >> such,

    > >
    > > Under Help->Examples there are several working examples
    > > for making windows, making objects draggable, a hello
    > > world program, etc.

    >
    > There is quite a gap between 'hello world' and a web application
    > multi-facetted enough to warrant a windowing GUI.


    "Hello World" is only the first example, as it should be. The basic
    functionality of organising things in separate windows is not that
    demanding on a browser, and a lot of basic web-applications could
    benefit from it.

    I'm sure you could make a better one that is free and even more
    lightweight and efficient, but where is it?

    > > Also the windowing system itself works, as does the
    > > desktop.
    > >
    > >> but I suppose could be extended for specific
    > >> applications. However, as it is only really suited
    > >> for Mozilla/Gecko browsers as it stands

    > >
    > > There isn't any browser-specific code, and although it's
    > > not coded to an apparently well-known ie bug,

    >
    > At least two well known IE bugs, but the number doesn't matter as any
    > one is sufficient to make the result viable for use on Windows IE only
    > Intranets, or multi-browser Intranets that include IE (i.e. the actual
    > market) for as long as your "I'm not particularly interested in coding
    > to the bugs of a product whose manufacturers don't even pretend it's
    > good anymore" stands.


    Do you know if they've fixed it in ie 7?

    > > it's fairly lightweight and quite
    > > responsive in either major browser.

    >
    > Maybe as it stands, but an actual application would be expected to have
    > something going on in those windows, which is what will slow the total
    > down.


    Most of the content can be organised in separate documents in iframes,
    which the browsers seem remarkably adept at handling. The windowing is
    just for more versatile organisation.

    > (Incidentally "either major browser" sounds like the 'both browsers'
    > attitude prevalent at the end of the last century.)


    You're right, I'm not sure what the opera problem is but I think it's
    an opera bug.

    > >> I don't see it being of much practical benefit in
    > >> a world where IE support is normally expected (and
    > >> sometimes sufficient).

    > >
    > > It's meant as a free codebase. I've seen nothing really
    > > that does all desktop-environment stuff in a short, free,
    > > clear fashion. Most is heavy or proprietary, or both, and
    > > most try to reinvent the wheel.

    >
    > There is the dilemma; if you attempt to anticipate and provide all that
    > an application may need the result will be 'heavy', and much of what is
    > included will be unnecessary in any real application, but so long as it
    > is omitted all you have is a demonstration that it is possible to drag
    > and re-size IFRAMEs in a container of some sort on a particular set of
    > browsers.


    You may be surprised how much of a struggle it can be to a novice
    javascript programmer. Just the individual techniques required are
    popular "how to" articles all over the web. Having given liberal
    comments my attempt was to draw together a set of practical how-tos. I
    can see as a connoisseur of the language you are holding your nose up
    at it.

    > >> > or contribute.
    > >>
    > >> You don't appear to be someone who takes advice, so
    > >> anything approaching collaboration is out of the question.

    > >
    > > I appreciate your advice, even if you don't like what I do
    > > with it. I happen to consider that what "works" is very
    > > important.

    >
    > My long experience of people declaring that something "works" or
    > "doesn't work" on this group has diminished the significance of the
    > word. So many things "work", by some criteria or another, that 'works'
    > is barely the starting point for a choice of implementation strategies.


    Indeed my standard should have been stated more explicitly. Two main
    browsers = as much of the desktop-share as any program written for any
    specific operating system could hope to reach, maybe more.

    > Much of the time people are declaring things to 'work' only because they
    > have not tested them vigorously/seriously. Indeed you don't seem to have
    > tried stressing your code much, as the two megabyte memory leak in IE
    > per window instance should have become evident once you had opened and
    > closed 100 windows or so.


    Maybe I should just declare my bias and write "runs best in firefox,
    you broken-software using cretins", and put a link to download firefox
    on the page for anyone in danger of these bugs affecting them. At least
    it's free and will probably run on their operating system, if they're
    allowed to install it.

    > > Javsacript specs are what browsers should implement, but
    > > actual browser support is what programmers need to worry
    > > about.

    >
    > The two are far too interrelated for the specifications to be dismissed
    > in favour of studying implementations (assuming you had access to, and
    > time to study, all browser implications). As far as the javascript
    > specification is concerned the implementations that assert that they
    > comply with ECMA 262 actually have very few deviations from the
    > specification (and mostly insignificant ones) so knowing how a
    > javascript engine should be expected to behave is a very good guide to
    > 99%+ of the actual behaviour of implementations, including the ones that
    > are unavailable for actual testing.


    Specifications are one half of what will work, the other half is what
    has in fact been implemented in enough popular browsers to rely on it
    in the wild.

    > > It seems that moving windows around by reference rather
    > > than ID would be a speed improvement and probably slightly
    > > less code,

    >
    > As in general whenever you can pass, access or store a string value you
    > can also pass, access or store an object reference the use of string
    > references just adds a layer of needless complexity and a runtime
    > overhead.


    Thanks for the tip.

    > > so you can rest-assured my application will reflect this
    > > when I next have a play with it.

    >
    > OK, but doesn't that make you suspect "all you need to know to ..."


    Finish the sentence you are quoting.

    > > I don't respond to authority though. Never have, never will

    >
    > Not even to listen?


    I'll listen to anyone, you don't have to pretend you're the arbiter of
    correct javascript.

    > > (unless you're paying me).

    >
    > In the event of needing more javascript programmers I would be looking
    > for someone with more practical experience (though it would not be me
    > paying anyway, just interviewing).


    Oh I just meant I'll take orders for money (within reason), but I've
    got too many jobs right now, in order to get as much of that experience
    you mention, as possible.

    As you can probably tell I'm not a js programmer anyway, it's just one
    of the many languages you have to use when dealing with php.

    > Richard.
     
    darwinist, Aug 12, 2006
    #16
  17. darwinist wrote:
    > Richard Cornford wrote:
    >> darwinist wrote:
    >>> Richard Cornford wrote:

    <snip>
    >>>> You have never actually said what this thing is
    >>>> supposed to be for.
    >>>
    >>> It's to demonstrate all you need to know to start
    >>> making your own web-based desktop system, or any
    >>> subset thereof (a windowed-based application, for

    >> example).
    >>
    >> Now there is a frightening notion.

    >
    > Then you are easily frightened.


    Or maybe I am familiar with the harm that follows form over-confidence
    that it is a common symptom of individuals who have got beyond the
    initial stages of starting to learn javascript, but mistake the ability
    to make things that broadly 'work' for knowing javascript.

    >> I didn't look at your actual code too
    >> much,

    >
    > This much is obvious from the rest of the post. Your
    > criticisms have some merit, but they would have taken
    > as long to write (even for a fast typist, which I assume
    > you are), as reading the majority of the application in
    > question. There is no need for you to read it, except
    > that your arguments would have better aim, and probably
    > would have been shorter as a result.


    Elsewhere we have discussed the readability of source code. I looked at
    your source code and the prospect of attempting to read it did not
    appeal.

    However, it is only really necessary to consider attempting to
    understand a third party script is there is some prospect that it may be
    useful in some way. Having verified that it did not satisfy basic
    criteria for the stated task any additional attention directed towards
    it would be wasted.

    >> I just verified ... serious memory leak ... select
    >> element issue, and ... could not drag one window over
    >> the contents of another ...

    <snip>
    > Those could be useful and aren't precluded or made overly
    > difficult by imposing a complex framework, like some html
    > windowing packages do. As I said it is to demonstrate all
    > you need to know to start making one yourself. A lot of
    > people who want to make web applications don't have the
    > encyclopedic knowledge of the specifications that you do,
    > and access to an encyclopedia isn't quite the same thing.


    The knowledge and level of understanding someone should possess prior to
    attempting the creation of a complex web application may be subject to
    some debate, but not knowing how to position, move and size Element, and
    nest an IFRAME within them, strikes me as not knowing enough. But it
    would not be the absence of that specific knowledge that I would worry
    about, rather the grasp of the bigger picture that could be expected to
    come with acquiring that knowledge. You don't get from novice to someone
    who should be allowed to work on web applications by being handled "all
    you need to know" as pre-written code.

    <snip>
    >>>> It looks like it is indented to be the bases for an
    >>>> in-browser windowing system for web-applications. It
    >>>> doesn't look capable enough for any actual example of
    >>>> such,
    >>>
    >>> Under Help->Examples there are several working examples
    >>> for making windows, making objects draggable, a hello
    >>> world program, etc.

    >>
    >> There is quite a gap between 'hello world' and a web
    >> application multi-facetted enough to warrant a windowing
    >> GUI.

    >
    > "Hello World" is only the first example, as it should be.
    > The basic functionality of organising things in separate
    > windows is not that demanding on a browser, and a lot of
    > basic web-applications could benefit from it.


    If you look at the current situation in web development you see a very
    large number of people attempting to make AJAX web sites, seemingly only
    because they can (and particularly because others have created
    frameworks for them that make it even easier). This is the power of
    fashion and the AJAX buzzword.

    There is going to be a bit of an anti-AJAX back-lash soon, as was
    indicated by an article in the (UK) Financial Times earlier in the week
    about the security vulnerabilities (various forms of script insertion)
    introduced by AJAX (none really introduced by AJAX as they all existed
    before, but certainly all exposed more often by a growth in people
    writing public sites that use AJAX). That article essentially blamed web
    developers for increasingly using a technology that they did not
    understand well enough to cover the security aspects of, and framework
    authors for shielding them from that understanding.

    Which is not to say that AJAX applications should not be created, it is
    an ideal technology for Intranet applications and special purpose web
    applications. But in many (probably most) cases doing something because
    you can is not a good reason for doing it. For a start it goes against
    the KISS principle (and when you don't understand the technology you are
    using it is difficult to justify labelling the result 'simple') as much
    of what has recently been done with AJAX had previously, and more
    simply, been done with server-side technology. And then there is the
    impact upon reliability, where an AXAX e-commerce site I looked at
    recently was so tied up in technology that its author did not actually
    understand that the result did not even work with non-default
    installations of IE 6. Costing the owners of the site (who presumably
    paid for it in good faith) an indeterminate proportion of their
    potential income, where the traditional server-based approach to
    e-commerce would have allowed them to take money of all their potential
    customers (and an AJAX with clean degradation design would have allowed
    them to have their cake and eat it too).

    Some web applications would benefit from an in-browser windowing system
    (I am working on one myself at the moment), but using one because you
    can is likely to directly result in issues.

    > I'm sure you could make a better one that is free and
    > even more lightweight and efficient, but where is it?


    If someone is about to shoot themselves in the foot handing them a
    bigger gun is not doing them a favour.

    <snip>
    >> At least two well known IE bugs, but the number doesn't
    >> matter as any one is sufficient to make the result viable
    >> for use on Windows IE only Intranets, or multi-browser
    >> Intranets that include IE (i.e. the actual market) for as
    >> long as your "I'm not particularly interested in coding to
    >> the bugs of a product whose manufacturers don't even pretend
    >> it's good anymore" stands.

    >
    > Do you know if they've fixed it in ie 7?


    I don't know, but it is unlikely that they would all be fixed (IE 7 is
    not a major re-write it is a series of bug fixes and tweaks and some of
    those issues are so inherent in the architecture of IE that they would
    take a major re-write to actually fix). But it doesn't' matter as IE 7
    is only going to be available for XP and 2003 (and presumably
    Microsoft's new OS) so it will take even longer for it to becomes
    dominate than the couple of years it took IE 6 to outstrip IE 5.

    >> > it's fairly lightweight and quite
    >> > responsive in either major browser.

    >>
    >> Maybe as it stands, but an actual application would be
    >> expected to have something going on in those windows, which
    >> is what will slow the total down.

    >
    > Most of the content can be organised in separate documents
    > in iframes, which the browsers seem remarkably adept at
    > handling. The windowing is just for more versatile organisation.


    That will not make a significant difference to the way IE slows down
    when you accumulate thousands of objects in the system.

    <snip>
    >>> It's meant as a free codebase. I've seen nothing really
    >>> that does all desktop-environment stuff in a short, free,
    >>> clear fashion. Most is heavy or proprietary, or both, and
    >>> most try to reinvent the wheel.

    >>
    >> There is the dilemma; if you attempt to anticipate and
    >> provide all that an application may need the result will
    >> be 'heavy', and much of what is included will be unnecessary
    >> in any real application, but so long as it is omitted all
    >> you have is a demonstration that it is possible to drag and
    >> re-size IFRAMEs in a container of some sort on a particular
    >> set of browsers.

    >
    > You may be surprised how much of a struggle it can be to a
    > novice javascript programmer.


    Why, it is inevitable that I would have been a novice javascript
    programmer myself at some point in the past?

    > Just the individual techniques required are
    > popular "how to" articles all over the web. Having
    > given liberal comments my attempt was to draw together a
    > set of practical how-tos. I can see as a connoisseur of
    > the language you are holding your nose up at it.


    One of the consequences of having been a novice myself is that I have
    some idea of what path leads from there to some sort of understanding of
    the subject.

    <snip>
    >>> ... . I happen to consider that what "works" is very
    >>> important.

    >>
    >> My long experience of people declaring that something "works" or
    >> "doesn't work" on this group has diminished the significance of the
    >> word. ...

    <snip>
    > Indeed my standard should have been stated more explicitly.
    > Two main browsers =


    But not sufficiently well in IE for actual applications.

    > as much of the desktop-share as any program written
    > for any specific operating system could hope to reach,
    > maybe more.
    >
    >> Much of the time people are declaring things to 'work' only because
    >> they have not tested them vigorously/seriously. Indeed you don't
    >> seem to have tried stressing your code much, as the two megabyte
    >> memory leak in IE per window instance should have become evident
    >> once you had opened and closed 100 windows or so.

    >
    > Maybe I should just declare my bias and write "runs best in firefox,
    > you broken-software using cretins", and put a link to download firefox
    > on the page for anyone in danger of these bugs affecting them. At
    > least it's free and will probably run on their operating system, if
    > they're allowed to install it.
    >
    >>> Javsacript specs are what browsers should implement,
    >>> but actual browser support is what programmers need
    >>> to worry about.

    >>
    >> The two are far too interrelated for the specifications
    >> to be dismissed in favour of studying implementations
    >> (assuming you had access to, and time to study, all
    >> browser implications). As far as the javascript
    >> specification is concerned the implementations that
    >> assert that they comply with ECMA 262 actually have
    >> very few deviations from the specification (and mostly
    >> insignificant ones) so knowing how a javascript engine
    >> should be expected to behave is a very good guide to
    >> 99%+ of the actual behaviour of implementations,
    >> including the ones that are unavailable for actual
    >> testing.

    >
    > Specifications are one half of what will work,


    Specifications are what should work, and how it should work.

    > the other half is what has in fact been implemented
    > in enough popular browsers to rely on it in the wild.


    That is the attitude that gets in the way of ever being able to write
    cross-browser code.

    >>> It seems that moving windows around by reference rather
    >>> than ID would be a speed improvement and probably slightly
    >>> less code,

    >>
    >> As in general whenever you can pass, access or store a
    >> string value you can also pass, access or store an object
    >> reference the use of string references just adds a layer
    >> of needless complexity and a runtime overhead.

    >
    > Thanks for the tip.
    >
    >>> so you can rest-assured my application will reflect this
    >>> when I next have a play with it.

    >>
    >> OK, but doesn't that make you suspect "all you need to know
    >> to ..."

    >
    > Finish the sentence you are quoting.

    <snip>

    You don't se the logic in questioning "all you need to know" when
    additional information suggests changes?

    Richard.
     
    Richard Cornford, Aug 12, 2006
    #17
    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. Matt
    Replies:
    2
    Views:
    223
    Roland Hall
    Jan 11, 2004
  2. SAN CAZIANO
    Replies:
    1
    Views:
    122
    Grant Wagner
    Nov 25, 2004
  3. Replies:
    1
    Views:
    160
  4. Pascal Ehlert
    Replies:
    6
    Views:
    96
    Pascal Ehlert
    Jan 18, 2008
  5. Pascal Ehlert
    Replies:
    19
    Views:
    192
    Thomas 'PointedEars' Lahn
    Jan 21, 2008
Loading...

Share This Page