Chris, you make a good point about caching and .live. I tend to steer
clear of .live, but a mooTools style "live collection" would certainly
allow for less "element management" in highly dynamic pages. I am not
sure of the performance implications of this functionality, so I look
forward to seeing what you post...
--adam
On Jun 3, 11:52 pm, chris thatcher <thatcher.christop...@gmail.com>
wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
