[Javascript] OOP and the DOM

Cutter (JS Related) java.script at cutterscrossing.com
Thu Oct 18 20:55:59 CDT 2007


And, in the scenario you've played out (links to categories, sub-cats, 
etc.) you could probably seriously benefit from looking at JQuery. 
Small, fast, and a lot already under the hood to simplify this stuff. 
Define each 'category' within it's own parent container with a unique 
ID, and applying toggle functionality to each <a> element of that 
parent. That's a little simplified, but not by much.

Steve 'Cutter' Blades
Adobe Certified Expert
Advanced Macromedia ColdFusion MX 7 Developer
____________
http://blog.cutterscrossing.com

"The best way to predict the future is to help create it"



Scott Reynen wrote:
> On Oct 17, 2007, at 7:02 AM, girzel wrote:
>
>   
>> I have a relatively good grasp of OOP, via Python, and also a basic
>> familiarity with using Javascript for doing 'stupid web tricks'. I'd
>> like to deepen my understanding of Javascript so I can put it to more
>> complex uses, but I'm a little confused about the connection between
>> Javascript's OOP aspects, and its interaction with the DOM.
>>     
>
> Every DOM node is an object.
>
>   
>> Specifically, to what extent does a regular DOM node 'grab' like node
>> = d.getElementsByID('myDiv') correspond to the creation of an object?
>>     
>
> I'm assuming you meant getElementById.  That returns an object.  How  
> that object interacts with the DOM's internal representation differs  
> between implementations, and is abstracted by it being an object.
>
>   
>> If I've created my own classes which are meant to correspond to
>> elements of the DOM, are they very closely tied together (ie as
>> object references), or do they merely copy values from the elements?
>>     
>
> They are very closely tied together.  Changes you make to an object  
> returned from getElementById will effect the DOM almost instantly.
>
>   
>> I've read that the DOM as a whole is a single object, does that mean
>> that specific elements/nodes are only attributes of the DOM object?
>>     
>
> No.  That means every document has one object, conveniently named  
> "document", which models the document.  One might call it a document  
> object model.  But that object can produce other objects,  
> representing individual nodes.
>
>   
>> My practical situation: I have a webpage with a giant list of links,
>> and a smaller list which represents categories to which those links
>> might belong. Clicking categories in the category list 'disappears'
>> links which don't belong to that category, so that you can filter the
>> giant link list by clicking on one or more categories.
>>
>> Right now this is done by re-parsing the link list every time a
>> category is toggled on or off. I thought I could move some of the
>> heavy lifting to onLoad time, by creating a Category class
>> corresponding to the category toggles, and having each instantiation
>> search out the links which 'belong' to it and put them in an array.
>> Then, when the category is clicked, it already 'knows' which links to
>> disappear or not disappear.
>>     
>
> Sounds good.
>
>   
>> I don't really know if this will actually run faster than my present
>> setup.
>>     
>
> That's rather browser-specific, but it will most likely run faster.
>
>   
>> I also don't know if it's possible to 'actually' connect the
>> class instances to the DOM elements: would a Category class have a
>> this.element = d.getElementsByID() attribute in it?
>>     
>
> Yes.  But the DOM itself is already indexing every node ID, so this  
> isn't likely much if any optimization.  Your real efficiency  
> improvements will likely be in picking out the links in advance, as  
> it's unlikely the links are pre-indexed automatically.
>
> Peace,
> Scott
>
> _______________________________________________
> Javascript mailing list
> Javascript at lists.evolt.org
> http://lists.evolt.org/mailman/listinfo/javascript
>   



More information about the Javascript mailing list