Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 11 of 11
  1. #1
    Regular Coder
    Join Date
    Apr 2003
    Location
    Atlanta, GA
    Posts
    487
    Thanks
    0
    Thanked 0 Times in 0 Posts

    DOM too fast for Firebird? (long)

    Developing a ridiculously dynamic form, here's a temp copy: http://www.10mar2001.com/temp/formUI/ - the scripting is in this external file: http://www.10mar2001.com/temp/formUI/formUI.js

    I'd like to draw your attention to the Delete member button. It's kind of nasty what's going on back there behind the scenes, but when it's clicked, I perform these steps:
    - Detect which button was clicked (by parsing its ID)
    - Delete the row that button's in
    - Loop over the rows in the table after the one that was deleted (including the one that takes its place)
    - During the loop, rename the button so that its ID parsing will trigger the delete of the proper row (i.e., the one it's in)

    This is probably just as convoluted as it sounds, but I haven't really been able to figure out a better way to provide this kind of dynamicism on a form. If you've got a suggestion, I'm open to it.

    It works just fine in IE6 (I'm not trying to make it work in anything lower, just it and Firebird .7 at this point), but in Firebird, this happens:

    (First, you may wish to click the Add member button a few or several times.) When you first delete a row, it's all fine and dandy, and renames the elements exactly right. The second time you click a delete button, its row is deleted, but the elements which are told to be renamed are not renamed. The third time a delete button is clicked, each button which should be renamed just loses its text, nothing more. Once a button has no text in it, if it's clicked, its row is deleted, and no renaming happens.

    I have not coded this for IE. I have not coded this for *any* browser, and I believe my scripting reflects that. I have some IE-specific workarounds, because of its lack of DOM2 event use and its oddness regarding the dblclick event, but other than that, it should be perfectly fine.

    Has anyone else seen this kind of thing happen in Firebird?

    edited to add: Though I hadn't tried it in Opera 7 before I posted, I haven't changed a thing and it works like a freakin' charm. Why Firebird? What have I done?
    Last edited by Choopernickel; 12-17-2003 at 07:23 PM.

  • #2
    Regular Coder
    Join Date
    Jun 2002
    Posts
    338
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Hmmm...well, it worked once for me when I deleted a row, but when I deleted a second row, it crashed the browser. I'm running Firebird 0.6.1.

  • #3
    Regular Coder
    Join Date
    Apr 2003
    Location
    Atlanta, GA
    Posts
    487
    Thanks
    0
    Thanked 0 Times in 0 Posts
    ...uh, ouch?

    I don't think I still have .61 installed, but I'll look around and give it a shot there.

    Sorry about that.

    Edit:
    Found .60 and .61 on my system, and yes, it crashes them both. What the huh? Also crashes Mozilla 1.4, but not Netscape 7.01 (same bugs experienced). Again: What the huh?

    by build date:
    20021120 (Netscape 7.01) - buggy
    20030516 (Firebird .6) - crash
    20030529 (Mozilla 1.4) - crash
    20030728 (Firebird .61) - crash
    20031007 (Firebird .7) - buggy

    Odd, isn't it? Time to search bugzilla.
    Last edited by Choopernickel; 12-17-2003 at 08:07 PM.

  • #4
    Master Coder
    Join Date
    Feb 2003
    Location
    UmeŚ, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    No errors, no exceptions in moz1.5. Behaves as you described. If I were you, I'd try to avoid this clumsy method you've built, and instead rely on an array. First of all, you can use separate creation and member numbers. If you have running creation numbers, you can let the member numbers map to a creation number, and use that when you change the array.

    Start with five members, for example:

    [0,1,2,3,4]

    Then, you delete member '2' (3rd entry) using splice.

    [0,1,3,4]

    Then you add three new members:

    [0,1,3,4,5,6,7]

    You delete 6

    [0,1,3,4,5,7]

    etc. That way, you easily keep track of them without having to go through each entry in the list to rename them.
    Don't let the DOM do the majority of the work. Do the thinking in JavaScript, and then change only what is required in the DOM. You needn't change the ids, thay are good as they are. Use a running cretion number. However, use a member number that depends on the actual position in the members list, as specified by the array index. It's much less of a headache if you do.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

  • #5
    Regular Coder
    Join Date
    Apr 2003
    Location
    Atlanta, GA
    Posts
    487
    Thanks
    0
    Thanked 0 Times in 0 Posts
    I think I see what you mean, liorean, but how then when I click a button will I know which row to get rid of? In my experience, one of the most painful things to script is a walk *up* the tree from some child to some ancestor.

    Basically, what I need to do is decouple the counting from the deleting. I can let my server-side processing handle the real number counting, I guess; the problem with that will be telling it when to finally stop. Regardless, I see much much difficulty in trying to figure out which row contains the delete button I just clicked.

    Recommendations?

  • #6
    Master Coder
    Join Date
    Feb 2003
    Location
    UmeŚ, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    I don't see any troubles with it, really. you just do an easy traversal:
    Code:
    function getRow(oElm){
        return ( /^tr$/i.test(oElm.tagName)?
            oElm:
            getRow(oElm.parentNode));
    }
    which you call with this as the argument, from the event handler. It will return your row, nice and simple.
    Last edited by liorean; 12-17-2003 at 09:56 PM.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

  • #7
    Regular Coder
    Join Date
    Apr 2003
    Location
    Atlanta, GA
    Posts
    487
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Is it just me or does that look like it would cause infinite recursion? And are the parinthesis unmatched?

  • #8
    Master Coder
    Join Date
    Feb 2003
    Location
    UmeŚ, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    Yeah, I saw that now. Fixed as I intended it.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

  • #9
    Regular Coder
    Join Date
    Apr 2003
    Location
    Atlanta, GA
    Posts
    487
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Okay, so it's coming along. I really appreciate your help on this.
    *bows down*

    I've still got to figure out which row numerically (via counter or index) was/is-to-be removed, in order to properly splice out the correct pointer in the array. What kind of trick do you have up your sleeve for that?

  • #10
    Master Coder
    Join Date
    Feb 2003
    Location
    UmeŚ, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    Simple - the button will have a running number/id taken from the creation numbering, right? Use that number/id to search through the array and splice out the one which matches the value. How best to do this will depend a little on what else you might want to use the running number, the order number, or the name.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

  • #11
    Regular Coder
    Join Date
    Apr 2003
    Location
    Atlanta, GA
    Posts
    487
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Fantastic. I've got almost all of it figured out now.

    I'm down to the more complex element creation/deletion stuff: nested sets. The demo before was very stripped down compared with what I'm actually doing. Now it's fleshed out to show the entire deal. I'll refer you to the same page as before, with the script also in the same place as before.

    IE 6 and Opera 7 handle the scripts seamlessly. Firebird .6 and .61 still crash.

    In Firebird .7, for some reason, when the first method is deleted, its arguments stick around. No other method does this. The code that doesn't always work is this right here:
    Code:
    var methodSet = document.getElementById('methods').getElementsByTagName('tbody')[0],
        toDelete = getRow(e.target);
    methodSet.removeChild(toDelete.nextSibling); // this method's arguments
    methodSet.removeChild(toDelete);             // this method
    I can't imagine why it would work on all but the first method. The arguments work, (AFAIK) though I'm not exactly sure why, seeing as the array indexing stuff is getting pretty ridiculous.

    Any ideas?

    edit: browser clarification

    edit: Yes, the problem is with the nextSibling property: it doesn't want to read the ...next sibling of the row to delete. I started the week fairly fully haired; now, not so much.

    final edit: All I had to do was collapse the </tr><tr> tags between the first method and its arguments, then call normalize() on the parent in the script before I tried to delete the nextSibling. I think I'm starting to get the hang of this.


    Maybe.
    Last edited by Choopernickel; 12-18-2003 at 10:02 PM.


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •