The only problem with 'caching collections' in 1.3.2 with '.live' is that
if you depend on regular expressions to attach behavior to a highly
modified-on-the-fly DOM, then '.live' doesnt permit all selectors available
through Sizzle.
More importantly, without '.live' the assignment needs to be a
predetermined collection of static elements, otherwise you may end up with
elements you want applied behavior for but don't get it.
I do lean toward the group of developers that want all valid jquery
selectors to be 'live'. I believe there are plugins available to do this
that I've been meaning to look at. I will post back links.
So my general point is that, addressing caching of jQuery objects, it's not
enough to use 'any' selector once if you depend on highly-modified DOMs you
would always have to repeat the search.
On Wed, Jun 3, 2009 at 2:25 PM, ajpiano <ajpi...@gmail.com> wrote:
>
> In all honesty, this was a functionality I was hot for maybe a year
> ago, but probably wouldn't need much today. I cache collections all
> the time, and I recommend it highly to new users. Users of jQuery
> should be WAY more aware of the simple fact that $() is a constructor,
> but many are not. If there's anything we could do as a community, it
> would be to further encourage the practise.
>
> That said, I think the idea that multi-line chains should be frowned
> upon is a bit short-sighted. Take this piece of code:
>
> $('tr.parent')
> .css("cursor","pointer")
> .attr("title","Click to expand/collapse")
> .click(function(){
> $(this).siblings('.child-'+this.id).toggle();
> });
>
> It completely breaks your Best Practise of never chaining across
> multiple lines, but I don't think there's anyone on this list who
> would decry that example as unreadable or "cryptic."
>
> I think a lot of people, including myself, use a jQuery chain as an
> opportunity to briefly interact with the DOM after doing setting up an
> instance. This isn't the world's greatest example, but I think it
> demonstrates why this might be desirable.
>
>
> var foo = {
> $el:$("#bar"),
> emotion: Math.rand < .5 ? "sad" : "happy",
> init:function() {
> var self = this;
> this.$el.click(function() {
> alert(foo.emotion);
> })
> .iff(this.readyToDoSomeWork)
> .load("url.php",function(data) {
> self.update(data);
> })
> .end()
> .addClass(this.emotion);
> },
> readyToDoSomeWork:function() {
> return this.emotion == "happy";
> },
> update:function(data) {
> this.$el.html(data);
> },
>
> };
>
>
> foo.init();
>
> It is easy to code around a chainable conditional using cached
> collections, but, like with the suggestion I had for .index(), the
> idea here is to save developers the stops and starts and extra
> variables that might not be necessary. As I said before, I'm not even
> sure I myself would use this, my point is just that there is
> considerable demand for the functionality, and even when you *do*
> cache your selections, it doesn't completely prevent you from needing
> to break chains.
>
>
> Ultimately this discussion boils down to taste. How jQueryish should
> jQuery be? How Javascripty? To answer the question, "how is this
> better?" I would say, however, that when you have to refer to the same
> element three times in six lines of code just to execute any piece of
> conditional logic, you're just giving up the power of chaining
> altogether just in favor of more "Javascriptiness." Which is, of
> course, better than "PHPness," at least when you say it out loud :p
>
> --adam
>
>
>
>
>
>
>
>
> On Jun 3, 10:29 am, DBJDBJ <dbj...@gmail.com> wrote:
> > If something is possible , that does not mean it is feasible ...
> >
> > In the conext of jQuery, one can do a lot of kind-of-a "if then else"
> > logic through selectors and scope (aka context). Especially with the
> > help of plugins like :
> http://plugins.jquery.com/project/EnhancedAttributeSelectors
> > (side note: (mildly) interesting discussion can be found here :
> http://james.padolsey.com/javascript/a-better-data-selector-for-jquery/
> > )
> >
> > Also, don take it as a sarcasm but there is still good old, if-then-
> > else javascript construct available ...
> >
> > Last, but not the least: never underestimate importance fo the
> > readability of the code. Never.
> >
> > -- DBJ
> >
> > On Jun 3, 10:19 am, Már <mar.orlygs...@gmail.com> wrote:
> >
> > > Here's my pass at creating an elegant if/else plugin:
> http://mar.anomy.net/entry/2008/11/04/20.00.32/
> >
> > > I've used it quite a bit, and I love it, but...
> > > I would still vote against adding this sort of thing to the jQuery
> > > core.
> >
> > > The only real benefit of these sorts of plugins is that they make your
> > > code more jQuery-ish.
> > > (You don't have to assign collections to variables, and break your
> > > chains to add conditions.)
> > > Meanwhile your code becomes less javascript-ish.
> >
> > > I've also found that assigning collections to variables, actually
> > > encourages programmers to recycle their collections instead of using $
> > > (selector) again and again...
> >
> > > --
> > > Már
> >
> >
> >
>
--
Christopher Thatcher
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@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
-~----------~----~----~----~------~----~------~--~---
