On Thu, Oct 9, 2008 at 6:50 PM, Jason Bunting <[EMAIL PROTECTED]> 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.
There is no specification on this, it is just kind of what you'd expect. Why would otherwise the parent node be an input parameter? If the result is constant, no parameter in the world can change that. > 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. I wasn't thinking about widgets, but rather situations were you'd added a dom() method to various other objects. For convenience. >> 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. I shouldn't start an OO discussion here, but in my opinion the fields in an object are all public unless names are prefixed with an "_". > 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 > ... Ehm... The proposed MochiKit.Widget isn't "an entire widget framework". I just pointed at it for example, not to force you to change your code or your ways. I don't oppose changing there MochiKit.DOM functions, I'm just of the opinion that it isn't much of a problem. And if it is, I'd suggest that we check typeof(o.dom) == "object" or something. So that we know for sure that what is being removed is an existing DOM node, not something that was created by our call to o.dom()... Also, doing that would increase our compability with Dojo et al. Cheers, /Per --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
