I'd argue that it actually provides you more control over the element
in the sense that you will know when it is initially added or removed
from the DOM.
It is actually pretty smart about how it watches for DOM changes.
Thanks to jQuery's architecture this is all possible with very little
initial overhead. For example if you had the following chain:
$('...').css('...').attr('...').append('...');
Live Query wouldn't run until after the append was done even though
the css and attr methods are also monitored. It also doesn't apply
just to chains. The above could also be broken apart and Live Query
still wouldn't run until after the append was done.
$('...').css('...');
$('...').attr('...');
$('...').append('...');
The performance issues come about when you are selecting _lots_ of
elements with several Live Queries. It has the same performance
concerns as you would with regular jQuery selectors. For example to
increase performance give it a context.
$('div', '#myDynamicArea').livequery('...')
That will obviously run faster than just $('div').livequery('...').
As with all performance concerns ... don't get caught up in pre-
optimizations. After the app is built use profiling and experiment
with selectors to find the areas that are actually slowing you down.
Finally, Live Query will never bind a particular event to an element
more than once. In fact it _only_ binds the event (or calls the
callback) once per a newly matched element.
Live Query's main purpose is to solve a _very_ common problem in AJAX
development ... the need to rebind events to elements added to the DOM
after the initial page load. It does this _very_ well and on most
common uses there will be absolutely no noticeable performance hit.
--
Brandon Aaron
On Nov 2, 12:26 pm, Jack Killpatrick <[EMAIL PROTECTED]> wrote:
> I 2nd Dan's idea. What has made me wary about dipping into using
> LiveQuery is:
>
> 1. loss of an element of control, compared to just calling a helper
> function at the right time to rebind events
> 2. concern about overhead, since (as I understand it), it's watching for
> DOM changes and hence maybe not rebinding things in as efficient a
> manner as I would want. This concern could just come from not knowing
> (or having looked at) how it works under the covers, but I'd have to
> make time for that, to ease my concerns
> 3. concern about possibly rebinding things that I don't want rebound, so
> I'd have to write code to prevent it, ending up with around as much code
> as just rebinding via my helper function
>
> - Jack
>
> Dan G. Switzer, II wrote:
>
> > I think what I'd be more interested is having a method that would allow me
> > to really easily *manually* re-apply effects/events to a jQuery object.
>
> > For example:
> > $('li')
> > .cache('some.name', function(){
> > // use the helper function hover to bind a mouseover and mouseout event
> > $(this)
> > .hover(function() {
> > $(this).addClass('hover');
> > }, function() {
> > $(this).removeClass('hover');
> > });
> > });
>
> > Now you could do:
> > $('li').applyCache('some.name');
>
> > Something like that would definitely save me some coding. (I'd allow a
> > manual cache "key", just so you could re-use the chain on other selectors.)
>
> > The benefit is you don't have the overhead of having to constantly monitor
> > the DOM, but you have an easy way to re-apply a bunch of commands to a
> > selector.
>
> > Right now I just use helper functions--which isn't hard, just not very
> > jQueryish. :)
>
> > Too bad there's no way to programmatically know the jQuery chain. It would
> > be really sweet to be able to do:
>
> > $('li')
> > .hover(function() {
> > $(this).addClass('hover');
> > }, function() {
> > $(this).removeClass('hover');
> > })
> > .cache('some.name');
>
> > And have the cache() method be aware of all the methods called in the
> > current chain.
>
> > -Dan
>
> >> -----Original Message-----
> >> From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On
> >> Behalf Of tlphipps
> >> Sent: Thursday, November 01, 2007 9:22 AM
> >> To: jQuery (English)
> >> Subject: [jQuery] Re: LiveQuery (Discuss Please)
>
> >> I'd like to second this opinion. I'm using livequery more and more,
> >> but there are plenty of places where I DON'T use it, so not having it
> >> in the core would still be my preference.
>
> >> On Nov 1, 5:53 am, James Dempster <[EMAIL PROTECTED]> wrote:
>
> >>> My less than one pence worth would be I love and use the plugin, but I
> >>> don't think it should be included into jQuery core, I would
> >>> like to see jQuery core stay light and fresh. There's nothing wrong
> >>> with adding LiveQuery yourself, either just add another js file to
> >>> your html or append all the plugins you want to the same js file.
>
> >>> /James
>
> >>> On Nov 1, 2:04 am, "Yehuda Katz" <[EMAIL PROTECTED]> wrote:
>
> >>>> So as far as I'm concerned, livequery is the biggest advance in jQuery
>
> >> since
>
> >>>> its inception (no, I am not its author). I'm trying to understand why
>
> >> it's
>
> >>>> having such a slow rate of adoption.
>
> >>>> it solves this problem:
> >>>> $("div.klass").draggable();
> >>>> $("#foo").load("url", function() { $("div.klass").draggable(); });
>
> >>>> beautifully, as you now only need to do:
>
> >>>> $("div.klass").livequery(function() { $(this).draggable() });
> >>>> $("#foo").load("url");
>
> >>>> Obviously, that was only a simple example. The more general case,
>
> >> wanting to
>
> >>>> bind some event handler to a selector regardless of when it appears on
>
> >> the
>
> >>>> page, is extremely common. So again, I'm trying to understand why the
>
> >> rate
>
> >>>> of adoption has been so slow. Any thoughts?
>
> >>>> --
> >>>> Yehuda Katz
> >>>> Web Developer | Procore Technologies
> >>>> (ph) 718.877.1325
