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: [email protected] [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 group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~----------~----~----~----~------~----~------~--~---
