[mochikit] Re: Why doesn't removeElement use the DOM Coercion rules?
That's it huh? No more discussion on this? I guess I am smoking crack... Jason -Original Message- From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jason Bunting Sent: Thursday, October 09, 2008 10:50 AM To: 'Per Cederberg'; 'MochiKit' Subject: [mochikit] Re: Why doesn't removeElement use the DOM Coercion rules? Per Cederberg wrote: Well... I think your case here is pretty uncommon. This is because the __dom__() function is really supposed to create a *new* DOM node. Otherwise people might run into issues when adding an object twice into the DOM tree. Excuse my ignorance, and permit me to ask a few questions so I can explore this further... Line item 6 in the DOM Coercion Rules, as posted in the documentation, states: 6. Objects that have a .dom(node) or .__dom__(node) method are called with the parent node and their result is coerced using these rules. So, perhaps there is some confusion because of the documentation, but I don't see how my example code violates anything. I am confused by your statement that Otherwise people might run into issues when adding an object twice into the DOM tree - using my example, if someone were to try to add myWidgetInstance to the DOM twice, the behavior would be exactly as I would expect it - it is the same instances, and thus it would only appear once (because the call to __dom__ would return the same instance). If the developer doesn't understand that this would happen, then they have other problems. Unless they instantiate another instance, there should only be one. But sure, there is an inconsistency here. My suggestion would be to just work around it instead: removeElement(myWidgetInstance.widgetDomRepresentation); IMO, that's terrible. It breaks encapsulation because now something that should be private is made explicitly public. I don't want a workaround, I want consistency in MochiKit's API. Actually, other widget libraries tend to use the magic dom property for storing the root DOM node in the widget. Personally, I'd recommend using a mixin approach to widgets, just as I've done in the suggested MochiKit.Widget library: http://github.com/cederberg/mochikit- patches/tree/master/MochiKit/Widget.js I appreciate your comments, and while an API for widget building may provide some useful help, it isn't what I am looking for at the moment. The way I have built widgets up to now (successfully, and for quite a while) is pretty much the way my example implies. It works beautifully and is simple enough to be understood without an entire widget framework (notwithstanding the fact that some help from using one might eventually be better than my approach). I would simply like some consistency in the API - the following functions all use the DOM Coercion Rules: appendChildNodes insertSiblingNodesBefore insertSiblingNodesAfter createDOM replaceChildNodes ... If those do, so should any of the others that expect DOM elements: removeElement swapDOM ... If this is merely work that needs to be done, I would be willing to do it. I simply want to see if and why others don't see the inconsistencies that I do. Thanks again, Jason Bunting On Thu, Oct 9, 2008 at 1:01 AM, Jason Bunting [EMAIL PROTECTED] wrote: I don't know if I am up in the night on this or if it is an oversight, but why doesn't removeElement use the DOM Coercion rules in the same way that something like appendChildNodes does? Here's some sample code that illustrates my problem: function MyWidget() { var widgetDomRepresentation = DIV({style:border:solid 1px}, Hi!); var that = this; connect(widgetDomRepresentation, onclick, function() { signal(that, removeme); }); this.__dom__ = function() { return widgetDomRepresentation; }; } var myWidgetInstance = new MyWidget(); connect(myWidgetInstance, removeme, function() { removeElement(myWidgetInstance); // this blows up }); appendChildNodes(currentDocument().body, myWidgetInstance); It seems to make little sense that one can append myWidgetInstance to the DOM using MochiKit.DOM functions, but can't remove it just as easily. Am I missing something here? Jason Bunting No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.7.6/1716 - Release Date: 10/9/2008 9:44 AM No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.7.6/1716 - Release Date: 10/9/2008 9:44 AM --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this
[mochikit] Re: Why doesn't removeElement use the DOM Coercion rules?
If you'd like to fix it then I don't see why the patch would be rejected. On Fri, Oct 10, 2008 at 7:57 PM, Jason Bunting [EMAIL PROTECTED] wrote: That's it huh? No more discussion on this? I guess I am smoking crack... Jason -Original Message- From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jason Bunting Sent: Thursday, October 09, 2008 10:50 AM To: 'Per Cederberg'; 'MochiKit' Subject: [mochikit] Re: Why doesn't removeElement use the DOM Coercion rules? Per Cederberg wrote: Well... I think your case here is pretty uncommon. This is because the __dom__() function is really supposed to create a *new* DOM node. Otherwise people might run into issues when adding an object twice into the DOM tree. Excuse my ignorance, and permit me to ask a few questions so I can explore this further... Line item 6 in the DOM Coercion Rules, as posted in the documentation, states: 6. Objects that have a .dom(node) or .__dom__(node) method are called with the parent node and their result is coerced using these rules. So, perhaps there is some confusion because of the documentation, but I don't see how my example code violates anything. I am confused by your statement that Otherwise people might run into issues when adding an object twice into the DOM tree - using my example, if someone were to try to add myWidgetInstance to the DOM twice, the behavior would be exactly as I would expect it - it is the same instances, and thus it would only appear once (because the call to __dom__ would return the same instance). If the developer doesn't understand that this would happen, then they have other problems. Unless they instantiate another instance, there should only be one. But sure, there is an inconsistency here. My suggestion would be to just work around it instead: removeElement(myWidgetInstance.widgetDomRepresentation); IMO, that's terrible. It breaks encapsulation because now something that should be private is made explicitly public. I don't want a workaround, I want consistency in MochiKit's API. Actually, other widget libraries tend to use the magic dom property for storing the root DOM node in the widget. Personally, I'd recommend using a mixin approach to widgets, just as I've done in the suggested MochiKit.Widget library: http://github.com/cederberg/mochikit- patches/tree/master/MochiKit/Widget.js I appreciate your comments, and while an API for widget building may provide some useful help, it isn't what I am looking for at the moment. The way I have built widgets up to now (successfully, and for quite a while) is pretty much the way my example implies. It works beautifully and is simple enough to be understood without an entire widget framework (notwithstanding the fact that some help from using one might eventually be better than my approach). I would simply like some consistency in the API - the following functions all use the DOM Coercion Rules: appendChildNodes insertSiblingNodesBefore insertSiblingNodesAfter createDOM replaceChildNodes ... If those do, so should any of the others that expect DOM elements: removeElement swapDOM ... If this is merely work that needs to be done, I would be willing to do it. I simply want to see if and why others don't see the inconsistencies that I do. Thanks again, Jason Bunting On Thu, Oct 9, 2008 at 1:01 AM, Jason Bunting [EMAIL PROTECTED] wrote: I don't know if I am up in the night on this or if it is an oversight, but why doesn't removeElement use the DOM Coercion rules in the same way that something like appendChildNodes does? Here's some sample code that illustrates my problem: function MyWidget() { var widgetDomRepresentation = DIV({style:border:solid 1px}, Hi!); var that = this; connect(widgetDomRepresentation, onclick, function() { signal(that, removeme); }); this.__dom__ = function() { return widgetDomRepresentation; }; } var myWidgetInstance = new MyWidget(); connect(myWidgetInstance, removeme, function() { removeElement(myWidgetInstance); // this blows up }); appendChildNodes(currentDocument().body, myWidgetInstance); It seems to make little sense that one can append myWidgetInstance to the DOM using MochiKit.DOM functions, but can't remove it just as easily. Am I missing something here? Jason Bunting No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.7.6/1716 - Release Date: 10/9/2008 9:44 AM No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.7.6/1716 - Release Date: 10/9/2008 9:44 AM