[mochikit] Re: Why doesn't removeElement use the DOM Coercion rules?
Ok, it's in r1430.
Cheers,
/Per
On Wed, Oct 15, 2008 at 10:30 PM, Jason Bunting
<[EMAIL PROTECTED]> wrote:
>
>
>> On Friday, October 10, 2008 at 11:33PM Bob Ippolito wrote:
>>
>>
>> If you'd like to fix it then I don't see why the patch would be rejected.
>>
>
> I assume that submitting patches through the mailing list is the way to go
> since I have seen so many already done this way, but if I need to submit it
> in some other way, please let me know.
>
> Also let me know if there is anything else I need to do or missed something
> or screwed up, etc. I appreciate the guidance.
>
> Thanks,
> Jason
>
>
> Index: DOM.js
> ===
> --- DOM.js (revision 1429)
> +++ DOM.js (working copy)
> @@ -640,7 +640,8 @@
>
> /** @id MochiKit.DOM.removeElement */
> removeElement: function (elem) {
> -var e = MochiKit.DOM.getElement(elem);
> +var self = MochiKit.DOM;
> +var e = self.coerceToDOM(self.getElement(elem));
> e.parentNode.removeChild(e);
> return e;
> },
> @@ -651,7 +652,7 @@
> dest = self.getElement(dest);
> var parent = dest.parentNode;
> if (src) {
> -src = self.getElement(src);
> +src = self.coerceToDOM(self.getElement(src), parent);
> parent.replaceChild(src, dest);
> } else {
> parent.removeChild(dest);
>
>
>
> Index: test_MochiKit-DOM.html
> ===
> --- test_MochiKit-DOM.html (revision 1429)
> +++ test_MochiKit-DOM.html (working copy)
> @@ -87,8 +87,11 @@
> is( d.getAttribute("value"), 'bar', "updateNodeAttributes updates value
> attribute" );
>
> var d = document.createElement('span');
> -appendChildNodes(d, 'word up', [document.createElement('span')]);
> -isDOM( d, 'word up', 'appendChildNodes' );
> +var widg = new (function(){ var domrep = SPAN(null, "foo");
> this.__dom__ = function(p){ return domrep; }; })();
> +appendChildNodes(d, 'word up', [document.createElement('span')], widg);
> +isDOM( d, 'word upfoo',
> 'appendChildNodes' );
> +removeElement(widg);
> +isDOM( d, 'word up', 'removeElement using DOM
> Coercion Rules' );
>
> replaceChildNodes(d, 'Think Different');
> isDOM( d, 'Think Different', 'replaceChildNodes' );
> @@ -163,9 +166,12 @@
>
> d = createDOM("span", null, "one", "two");
> swapDOM(d.childNodes[0], document.createTextNode("uno"));
> -isDOM( d, "unotwo", "swapDOM" );
> +isDOM( d, "unotwo", "swapDOM" );
> +var widg = new (function(){ var domrep = SPAN(null, "foo");
> this.__dom__ = function(p){ return domrep; }; })();
> +swapDOM(d.childNodes[0], widg);
> +isDOM( d, "footwo", "swapDOM using DOM
> Coercion Rules" );
>
> -is( scrapeText(d, true).join(" "), "uno two", "multi-node scrapeText"
> );
> +is( scrapeText(d, true).join(" "), "foo two", "multi-node scrapeText"
> );
> /*
>
> TODO:
>
>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
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
-~--~~~~--~~--~--~---
[mochikit] Re: Why doesn't removeElement use the DOM Coercion rules?
> On Friday, October 10, 2008 at 11:33PM Bob Ippolito wrote:
>
>
> If you'd like to fix it then I don't see why the patch would be rejected.
>
I assume that submitting patches through the mailing list is the way to go
since I have seen so many already done this way, but if I need to submit it
in some other way, please let me know.
Also let me know if there is anything else I need to do or missed something
or screwed up, etc. I appreciate the guidance.
Thanks,
Jason
Index: DOM.js
===
--- DOM.js (revision 1429)
+++ DOM.js (working copy)
@@ -640,7 +640,8 @@
/** @id MochiKit.DOM.removeElement */
removeElement: function (elem) {
-var e = MochiKit.DOM.getElement(elem);
+var self = MochiKit.DOM;
+var e = self.coerceToDOM(self.getElement(elem));
e.parentNode.removeChild(e);
return e;
},
@@ -651,7 +652,7 @@
dest = self.getElement(dest);
var parent = dest.parentNode;
if (src) {
-src = self.getElement(src);
+src = self.coerceToDOM(self.getElement(src), parent);
parent.replaceChild(src, dest);
} else {
parent.removeChild(dest);
Index: test_MochiKit-DOM.html
===
--- test_MochiKit-DOM.html (revision 1429)
+++ test_MochiKit-DOM.html (working copy)
@@ -87,8 +87,11 @@
is( d.getAttribute("value"), 'bar', "updateNodeAttributes updates value
attribute" );
var d = document.createElement('span');
-appendChildNodes(d, 'word up', [document.createElement('span')]);
-isDOM( d, 'word up', 'appendChildNodes' );
+var widg = new (function(){ var domrep = SPAN(null, "foo");
this.__dom__ = function(p){ return domrep; }; })();
+appendChildNodes(d, 'word up', [document.createElement('span')], widg);
+isDOM( d, 'word upfoo',
'appendChildNodes' );
+removeElement(widg);
+isDOM( d, 'word up', 'removeElement using DOM
Coercion Rules' );
replaceChildNodes(d, 'Think Different');
isDOM( d, 'Think Different', 'replaceChildNodes' );
@@ -163,9 +166,12 @@
d = createDOM("span", null, "one", "two");
swapDOM(d.childNodes[0], document.createTextNode("uno"));
-isDOM( d, "unotwo", "swapDOM" );
+isDOM( d, "unotwo", "swapDOM" );
+var widg = new (function(){ var domrep = SPAN(null, "foo");
this.__dom__ = function(p){ return domrep; }; })();
+swapDOM(d.childNodes[0], widg);
+isDOM( d, "footwo", "swapDOM using DOM
Coercion Rules" );
-is( scrapeText(d, true).join(" "), "uno two", "multi-node scrapeText"
);
+is( scrapeText(d, true).join(" "), "foo two", "multi-node scrapeText"
);
/*
TODO:
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
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
-~--~~~~--~~--~--~---
[mochikit] Re: Why doesn't removeElement use the DOM Coercion rules?
> On Saturday, October 11, 2008 at 2:50AM Per Cederberg wrote: > > > 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 could just as easily ask why the result of the call would be coerced to a DOM element - and I can think of situations where knowing about the intended parent node would be useful to a 'widget' when its __dom__ or dom function is called with it. Consider, for example, that a widget might want to use the dimensions of the parent node for setting its behavior - when __dom__ is called, I can gather information about the passed-in parent node and update my widget's size or behavior before passing back the thing that will be coerced for placement in the DOM. > > 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. I won't fault you for your particular view of how one might use certain facilities of MochiKit if you don't fault me for mine. :) > >> 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 "_". In the widgets I develop, the private fields are not accessible because of closures. Doesn't make sense to me to call something private when it isn't really private (or when it is only considered private because of a naming convention). > > 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. It is far more of a widget framework than what I currently use, so to me it is "an entire widget framework." :) Besides, it is meant to do just that, isn't it? I think the word "entire" is rather subjective. And I realize you were not trying to force me into anything. > 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. I will cr
[mochikit] Re: Why doesn't removeElement use the DOM Coercion rules?
> On Friday, October 10, 2008 at 11:33PM Bob Ippolito wrote: > > > If you'd like to fix it then I don't see why the patch would be rejected. > Sounds good, I will do just that. Thanks, Jason --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com 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 -~--~~~~--~~--~--~---
[mochikit] Re: Why doesn't removeElement use the DOM Coercion rules?
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 mochikit@googlegroups.com 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 -~--~~~~--~~--~--~---
[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
[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();
[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
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
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
-~--~~~~--~~--~--~---
[mochikit] Re: Why doesn't removeElement use the DOM Coercion rules?
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.
But sure, there is an inconsistency here. My suggestion would be to
just work around it instead:
removeElement(myWidgetInstance.widgetDomRepresentation);
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
Cheers,
/Per
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
>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochikit@googlegroups.com
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
-~--~~~~--~~--~--~---
