Ah, yes .. of course there is detach() already in 1.4. I remember it
now from a "roadmap" ...
And a "new" remove( selector, keepData ).
But. I am thinking on a more conceptual level. Not just on the API
level. jQuery is in essence a visitor/handler/mediator between a
persistent storage (dom tree) and a user. What complicates this
picture (a lot) is the fact that one can have a number of active jQ
instances, all operating on the same single persistent stroage (dom
tree).
This situation is a very tough nut to crack. Exactly the same as
having a lot of web client users looking into the same data set on the
server side. And updating it. And erasing portions of it. Usally
solved with some kind of distributed system events infrastructure.
Create, read, update and delete (CRUD) are the four basic functions of
persistent storage.
It seems that jQuery might benefit from solutions in this "space"
from other "database like" systems? Which usualy is done as a form of
"system events" which would map to the CRUD operations which are
changing the state of the document tree. Something that W3C has
"forgoten" to do, perhaps ...
I do not think this would be too difficult to design? A bit tricky to
implement and too deep for a simple "change", for a 1.4 perhaps....
Certainly a non-trivial plugin might be a good prototype?
--DBJ
On Dec 15, 1:37 pm, Karl Swedberg <k...@englishrules.com> wrote:
> Devon, some people like to remove elements and have the option of
> adding some or all of them back into the DOM at a later time.
>
> DBJDBJ, this is just FYI since you already retracted your suggestion
> to add a .detach() method, but jQuery 1.4a already has a .detach()
> method. It removes elements from the DOM without removing their events
> or data.
>
> --Karl
>
> On Dec 15, 2009, at 7:33 AM, Devon Govett wrote:
>
> > @John I would like to ask the same thing DBJDBJ did. Why would you
> > want to find the index of an element that no longer exists? This just
> > seems unintuitive. You shouldn't be able to find the index of
> > something not in the document. The two sets of elements did refer to
> > the same thing, but no they don't because you removed the elements.
> > This makes sense to me. As far as I know, no matter how you remove
> > elements they are not part of the document any more. Isn't that the
> > point of removing them?
>
> > Devon
>
> > On Dec 14, 11:48 pm, John Resig <jere...@gmail.com> wrote:
> >> A major problem with your technique is that the original elements are
> >> simply no longer part of the document.
>
> >> For example:
>
> >> var someElems = $("div");
> >> // length == 10
>
> >> var removed = $("div.foo").remove();
> >> // length == 5
>
> >> someElems.index( removed )
> >> // -1 (the elements you just removed aren't found!)
>
> >> This creates a problem: You now have two sets of elements that sort
> >> of
> >> refer to the same thing but actually aren't the same.
>
> >> --John
>
> >> On Mon, Dec 14, 2009 at 11:35 PM, Devon Govett
> >> <devongov...@gmail.com> wrote:
> >>> I did some performance testing with the following code, and found it
> >>> to be much slower than the cloneNode method, but still often twice
> >>> as
> >>> fast as the current method.
>
> >>> jQuery.fn.removeAll = function() {
> >>> this.each(function() {
> >>> var nextSibling = this.nextSibling;
> >>> var parent = this.parentNode;
>
> >>> parent.removeChild(this);
> >>> while (this.firstChild) {
> >>> this.removeChild(this.firstChild);
> >>> }
> >>> if(nextSibling)
> >>> parent.insertBefore(this, nextSibling)
> >>> else
> >>> parent.appendChild(this);
> >>> });
> >>> };
>
> >>> What are the problems with the cloneNode method?
>
> >>> Devon
>
> >>> On Dec 13, 5:36 pm, Devon Govett <devongov...@gmail.com> wrote:
> >>>> Yeah I tried that too, and it was slightly slower in most browsers
> >>>> than cloneNode. The other issue with this, is that if the user
> >>>> has a
> >>>> slow computer, or the removal is taking a really long time, layout
> >>>> problems may occur since there is no element in the DOM during the
> >>>> emptying. The cloneNode method has the advantage that during the
> >>>> emptying process nothing is removed from the screen and so things
> >>>> don't look weird. I know this is an edge case, but it is
> >>>> something to
> >>>> consider.
>
> >>>> Devon
>
> >>>> On Dec 13, 10:46 am, John Resig <jere...@gmail.com> wrote:
>
> >>>>> Actually, now that you bring this up, it would make a lot of
> >>>>> sense to
> >>>>> just remove the element from the DOM first and /then/ go through
> >>>>> and
> >>>>> clean up the child nodes, and finally re-inject the element
> >>>>> again. I'm
> >>>>> hesitant to do a cloneNode because of the inherent problems that
> >>>>> exist
> >>>>> in Internet Explorer. I'll see if I have some time to do some perf
> >>>>> testing on this later today.
>
> >>>>> --John
>
> >>>>> On Sun, Dec 13, 2009 at 8:19 AM, Devon Govett
> >>>>> <devongov...@gmail.com> wrote:
> >>>>>> Hi all,
>
> >>>>>> I've just blogged about a technique that I used to make
> >>>>>> jQuery.empty
> >>>>>> over 10x faster in some cases. Basically, rather than
> >>>>>> individually
> >>>>>> removing each child element from the DOM which causes the
> >>>>>> browser to
> >>>>>> reflow after each one, I use a shallow cloneNode to do the job
> >>>>>> then
> >>>>>> copying events back over. Check out the blog post for more
> >>>>>> details:
> >>>>>>http://devongovett.wordpress.com/2009/12/12/how-to-make-jquery-empty-
> >>>>>> ....
> >>>>>> I've included some charts comparing the performance of jQuery
> >>>>>> 1.4's
> >>>>>> empty and html("") functions, as well as the function I've
> >>>>>> written,
> >>>>>> and the cloneNode method out performs all other methods by a
> >>>>>> significant amount in all browsers.
>
> >>>>>> Thanks for jQuery!
> >>>>>> Devon
>
> >>>>>> --
>
> >>>>>> You received this message because you are subscribed to the
> >>>>>> Google Groups "jQuery Development" group.
> >>>>>> To post to this group, send email to jquery-...@googlegroups.com.
> >>>>>> To unsubscribe from this group, send email to
> >>>>>> jquery-dev+unsubscr...@googlegroups.com
> >>>>>> .
> >>>>>> For more options, visit this group
> >>>>>> athttp://groups.google.com/group/jquery-dev?hl=en
> >>>>>> .
>
> >>> --
>
> >>> You received this message because you are subscribed to the Google
> >>> Groups "jQuery Development" group.
> >>> To post to this group, send email to jquery-...@googlegroups.com.
> >>> To unsubscribe from this group, send email to
> >>> jquery-dev+unsubscr...@googlegroups.com
> >>> .
> >>> For more options, visit this group
> >>> athttp://groups.google.com/group/jquery-dev?hl=en
> >>> .
>
> > --
>
> > You received this message because you are subscribed to the Google
> > Groups "jQuery Development" group.
> > To post to this group, send email to jquery-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > jquery-dev+unsubscr...@googlegroups.com
> > .
> > For more options, visit this group
> > athttp://groups.google.com/group/jquery-dev?hl=en
> > .
--
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
