Re: [jQuery] Chainable if/else - hot or not?
Hi,
Just putting in my vote for John's method. To me it makes sense, and would
mean I wouldn't have to keep track of numerous .end()s
You wouldn't nedd that with my aproach as well. Actually you could easily tell
if you need to call end() - simply by looking at the function name. With
Jhons solution you have to look if the function-call provides a
context-function. See the difference:
Johns aproach:
// add class to all divs with class hideme
var count = 0;
$('div.hideme').hide().filter('.showme',function() {
count++;
$(this).show();
}).addClass('test');
// add class to all divs with class hideme and showme
$('div.hideme').hide().filter('.showme').each(function() {
count++;
$(this).show();
}).addClass('test');
My aproach:
// add class to all divs with class hideme
$('div.hideme').hide().filterend('.showme',function() {
count++;
$(this).show();
}).addClass('test');
// add class to all divs with class hideme and showme
$('div.hideme').hide().filter('.showme',function() {
count++;
$(this).show();
}).addClass('test');
Christof
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
As an aside, or perhaps a branch, to this conversation...
I'm a jQuery newbie, and have found it interesting that
callbacks in the system do not seem to get parameters.
In systems that I've used before that provided callbacks,
those callbacks typically got a parameter or set of
parameters that would allow them to affect the data
being operated on.
You can pass as much data as you need using a closure, so there's no need to
have a parameter passed in:
var mydata = 0;
$(p).each(function(){
if ( ++mydata 4 ) this.style.fontWeight = bold;
});
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, October 04, 2006 11:59 AM
To: jQuery Discussion.
Subject: Re: [jQuery] Chainable if/else - hot or not?
As an aside, or perhaps a branch, to this conversation... I'm a jQuery
newbie, and have found it interesting that callbacks in the system do not
seem to get parameters. In systems that I've used before that provided
callbacks, those callbacks typically got a parameter or set of parameters
that would allow them to affect the data being operated on.
Is this a philosophical matter (callbacks should not modify the current
operation?) or is there something I'm missing?
Thanks!
--Steve
[EMAIL PROTECTED] | irc: monkinetic|redmonk
I don't know, I've been using .filter( foo, Function ) and .find(
foo, Function ) for a while now and I find them to be immensely
useful - especially considering that they're non-destructive. IMO,
having the functions be destructive in the first place was something
of a mistake, but not really something that can be easily fixed at
this point. At least having this callback can provide some sanity for
those who want it ;-)
--John
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
[EMAIL PROTECTED] schrieb: As an aside, or perhaps a branch, to this conversation... I'm a jQuery newbie, and have found it interesting that callbacks in the system do not seem to get parameters. In systems that I've used before that provided callbacks, those callbacks typically got a parameter or set of parameters that would allow them to affect the data being operated on. Is this a philosophical matter (callbacks should not modify the current operation?) or is there something I'm missing? Most callbacks can use 'this' to operate on the data. Some callbacks get paramters: An event object is passed to all event handlers, each is passed the iteration index. What else would you expect? If you are interested in custom parameters and can't rely on closures: There is already a ticket for this: http://jquery.com/dev/bugs/bug/202/ -- Jörn ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
Just putting in my vote for John's method. To me it makes sense, and would mean I wouldn't have to keep track of numerous .end()sChris ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
Hi,
I don't know, I've been using .filter( foo, Function ) and .find(
foo, Function ) for a while now and I find them to be immensely
useful - especially considering that they're non-destructive.
Well, if it was destructive it would be more consistent. I don't think that it
would be a problem, because you always have end():
$('.hideme').hide().filter('.showme').show().end().addclass('IamCrazy');
is currently equivalent to
$('.hideme').hide().filter('.showme', function() {
$(this).show();
}).addclass('IamCrazy');
It feels a bit odd to me. I'd expect this to be equal to the first line:
$('.hideme').hide().filter('.showme', function() {
$(this).show();
}).end().addclass('IamCrazy');
The Problem arises when chaining a lot of filter(), find(), etc. functions.
Then your way is IMO less readable.
How about shortcut-functions for e.g. filter().end():
$.fn.filterend = function(s,c) { return this.filter(s,c).end(); }
$('.hideme').hide().filterend('.showme', function() {
$(this).show();
}).addclass('IamCrazy');
I think that would be less confusing.
Just my 2 cents.
Christof
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
See, the important point, and the reason why I made this addition, is
for the fact that I'm trying to standardize how jQuery works and the
order of arguments for a method. The idiom that I'm molding is:
.method( Hash, arg1, ..., argN, ContextFunction )
If a method takes a hash, you'll know that it's the first thing in
there. If it takes a context function - it'll always be last. With
that in mind, adding on context functions to virtually all methods
just makes sense (we were nearly there to begin with).
This way, a user can call .load(), .submit(), .parent(), .find(), etc.
etc. and know that the last argument can be an optional function that
will be executed within the set's context.
So, with .filter(foo,function) I'm taking the opportunity to remove
the need for:
.filter(foo).each(function(){
}).end()
Which is good because it's very common, and way too verbose. It's also
the same reason why I added the context function to $(...), to remove
that common .each() need. When people write the above code, they're
effectively building a non-destructive area in which they can work.
And it makes sense that way.
A lot of what you're doing can depend on how you write your code too,
and how you indent it, for example:
$(div.test)
.find(ul, function(){
$(this).hide()
if ( $(#newList:hidden).length )
$(#newList).show('fast');
})
.find(form)
.submit(function(){
return false;
})
.end();
I'm not confused by the above, although, I am steeped in the code
pretty good, so who knows. Comments are definitely appreciated.
--John
On 10/3/06, Christof Donat [EMAIL PROTECTED] wrote:
Hi,
I don't know, I've been using .filter( foo, Function ) and .find(
foo, Function ) for a while now and I find them to be immensely
useful - especially considering that they're non-destructive.
Well, if it was destructive it would be more consistent. I don't think that it
would be a problem, because you always have end():
$('.hideme').hide().filter('.showme').show().end().addclass('IamCrazy');
is currently equivalent to
$('.hideme').hide().filter('.showme', function() {
$(this).show();
}).addclass('IamCrazy');
It feels a bit odd to me. I'd expect this to be equal to the first line:
$('.hideme').hide().filter('.showme', function() {
$(this).show();
}).end().addclass('IamCrazy');
The Problem arises when chaining a lot of filter(), find(), etc. functions.
Then your way is IMO less readable.
How about shortcut-functions for e.g. filter().end():
$.fn.filterend = function(s,c) { return this.filter(s,c).end(); }
$('.hideme').hide().filterend('.showme', function() {
$(this).show();
}).addclass('IamCrazy');
I think that would be less confusing.
Just my 2 cents.
Christof
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
--
John Resig
http://ejohn.org/
[EMAIL PROTECTED]
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
Hi,
[...]
.method( Hash, arg1, ..., argN, ContextFunction )
[...]
That all was not my point. My point was that it is irritating that the same
function may be destructive or not just by providing the context-function.
I'd vote for either never be destructive, or always. Since for functions like
filter() it is difficult to go the never destructive-way, I'd like it to be
always destructive and have an alternative version which is never
destructive.
So, with .filter(foo,function) I'm taking the opportunity to remove
the need for:
.filter(foo).each(function(){
}).end()
That is exactly what the suggestet the filterend()-function is for. That way
filter() ist always destructive and filterend() never. In both cases with or
without a context function.
$('div').filter('.test') // return value only contains divs with class 'test'
$('div').filter('.test, // return value only contains divs with class 'test'
function() {
...
});
$('div').filterend('.test') // return value contains all divs (useless)
$('div').filterend('.test, // return value contains all divs
function() {
...
});
The last to calls have the same effect as
$('div').filter('.test').end()
$('div').filter('.test').each( function() {
...
}).end();
In all cases the context function is evaluated for each div with the
class 'test'. The difference between filter() and filterend() is just the
return value.
Christof
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
I thought, I'd add on my personal thoughts on this subject. Personally,
I find the anonymous function version of filter et. al. to be quite
intuitive. You can either modify the stack temporarily and continue the
chain until you .end() this modified stack and return to the original,
or you can simply apply the methods you want to the argument you
provided leaving the original stack intact without needing to .end() the
modified stack seeing as it wasn't modified. Please please keep this
syntax as it's too elegant to not keep around.
-blair
Christof Donat wrote:
Hi,
[...]
.method( Hash, arg1, ..., argN, ContextFunction )
[...]
That all was not my point. My point was that it is irritating that the same
function may be destructive or not just by providing the context-function.
I'd vote for either never be destructive, or always. Since for functions like
filter() it is difficult to go the never destructive-way, I'd like it to be
always destructive and have an alternative version which is never
destructive.
So, with .filter(foo,function) I'm taking the opportunity to remove
the need for:
.filter(foo).each(function(){
}).end()
That is exactly what the suggestet the filterend()-function is for. That way
filter() ist always destructive and filterend() never. In both cases with or
without a context function.
$('div').filter('.test') // return value only contains divs with class 'test'
$('div').filter('.test, // return value only contains divs with class 'test'
function() {
...
});
$('div').filterend('.test') // return value contains all divs (useless)
$('div').filterend('.test, // return value contains all divs
function() {
...
});
The last to calls have the same effect as
$('div').filter('.test').end()
$('div').filter('.test').each( function() {
...
}).end();
In all cases the context function is evaluated for each div with the
class 'test'. The difference between filter() and filterend() is just the
return value.
Christof
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
I like this idea. I think that it gives everyone what they want, and none
of the methods are going to be as confusing to a newcomer that way.
My one complaint is that I don't like filterend as a method name. It
sounds... clunky. I'm sure that one of us can do better. :)
- Brian
Hi,
I don't know, I've been using .filter( foo, Function ) and .find(
foo, Function ) for a while now and I find them to be immensely
useful - especially considering that they're non-destructive.
Well, if it was destructive it would be more consistent. I don't think
that it
would be a problem, because you always have end():
$('.hideme').hide().filter('.showme').show().end().addclass('IamCrazy');
is currently equivalent to
$('.hideme').hide().filter('.showme', function() {
$(this).show();
}).addclass('IamCrazy');
It feels a bit odd to me. I'd expect this to be equal to the first line:
$('.hideme').hide().filter('.showme', function() {
$(this).show();
}).end().addclass('IamCrazy');
The Problem arises when chaining a lot of filter(), find(), etc.
functions.
Then your way is IMO less readable.
How about shortcut-functions for e.g. filter().end():
$.fn.filterend = function(s,c) { return this.filter(s,c).end(); }
$('.hideme').hide().filterend('.showme', function() {
$(this).show();
}).addclass('IamCrazy');
I think that would be less confusing.
Just my 2 cents.
Christof
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
Elegant? Perhaps.
Breaks the Principle of Least Surprise? Absolutely, unfortunately.
I'm with Chris. One method that's always destructive, and another method
that's always not.
- Brian
I thought, I'd add on my personal thoughts on this subject. Personally,
I find the anonymous function version of filter et. al. to be quite
intuitive. You can either modify the stack temporarily and continue the
chain until you .end() this modified stack and return to the original,
or you can simply apply the methods you want to the argument you
provided leaving the original stack intact without needing to .end() the
modified stack seeing as it wasn't modified. Please please keep this
syntax as it's too elegant to not keep around.
-blair
Christof Donat wrote:
Hi,
[...]
.method( Hash, arg1, ..., argN, ContextFunction )
[...]
That all was not my point. My point was that it is irritating that the
same
function may be destructive or not just by providing the
context-function.
I'd vote for either never be destructive, or always. Since for functions
like
filter() it is difficult to go the never destructive-way, I'd like it
to be
always destructive and have an alternative version which is never
destructive.
So, with .filter(foo,function) I'm taking the opportunity to remove
the need for:
.filter(foo).each(function(){
}).end()
That is exactly what the suggestet the filterend()-function is for. That
way
filter() ist always destructive and filterend() never. In both cases
with or
without a context function.
$('div').filter('.test') // return value only contains divs with class
'test'
$('div').filter('.test, // return value only contains divs with class
'test'
function() {
...
});
$('div').filterend('.test') // return value contains all divs (useless)
$('div').filterend('.test, // return value contains all divs
function() {
...
});
The last to calls have the same effect as
$('div').filter('.test').end()
$('div').filter('.test').each( function() {
...
}).end();
In all cases the context function is evaluated for each div with the
class 'test'. The difference between filter() and filterend() is just
the
return value.
Christof
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
FYI, you can already call an extra Function argument on any destructive operation, for example: .find( foo, ifCallback ) .filter( foo, ifCallback ) .not( foo, ifCallback ) I didn't document this yet, since I didn't think anyone was going to care to use it, except for me. Heh. I use it in a few places already because of some issues with pushStack holding references to nodes that have been removed from the document: http://jquery.com/dev/bugs/bug/30/ It would still be nice to have chained operations though. Why not use the pushStack stack as an operand? For example, if you want the else part, just have a .invert() method that takes the current node set and selects all the nodes on the stack that aren't already in that set. $() .filter() .stuff().to().filtered().nodes() .invert() .stuff().to().remaining().nodes() .end() Yes, .invert() is destructive to the current node set, but if you need the original filtered nodes back you just invert them again. One other thing I've wanted a couple of times is a method that would add nodes only if the current node set was empty. Kind of like the || operator in Javascript. ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
Brian wrote: Elegant? Perhaps. Breaks the Principle of Least Surprise? Absolutely, unfortunately. I don't find it to be surprising at all. If you run filter without specifying what you want to do with the subset it creates via a secondary lambda argument, the stack is modified to allow you to act on that subset while retaining the original stack allowing you to return to it via an .end() call. If you specify a callback, it is smart enough to realize you want to use that callback on the subset and that's all. So it doesn't modify the set and the chain continues unmodified. It makes sense to me but, as with anything, that means nothing for anyone else. -blair ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
$() .filter() .stuff().to().filtered().nodes() .invert() .stuff().to().remaining().nodes() .end() invert ... that is so much better than $else or otherwise. I like this for an all jQuery method solution. -- Brandon Aaron ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
Brandon Aaron schrieb: $() .filter() .stuff().to().filtered().nodes() .invert() .stuff().to().remaining().nodes() .end() invert ... that is so much better than $else or otherwise. I like this for an all jQuery method solution. Ok, apart from a different name, that is the same $else method. But what happens if you do something like this: $() .filter() .filter() .doStuff() .invert() .doOtherStuff() .invert() doMoreStuff(); This is very difficult to implement, because the second invert has to revert (end()) both the filter and the invert operation. Other problems arise when you want to invert operations done via not() or find() etc. -- Jörn ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
Hi, Ok, apart from a different name, that is the same $else method. But what happens if you do something like this: $() .filter() .filter() .doStuff() .invert() .doOtherStuff() .invert() doMoreStuff(); That is very simple: the second invert() inverts the set that the first invert() has returned. To do what you might have thought about you need to use end(): $() .filter() .filter() .doStuff() .invert() .doOtherStuff() .end() .invert() doMoreStuff(); If course the invert()-function can not guess the indentation of your code. Actually I think, that else() or otherwise() may be better names for it. For me invert() sounds like a fx-function that swaps the foreground- and the background-color. Christof ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
Just to adding my vote.I like Johns approach because it fits in with the style of other jQuery methods. All the event and attribute methods have two sided functionality (bind/unbind, set/get), so it makes sense that the filtering methods would also have two sided functionality (persistent filter/non-persistent filter).
BlairOn 10/3/06, John Resig [EMAIL PROTECTED] wrote:
See, the important point, and the reason why I made this addition, isfor the fact that I'm trying to standardize how jQuery works and theorder of arguments for a method. The idiom that I'm molding is:.method( Hash, arg1, ..., argN, ContextFunction )
If a method takesa hash, you'll know that it's the first thing inthere. If it takes a context function - it'll always be last. Withthat in mind, adding on context functions to virtually all methodsjust makessense (we were nearly there to begin with).
This way, a user can call .load(), .submit(), .parent(), .find(), etc.etc. and know that the last argument can be an optional function thatwill be executed within the set's context.So, with .filter(foo,function) I'm taking the opportunity to remove
the need for:.filter(foo).each(function(){}).end()Which is good because it's very common, and way too verbose. It's alsothe same reason why I added the context function to $(...), to remove
that common .each() need. When people write the above code, they'reeffectively building a non-destructive area in which they can work.And it makes sense that way.A lot of what you're doing can depend on how you write your code too,
and how you indent it, for example:$(div.test).find(ul, function(){$(this).hide()if ( $(#newList:hidden).length )$(#newList).show('fast');
}).find(form).submit(function(){return false;}).end();I'm not confused by the above, although, I am steeped in the codepretty good, so who knows. Comments are definitely appreciated.
--JohnOn 10/3/06, Christof Donat [EMAIL PROTECTED] wrote: Hi, I don't know, I've been using .filter( foo, Function ) and .find(
foo, Function ) for a while now and I find them to be immensely useful - especially considering that they're non-destructive. Well, if it was destructive it would be more consistent. I don't think that it
would be a problem, because you always have end():$('.hideme').hide().filter('.showme').show().end().addclass('IamCrazy'); is currently equivalent to$('.hideme').hide().filter('.showme', function() {
$(this).show();}).addclass('IamCrazy'); It feels a bit odd to me. I'd expect this to be equal to the first line:$('.hideme').hide().filter('.showme', function() {
$(this).show();}).end().addclass('IamCrazy'); The Problem arises when chaining a lot of filter(), find(), etc. functions. Then your way is IMO less readable. How about shortcut-functions for
e.g. filter().end():$.fn.filterend = function(s,c) { return this.filter(s,c).end(); }$('.hideme').hide().filterend('.showme', function() { $(this).show();}).addclass('IamCrazy');
I think that would be less confusing. Just my 2 cents. Christof ___ jQuery mailing list
discuss@jquery.com http://jquery.com/discuss/--John Resighttp://ejohn.org/
[EMAIL PROTECTED]___jQuery mailing listdiscuss@jquery.comhttp://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
1 more vote for John's approach the documention can explain that
these functions can be run destructively or non-destructively. It's a
beauty!
On 10/3/06, Blair McKenzie [EMAIL PROTECTED] wrote:
Just to adding my vote.
I like Johns approach because it fits in with the style of other jQuery
methods. All the event and attribute methods have two sided functionality
(bind/unbind, set/get), so it makes sense that the filtering methods would
also have two sided functionality (persistent filter/non-persistent filter).
Blair
On 10/3/06, John Resig [EMAIL PROTECTED] wrote:
See, the important point, and the reason why I made this addition, is
for the fact that I'm trying to standardize how jQuery works and the
order of arguments for a method. The idiom that I'm molding is:
.method( Hash, arg1, ..., argN, ContextFunction )
If a method takes a hash, you'll know that it's the first thing in
there. If it takes a context function - it'll always be last. With
that in mind, adding on context functions to virtually all methods
just makes sense (we were nearly there to begin with).
This way, a user can call .load(), .submit(), .parent(), .find(), etc.
etc. and know that the last argument can be an optional function that
will be executed within the set's context.
So, with .filter(foo,function) I'm taking the opportunity to remove
the need for:
.filter(foo).each(function(){
}).end()
Which is good because it's very common, and way too verbose. It's also
the same reason why I added the context function to $(...), to remove
that common .each() need. When people write the above code, they're
effectively building a non-destructive area in which they can work.
And it makes sense that way.
A lot of what you're doing can depend on how you write your code too,
and how you indent it, for example:
$(div.test)
.find(ul, function(){
$(this).hide()
if ( $(#newList:hidden).length )
$(#newList).show('fast');
})
.find(form)
.submit(function(){
return false;
})
.end();
I'm not confused by the above, although, I am steeped in the code
pretty good, so who knows. Comments are definitely appreciated.
--John
On 10/3/06, Christof Donat [EMAIL PROTECTED] wrote:
Hi,
I don't know, I've been using .filter( foo, Function ) and .find(
foo, Function ) for a while now and I find them to be immensely
useful - especially considering that they're non-destructive.
Well, if it was destructive it would be more consistent. I don't think
that it
would be a problem, because you always have end():
$('.hideme').hide().filter('.showme').show().end().addclass('IamCrazy');
is currently equivalent to
$('.hideme').hide().filter('.showme', function() {
$(this).show();
}).addclass('IamCrazy');
It feels a bit odd to me. I'd expect this to be equal to the first line:
$('.hideme').hide().filter('.showme', function() {
$(this).show();
}).end().addclass('IamCrazy');
The Problem arises when chaining a lot of filter(), find(), etc.
functions.
Then your way is IMO less readable.
How about shortcut-functions for e.g. filter().end():
$.fn.filterend = function(s,c) { return this.filter(s,c).end(); }
$('.hideme').hide().filterend('.showme', function() {
$(this).show();
}).addclass('IamCrazy');
I think that would be less confusing.
Just my 2 cents.
Christof
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
--
John Resig
http://ejohn.org/
[EMAIL PROTECTED]
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
--
Ⓙⓐⓚⓔ - יעקב ʝǡǩȩ ᎫᎪᏦᎬ
▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒
░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░
▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒
░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░
▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
Brandon Aaron schrieb: ** Going to re-read to make sure I'm not complete off-base ** Okay ... so after re-reading I think that Jörn's first idea is the better one than the other suggestions. My only concern is that it changes the behavior of the is method. I still think making this its own method is the best option. With that said I think either modifying the is method, not method or *preferably* adding a new method with this simple syntax will be very useful! The modification to is() won't break any existing code that uses is() as documented (with only one paramter). But before closing this topic: Could you please have a look at the other solution to this: http://jquery.com/discuss/2006-October/012969/ This avoids the anonymous functions, but it's use is limited to jQuery methods. -- Jörn ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
The modification to is() won't break any existing code that uses is() as documented (with only one paramter). What I mean by changing the behavior of the is method is this ... The is method returns true or false based on the condition. What will the return value be if you pass in a function or two functions for if/else? Would it still return true/false or the actual unchanged jQuery object? Same question applies for the not method suggestion ... Would it return a modified jQuery object or an unmodified one when functions are passed? This avoids the anonymous functions, but it's use is limited to jQuery methods. So I think maybe I missed the goal of the $else construct. It seems its purpose is to provide a way to apply only jQuery methods. I can see the benefit of this but still really dislike the name since it is a keyword. Maybe name it 'otherwise'. I still think providing a method named 'ifelse' that takes an expression and two methods or maybe even one. I could see this being very useful and flexible. The 'ifelse' method would return the jQuery object unmodified. -- Brandon Aaron On 10/2/06, Jörn Zaefferer [EMAIL PROTECTED] wrote: Brandon Aaron schrieb: ** Going to re-read to make sure I'm not complete off-base ** Okay ... so after re-reading I think that Jörn's first idea is the better one than the other suggestions. My only concern is that it changes the behavior of the is method. I still think making this its own method is the best option. With that said I think either modifying the is method, not method or *preferably* adding a new method with this simple syntax will be very useful! The modification to is() won't break any existing code that uses is() as documented (with only one paramter). But before closing this topic: Could you please have a look at the other solution to this: http://jquery.com/discuss/2006-October/012969/ This avoids the anonymous functions, but it's use is limited to jQuery methods. -- Jörn ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/ ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
Brandon Aaron schrieb:
What I mean by changing the behavior of the is method is this ... The
is method returns true or false based on the condition. What will the
return value be if you pass in a function or two functions for
if/else? Would it still return true/false or the actual unchanged
jQuery object? Same question applies for the not method suggestion ...
Would it return a modified jQuery object or an unmodified one when
functions are passed?
You are right: While adding paramters to a method is ok, changing the
return type is not.
This avoids the anonymous functions, but it's use is limited to jQuery
methods.
So I think maybe I missed the goal of the $else construct. It seems
its purpose is to provide a way to apply only jQuery methods. I can
see the benefit of this but still really dislike the name since it is
a keyword. Maybe name it 'otherwise'.
I thought about otherwise, too. I changed it to else$ lately, but that
is stupid, too.
I still think providing a method named 'ifelse' that takes an
expression and two methods or maybe even one. I could see this being
very useful and flexible. The 'ifelse' method would return the jQuery
object unmodified.
I like that. You could then use it like this:
$(...).ifelse(':visible', ifCallback).doOtherStuff();
$(...).ifelse(':visible', ifCallback, elseCallback).doOtherStuff();
$(...).ifelse(':visible', null, elseCallback).doOtherStuff();
I'll put that in, if noone objects :-)
-- Jörn
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
youse guys are cookin! (that's good)
what about generalizing the if else if else if else case into
choose(
.this', thiscallback
, that, thatcallback,otherwisecallback)
M
On 10/2/06, Jörn Zaefferer [EMAIL PROTECTED] wrote:
Brandon Aaron schrieb:
What I mean by changing the behavior of the is method is this ... The
is method returns true or false based on the condition. What will the
return value be if you pass in a function or two functions for
if/else? Would it still return true/false or the actual unchanged
jQuery object? Same question applies for the not method suggestion ...
Would it return a modified jQuery object or an unmodified one when
functions are passed?
You are right: While adding paramters to a method is ok, changing the
return type is not.
This avoids the anonymous functions, but it's use is limited to jQuery
methods.
So I think maybe I missed the goal of the $else construct. It seems
its purpose is to provide a way to apply only jQuery methods. I can
see the benefit of this but still really dislike the name since it is
a keyword. Maybe name it 'otherwise'.
I thought about otherwise, too. I changed it to else$ lately, but that
is stupid, too.
I still think providing a method named 'ifelse' that takes an
expression and two methods or maybe even one. I could see this being
very useful and flexible. The 'ifelse' method would return the jQuery
object unmodified.
I like that. You could then use it like this:
$(...).ifelse(':visible', ifCallback).doOtherStuff();
$(...).ifelse(':visible', ifCallback, elseCallback).doOtherStuff();
$(...).ifelse(':visible', null, elseCallback).doOtherStuff();
I'll put that in, if noone objects :-)
-- Jörn
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
--
Ⓙⓐⓚⓔ - יעקב ʝǡǩȩ ᎫᎪᏦᎬ
▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒
░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░
▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒
░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░
▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
I hate writing code in gmail's little text window! I hope you got what I meant! On 10/2/06, Ⓙⓐⓚⓔ [EMAIL PROTECTED] wrote: youse guys are cookin! (that's good) what about generalizing the if else if else if else case into choose( .this', thiscallback , that, thatcallback,otherwisecallback) M ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
I like that. You could then use it like this:
$(...).ifelse(':visible', ifCallback).doOtherStuff();
$(...).ifelse(':visible', ifCallback, elseCallback).doOtherStuff();
$(...).ifelse(':visible', null, elseCallback).doOtherStuff();
I'll put that in, if noone objects :-)
FYI, you can already call an extra Function argument on any
destructive operation, for example:
.find( foo, ifCallback )
.filter( foo, ifCallback )
.not( foo, ifCallback )
etc. etc.
I didn't document this yet, since I didn't think anyone was going to
care to use it, except for me. Heh.
Since there's already an ifCallback for all those functions, adding in
an optional elseCallback wouldn't be that bad and would probably be
preferrable to adding a new .ifelse() function. What's everyone's
thoughts on this?
--John
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
I don't have my jqIfElse web page updated, I'll do that in the next couple of
days. However, here is updated code for the general $if/$else extension to
jQuery. Since it uses the jQuery internal stacks, it should work with
filter, is, add, not, etc. I have not tested it with anything but filter,
however.
One change to the original version is that if no parameters are passed to
if() it will traverse the true condition if the current jQuery handle has
objects.
$.fn.pushStack = function(a,args) {
var fn = args args[args.length-1];
if ( !fn || fn.constructor != Function ) {
var jq = this.get();
if ( !this.stack ) this.stack = [];
if ( !this.ifStack ) this.ifStack = [];// Added line
this.stack.push( jq );
this.ifStack.push( a ); // Added line
this.get( a );
} else {
var old = this.get();
this.get( a );
if ( fn.constructor == Function )
return this.each( fn );
this.get( old );
}
return this;
};
$.fn.$if = function(b) {
b = (typeof b == 'undefined') ? this.length : b;
return this.pushStack(b ? this : []);
};
$.fn.$else = function() {
return this.get((!this.stack.length || (this.ifStack[0]
this.ifStack[0].length)) ? [] : this.stack[0]);
};
$.fn.end = function() {
this.ifStack.pop();
return this.get( this.stack.pop() );
};
John Klinger
J?rn Zaefferer wrote:
I investigated on the idea a little further. A basic if/else, with
filter() as the if-method can be achieved with this change to filter():
filter: function(t) {
if( !this.filterStack ) this.filterStack = [];
this.filterStack.push(t);
return this.pushStack( ...);
}
The else method, with a dollar sign prepended, looks like this:
$else: function() {
return this.end().not( this.filterStack.pop() );
},
With those changes, this works:
$('#faq').find('dd').hide().end().find('dt').click(function() {
$(this).next().filter(':visible')
.slideUp()
.$else()
.slideDown();
});
Hot or not?
-- J?rn
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
--
View this message in context:
http://www.nabble.com/Chainable-if-else---hot-or-not--tf2363128.html#a6610843
Sent from the JQuery mailing list archive at Nabble.com.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
On 02/10/06, John Resig [EMAIL PROTECTED] wrote:
I like that. You could then use it like this:
$(...).ifelse(':visible', ifCallback).doOtherStuff();
$(...).ifelse(':visible', ifCallback, elseCallback).doOtherStuff();
$(...).ifelse(':visible', null, elseCallback).doOtherStuff();
I'll put that in, if noone objects :-)
FYI, you can already call an extra Function argument on any
destructive operation, for example:
.find( foo, ifCallback )
.filter( foo, ifCallback )
.not( foo, ifCallback )
etc. etc.
I didn't document this yet, since I didn't think anyone was going to
care to use it, except for me. Heh.
Since there's already an ifCallback for all those functions, adding in
an optional elseCallback wouldn't be that bad and would probably be
preferrable to adding a new .ifelse() function. What's everyone's
thoughts on this?
--John
I would prefer that (extending existing functions) to having ifelse
(which could always be done as an extension anyway).
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
Thanks, John R.
I've updated my demo page for the latest jQuery
(http://dmlair.com/jquery/jqIfElse/). I've also thought about the
issue of providing callbacks. If the $if() function is modified into
something like the following, then you could add a .$if(function()
{...}) to any jquery chain and the function will be executed if the
chain isn't empty. Further chaining could be done as the function's
return value is used as the $if() return value.
Since I haven't tested this in *any* way, for convenience I'll add it
to my demo page, but as $if2().
Here's the modified code:
$.fn.$if2 = function(b) {
if ( b b.constructor == Function this.length) {
return b(this);
} else {
b = (typeof b == 'undefined') ? this.length : b;
return this.pushStack(b ? this : []);
}
};
The $else() could be modified similarly, thusly:
$.fn.$else2 = function(fn) {
var returnEmpty = (!this.stack.length || (this.ifStack[0]
this.ifStack[0].length));
if ( !returnEmpty fn fn.constructor == Function) {
return fn(this.stack[0]);
} else {
return this.get(returnEmpty ? [] : this.stack[0]);
}
};
Again, I haven't tested either of these revisions, but it should give
both capabilities -- jQuery chaining and function callbacks.
John Klinger
On 9/30/06, John Resig [EMAIL PROTECTED] wrote:
Although, going back through his code - I really like what he did. He
made it such that you no longer had to use anonymous function wrappers
- which I really like. It'd be really cool to be able to do:
$(#foo)
.find(div)
.click()
.filter(.someclass)
.addClass(test)
.else()
.addClass(someclass)
.end()
.end();
It looks like it also needs to be ported to 1.0.1. The code is here,
for reference:
http://dmlair.com/jquery/jqIfElse/
--John
On 9/30/06, John Resig [EMAIL PROTECTED] wrote:
Well done, Jörn!
It makes me remember the work of John Klinger:
http://jquery.com/discuss/2006-July/#7292
It reminded me of that too. I kind of like the simplicity of this
solution. Doing a chainable .else() like what John K did is
fundamentally really hard.
--John
--
John Resig
http://ejohn.org/
[EMAIL PROTECTED]
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
that is cool, but destructive... is there a non-destructive if alternative available? Or do they just remove the filtered items from the chain, and let the rest of the chain calls deal with else cases? On 10/2/06, John Resig [EMAIL PROTECTED] wrote: \ FYI, you can already call an extra Function argument on any destructive operation, for example: .find( foo, ifCallback ) .filter( foo, ifCallback ) .not( foo, ifCallback ) etc. etc. I didn't document this yet, since I didn't think anyone was going to care to use it, except for me. Heh. Since there's already an ifCallback for all those functions, adding in an optional elseCallback wouldn't be that bad and would probably be preferrable to adding a new .ifelse() function. What's everyone's thoughts on this? --John ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
that is cool, but destructive... is there a non-destructive if alternative available? Or do they just remove the filtered items from the chain, and let the rest of the chain calls deal with else cases? It's completely non-destructive - that's what makes it great. .filter( string ) // destructive .fitler( string, function ) // non-destructive --John ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
Now that's GReat! On 10/2/06, John Resig [EMAIL PROTECTED] wrote: that is cool, but destructive... is there a non-destructive if alternative available? Or do they just remove the filtered items from the chain, and let the rest of the chain calls deal with else cases? It's completely non-destructive - that's what makes it great. .filter( string ) // destructive .fitler( string, function ) // non-destructive --John ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/ -- Ⓙⓐⓚⓔ - יעקב ʝǡǩȩ ᎫᎪᏦᎬ ▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒ ░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░ ▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒ ░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░ ▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒░▒ ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
I'm not crazy about the .filter()/.$else() as presented for one reason: It calls .end() as part of its implementation. Most programmers will expect to have to call .end() themselves, and it will be a bit confusing if it doesn't have to be explicitly called in this case. In fact, I don't think that people will expect the object returned by .$else(), which is the result of the .not() in the implementation (that they didn't call explicitly). The object that .$else() returns should be the original object returned by .filter() . That ends up being the making the most sense, I think. Agree? - Brian Brandon Aaron schrieb: ** Going to re-read to make sure I'm not complete off-base ** Okay ... so after re-reading I think that Jörn's first idea is the better one than the other suggestions. My only concern is that it changes the behavior of the is method. I still think making this its own method is the best option. With that said I think either modifying the is method, not method or *preferably* adding a new method with this simple syntax will be very useful! The modification to is() won't break any existing code that uses is() as documented (with only one paramter). But before closing this topic: Could you please have a look at the other solution to this: http://jquery.com/discuss/2006-October/012969/ This avoids the anonymous functions, but it's use is limited to jQuery methods. -- Jörn ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/ ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
I'm not sure I like that. If .filter() is destructive, it should be destructive all the time. It's less confusing that way. Just my opinion. :) that is cool, but destructive... is there a non-destructive if alternative available? Or do they just remove the filtered items from the chain, and let the rest of the chain calls deal with else cases? It's completely non-destructive - that's what makes it great. .filter( string ) // destructive .fitler( string, function ) // non-destructive --John ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
I'm not sure I like that. If .filter() is destructive, it should be destructive all the time. It's less confusing that way. Just my opinion. I don't know, I've been using .filter( foo, Function ) and .find( foo, Function ) for a while now and I find them to be immensely useful - especially considering that they're non-destructive. IMO, having the functions be destructive in the first place was something of a mistake, but not really something that can be easily fixed at this point. At least having this callback can provide some sanity for those who want it ;-) --John ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
Putting in my vote for whatever its worth...I Vote YES on $.fn.filter(string,ifCallback,elseCallback) instead of if/else etc.,with result remaining destructive as is current behaviour. On 10/3/06, Brian [EMAIL PROTECTED] wrote: I'm not sure I like that.If .filter() is destructive, it should bedestructive all the time.It's less confusing that way.Just my opinion. :) that is cool, but destructive... is there a non-destructive if alternative available? Or do they just remove the filtered items from the chain, and let the rest of the chain calls deal with else cases? It's completely non-destructive - that's what makes it great. .filter( string ) // destructive .fitler( string, function ) // non-destructive --John___jQuery mailing list discuss@jquery.comhttp://jquery.com/discuss/-- Reach1to1 Communications http://www.reach1to1.com[EMAIL PROTECTED]98201-94408 ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
John Resig schrieb:
Although, going back through his code - I really like what he did. He
made it such that you no longer had to use anonymous function wrappers
- which I really like.
Good point. That was the part of my solution I didn't like for myself.
It'd be really cool to be able to do:
$(#foo)
.find(div)
.click()
.filter(.someclass)
.addClass(test)
.else()
.addClass(someclass)
.end()
.end();
It looks like it also needs to be ported to 1.0.1. The code is here,
for reference:
http://dmlair.com/jquery/jqIfElse/
With that ability, the dt/dd example could be rewritten to this (almost,
can't use else):
$('#faq').find('dd').hide().end().find('dt').click(function() {
$(this).next().filter(':visible')
.slideUp()
.else()
.slideDown();
});
I really like that. I'll take a look at his code and try to port it.
-- Jörn
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
I investigated on the idea a little further. A basic if/else, with
filter() as the if-method can be achieved with this change to filter():
filter: function(t) {
if( !this.filterStack ) this.filterStack = [];
this.filterStack.push(t);
return this.pushStack( ...);
}
The else method, with a dollar sign prepended, looks like this:
$else: function() {
return this.end().not( this.filterStack.pop() );
},
With those changes, this works:
$('#faq').find('dd').hide().end().find('dt').click(function() {
$(this).next().filter(':visible')
.slideUp()
.$else()
.slideDown();
});
Hot or not?
-- Jörn
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
Very useful. One thought: It might be nice to allow the elseCallback to run
even when ifCallback is not provided.
George
J?rn Zaefferer wrote:
Hi folks,
the thread about showing and hiding DDs when clicking DTs gave me an
idea for a chainable if/else construct. I have implemented and tested it
and now I'd like to know if this is useful enough to be released as a
plugin or even adding to the core.
Basically I extended the current is(String expression) method. It now
accepts one or two functions. If one is given, it will be executed for
every element that fits the expression. If the second function is given,
it will be executed for every element that does not fit the expression.
Applied to the click dt to show/hide dd example:
$(document).ready(function() {
$('#faq').find('dd').hide().end().find('dt').click(function() {
$(this).next().is(':visible',
function() { $(this).slideUp(); },
function() { $(this).slideDown(); }
);
});
});
The extended is method looks like this:
is: function(expr, ifCallback, elseCallback) {
if(ifCallback) {
var elseCalllback = elseCallback || function() {};
return this.each(function() {
if($(this).is(expr)) {
ifCallback.apply(this);
} else {
elseCallback.apply(this);
}
});
}
return expr ? jQuery.filter(expr,this).r.length 0 : false;
},
The strength of this addition: is() returns the jQuery object, therefore
it does not break the chain. Your opinions?
-- J?rn
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
--
View this message in context:
http://www.nabble.com/Chainable-if-else---hot-or-not--tf2363128.html#a6592731
Sent from the JQuery mailing list archive at Nabble.com.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
Very useful. One thought: It might be nice to allow the elseCallback to run even when ifCallback is not provided. Maybe it should be added to .not() instead: .not(.foo, elseCallback, ifCallback) --John ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
[jQuery] Chainable if/else - hot or not?
Hi folks,
the thread about showing and hiding DDs when clicking DTs gave me an
idea for a chainable if/else construct. I have implemented and tested it
and now I'd like to know if this is useful enough to be released as a
plugin or even adding to the core.
Basically I extended the current is(String expression) method. It now
accepts one or two functions. If one is given, it will be executed for
every element that fits the expression. If the second function is given,
it will be executed for every element that does not fit the expression.
Applied to the click dt to show/hide dd example:
$(document).ready(function() {
$('#faq').find('dd').hide().end().find('dt').click(function() {
$(this).next().is(':visible',
function() { $(this).slideUp(); },
function() { $(this).slideDown(); }
);
});
});
The extended is method looks like this:
is: function(expr, ifCallback, elseCallback) {
if(ifCallback) {
var elseCalllback = elseCallback || function() {};
return this.each(function() {
if($(this).is(expr)) {
ifCallback.apply(this);
} else {
elseCallback.apply(this);
}
});
}
return expr ? jQuery.filter(expr,this).r.length 0 : false;
},
The strength of this addition: is() returns the jQuery object, therefore
it does not break the chain. Your opinions?
-- Jörn
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
That would definitely make my solution simpler. If it doesn't add too much to the core size, then I'd say yes.On 10/1/06, Jörn Zaefferer
[EMAIL PROTECTED] wrote:Hi folks,the thread about showing and hiding DDs when clicking DTs gave me an
idea for a chainable if/else construct. I have implemented and tested itand now I'd like to know if this is useful enough to be released as aplugin or even adding to the core.Basically I extended the current is(String _expression_) method. It now
accepts one or two functions. If one is given, it will be executed forevery element that fits the _expression_. If the second function is given,it will be executed for every element that does not fit the _expression_.
Applied to the click dt to show/hide dd example:$(document).ready(function() {$('#faq').find('dd').hide().end().find('dt').click(function() {$(this).next().is(':visible',function() { $(this).slideUp(); },
function() { $(this).slideDown(); });});});The extended is method looks like this:is: function(expr, ifCallback, elseCallback) {if(ifCallback) {var elseCalllback = elseCallback || function() {};
return this.each(function() {if($(this).is(expr)) {ifCallback.apply(this);} else {elseCallback.apply(this);}
});}return expr ? jQuery.filter(expr,this).r.length 0 : false;},The strength of this addition: is() returns the jQuery object, thereforeit does not break the chain. Your opinions?
-- Jörn___jQuery mailing listdiscuss@jquery.comhttp://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
Well done, Jörn! It makes me remember the work of John Klinger: http://jquery.com/discuss/2006-July/#7292 It reminded me of that too. I kind of like the simplicity of this solution. Doing a chainable .else() like what John K did is fundamentally really hard. --John ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Chainable if/else - hot or not?
Although, going back through his code - I really like what he did. He made it such that you no longer had to use anonymous function wrappers - which I really like. It'd be really cool to be able to do: $(#foo) .find(div) .click() .filter(.someclass) .addClass(test) .else() .addClass(someclass) .end() .end(); It looks like it also needs to be ported to 1.0.1. The code is here, for reference: http://dmlair.com/jquery/jqIfElse/ --John On 9/30/06, John Resig [EMAIL PROTECTED] wrote: Well done, Jörn! It makes me remember the work of John Klinger: http://jquery.com/discuss/2006-July/#7292 It reminded me of that too. I kind of like the simplicity of this solution. Doing a chainable .else() like what John K did is fundamentally really hard. --John -- John Resig http://ejohn.org/ [EMAIL PROTECTED] ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
