- From: Lauren Wood <lauren@sqwest.bc.ca>
- Date: Tue, 28 Jul 1998 14:44:27 -0700
- To: www-dom@w3.org
At 28/07/98 02:31 PM , keshlam@us.ibm.com wrote: >Of course there's always the other approach to resolving the conflict: Is >it Really Necessary that NodeList be "live"? How often is this going to >matter, and is it in fact the behavior you want (as opposed to requesting a >new NodeList when you know that changes have been made that you need to >respond to)? The main reason for making NodeList live is so that scripts can start accessing the document while it's still being loaded, and not have to poll the NodeList every so often to see if there are now five H3's in the document where only three had turned up before. It's not meant to be the solution to multi-threading problems; in fact Level 1 assumes that only one thread at a time can access the document so that you are in charge of everything that changes (apart from the process loading in the document which can't delete anything or move it around). >On a slightly different note, here's a suggestion from a friend: Have you >considered picking up some of the Model/View/Controller ideas and applying >them to the DOM? Specifically, it might make sense to add the ability to >register some flavor(s) of TreeChangeListener, which would be called when >the relevant portion of the document was altered. That will become >especially necessary when you start dealing with multiple access, and >particularly if the integer indices are preserved -- you'll have to know >what happened in order to adjust those appropriately. We've talked a bit about MVC and I'm sure we'll talk more about it when we get to multi-threading. Feel free to remind us when we get closer - we'll be doing our best to keep this mailing list up to date with what we're working on so that we get to pick all of your brains about the best ways to do things. Lauren
Received on Tuesday, 28 July 1998 17:44:12 UTC