jQuery Forum

On Jun 2, 1:06 pm, ajpiano <ajpi...@gmail.com>

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

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

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

I think it does make the code uglier. All this time I thought that it
would be a great idea as to not break the chain, but the code really
looks ugly in the end. It should still be made as a plugin for people
to use, but I would highly unrecommend it :)

Not that it matters much,
but I liked your level-headed reasoning, and hereby change my vote
from "against" to "for".
IMO, any conditional method needs to have an "else(if)" counterpart.
It should accept both truthy/falsy booleanoid and a function...
and passing arguments[1+] as parameters to the function sounds like a
good idea.
--
Már

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.

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

This thread got me thinking, as chaining conditions is something I've
found myself wanting to do occasionally when quickly writing jQuery.
I'm not sure I'm sold on the idea of having the condition affect the
current chain, though. I'd prefer something more like the event
helper syntax. Here's my contribution:
jQuery.fn.extend({
condition: function() {
for (var i=0; i<arguments.length; i=i+2) {
if (arguments[i]) {
this.condition = (arguments[i+1]) ? arguments[i+1]:
arguments[i];
this.condition();
this.condition = jQuery.fn.condition;
break;
}
}
return this;
}
});
It allows you to write chainable jQuery conditions thus:
jQuery("#element").condition(condition, fn)
The arguments can contain any number of condition / function pairs
that act as 'if' and 'else if'. If the final argument is a function
with no preceding condition
it acts as 'else'. Inside the function 'this' is the current jQuery
collection:
jQuery("#element")
.condition( (x===1), function(){
this.css({color: 'blue'});
}), (x===2), function(){
this.css({color: 'red'});
}), function(){
this.css({color: 'green'});
});
I'm really not sure of the merits of temporarily overwriting the
condition method to get 'this' to represent the current collection.
That's probably not clever. Certainly it means you can't put one
condition inside another. Does anyone know a better way, without
having to look for an unused name in the jQuery.fn.x namespace?

After several iterations this discussion is nearing its (obvious?)
conclusion.
A LISP cond statement . For Lisp-ers COND is a thing of beauty. The
basic syntax of COND is:
(cond ((predicate1) (then do something 1)) ;if this predicate is
true,
;do something1
((predicate2) (then do something 2)) ;if this predicate is
true,
;do something2,
;each predicate and
action
;following the
;first one is optional
(T (else do this)) ;else, if none of the
;predicates returns
;TRUE, do this
)
So, please go ahead and implement jQuery.fn.cond()
What's next? LAMBDA functions as an jQyery plugin ?
Cheers ;o)
--DBJ

Great ideas guys, how about this?
jQuery.fn.extend({
cond: function() {
var i, predicate, callback;
for (i = 0; i < arguments.length; i += 2) {
predicate = arguments[ i ];
callback = arguments[ i + 1 ];
if ( !callback ) {
callback = predicate;
predicate = true;
}
if ( jQuery.isFunction( predicate ) ? predicate.apply( this ) :
predicate ) {
callback.apply( this );
break;
}
}
return this;
}
});
function test() {
return x === 3;
}
jQuery("a")
.cond(
x === 1, function(){
this.css({ color: 'blue' });
},
x === 2, function(){
this.css({ color: 'red' });
},
test, function(){
this.css({ color: 'orange' });
},
function(){
this.css({ color: 'green' });
}
);

Hey, brilliant, thanks, Ben.
I hadn't got into call() and apply() yet. Now I have! I can see
that's going to become essential very quickly. There's not too much
documentation about them on the old googlenet, though.
The only thing wrong is that 'orange' is not a valid CSS colour. : )
Stephen.

P.S. Oh, and also, if !callback then we know predicate is not a
function, so we shouldn't need to then test it for function-ness with
jQuery.isFunction().
But I'm nit-picking. I can see that having 'this' refer to the
current collection in the predicate is a useful thing to have...
Cheers!

Well, since we're nit-picking, I should've used call instead of apply,
because it would net a 2 byte bandwidth savings!
- Cowboy

Am I too late for my good old If ElseIf Else ?
Its logic was different from every other plugin if I am not wrong:
<a href="http://plugins.jquery.com/project/IfElseIfElse">http://plugins.jquery.com/project/IfElseIfElse</a>
Regards

Here's a version (with call!) that allows you to
return whatever you like to the chain. If you return
undefined, it returns the original jQuery object unmodified.
jQuery.fn.extend({
condition: function() {
var i, test, result;
for (i=0; i<arguments.length; i=i+2) {
test = typeof(arguments[i])==='function' ? arguments
[i].call(this) : arguments[i] ;
if (!arguments[i+1]) {
result = test;
break;
}
if (test) {
result = arguments[i+1].call(this);
break;
}
}
return result === undefined ? this : result;
}
});

Ok, I've gone ever-so-slightly farther with this one. It works
basically the same as your last post (which was very well done btw!),
but also passes the value of the predicate into the callback (if the
predicate is truthy, of course) so that the callback can utilize it.
Sure, it's a total edge-case, but hey, you never know! If this were a
stand-alone plugin (which, it might just become) I'd add in a var
reference to arguments and undefined to aid in minification.
jQuery.fn.extend({
cond: function() {
var i = 0, predicate, callback, result;
while ( !predicate && i < arguments.length ) {
predicate = arguments[ i++ ];
callback = arguments[ i++ ];
predicate = jQuery.isFunction( predicate ) ? predicate.call
( this ) : predicate;
result = !callback ? predicate
: predicate ? callback.call( this, predicate )
: undefined;
}
return result !== undefined ? result : this;
}
});
var x = 1;
function test() {
return x === 3 ? 'aqua'
: x === 4 ? 'fuchsia'
: false;
}
jQuery('a')
.cond(
x === 1, function(){
this.css({ color: 'blue' });
},
x === 2, function(){
this.css({ color: 'red' });
},
test, function( val ){
this.css({ color: val });
},
function(){
this.css({ color: 'green' });
}
).length;

Nice idea. My version would do that by replacing line 13 with:
result = arguments[i+1].call(this, test);
Is there a good reason for using 'while'? Is it more efficient?

> jQuery('a')
>   .cond(
>     x === 1, function(){
>       this.css({ color: 'blue' });
>     },
>     x === 2, function(){
>       this.css({ color: 'red' });
>     },
>     test, function( val ){
>       this.css({ color: val });
>     },
>     function(){
>       this.css({ color: 'green' });
>     }
>   ).length;
Uhm, At the risk of exposing my complete failure to get the big
ongoing joke here (started by DBJDBJ),
...how is this `.cond()` thing supposed to be more readable/useful/
jQuery-ish than plain old:
jQuery('a').each(function(){
if (x === 1) {
$(this).css({ color: 'blue' });
}
else if (x === 2) {
$(this).css({ color: 'red' });
}
else if (test()) {
$(this).css({ color: val });
}
else {
$(this).css({ color: 'green' });
}
});
or an even more succinct:
jQuery('a').each(function(){
x === 1 ?
$(this).css({ color: 'blue' }):
x === 2 ?
$(this).css({ color: 'red' }):
test() ?
$(this).css({ color: val }):
$(this).css({ color: 'green' });
});
pray tell?

> ...how is this `.cond()` thing supposed to be more readable/useful/
> jQuery-ish
I admit, I'm not convinced I'll ever use it!
> pray tell?
It doesn't do the same thing. Where .each runs the tests for every
element in the collection and returns the collection, .cond() runs the
tests once and returns anything you like.

> It doesn't do the same thing.  Where .each runs the tests for every
> element in the collection and returns the collection, .cond() runs the
> tests once and returns anything you like.
Might I then suggest a simpler and more versatile method:
jQuery.fn.run = function (func, args)
{
this.length && func.apply(this, args||[]);
return this;
},
Used so:
jQuery('a').run(function(){
x === 1 ?
this.css({ color: 'blue' }):
x === 2 ?
this.css({ color: 'red' }):
test() ?
this.css({ color: val }):
this.css({ color: 'green' });
});
this `.run()` method has become part of my standard utility toolkit.
Highly efficient (only runs if the collection has length>0) and
provides the collection itself as this.

Well done Mr Már, from "treason" now we are back to reason.
Almost ;o)
Dare I say, the last nail in the coffin of the jQuert.fn.cond, might
be this :
jQuery('a').each(function(){
switch(x) {
case 1 : $(this).css({ color: 'blue' }): break ;
case 2 : $(this).css({ color: 'red' }): break ;
default :
$(this).css({ color: 'green' });
}
});
Unfortunately, for some, this is "too many keystrokes" ... And
peculiarly (then very young and rushed) Mr B. Eich forgot to make
result of the switch available, so this is not possible in
javascript :
$(this).css({ color:
switch(x) {
case 1 : 'blue' ; break ;
case 2 : 'red' ; break ;
default : 'green' ;
}
}) ;
Unless done like this :
eval(
'switch(x){ case 1: "blue"; break; case 2: "red"; break; default:
"green" } '
) ;
Which is somewhat clumsy. So some have concluded they "must help"
everyone with function simillar to this :
cond( x, 1, "blue", 2, "red", default, "green" ) ; // or call it
'my_switch'
Now the 'excitement' is high, because one can write this :
$(this).css({ color:
switch(x) {
cond( x, 1, "blue", 2, "red", default, "green" )
}
}) ;
For some this is "Awesome", while for some this is "obfuscation" . I
vote for ECMA5 to simply allow assignment with the 'switch'
statement :
//My ECMA5 proposal
var color = switch(x) { case 1: "blue"; break case 2: "red"; break
default: "green" } ;
--DBJ

Stephen - I didn't test while to see if it was more efficient, I just
didn't like the idea of having two break; statements, and was
wondering if it would be possible to do it with just one or none. This
way felt "cleaner" to me, somehow. But I'm a little weird (I'll freely
admit) :D

Mar, I like the generality of .run, that's a great method. And I think
that it's a great example of something that should be integrated in
core, because of its utility, size and simplicity.
As I was working on .cond, I did notice that this:
.cond( test, callback,
test, callback,
callback )
looked an awful lot like
function() {
test ? callback()
: test ? callback()
: callback();
};
but I clearly didn't think quite enough of it to take it to the next
level. I do still feel that .iff has a very "jQuery" feel.. but it's
just not as appropriate as .run.
- Cowboy

Yeah, Mar - I think you're right, and I already thought of that. I
probably will start using something similar: a function that will run
(but regardless of the collection), with the possibility of returning
a different collection to the chain:
jQuery.fn.extend({
run: function(fn) {
var result = fn.call(this);
return result !== 'undefined' ? result : this;
}
});
Really, it's a 'define-your-own-inline' jQuery plugin.
It's been fun mucking about with .cond(), though. Cheers, guys!