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
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
[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
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/
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
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
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
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
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
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
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
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
$()
.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
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
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
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
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
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
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
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
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
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,
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
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,
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
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
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
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 ) //
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
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
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,
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
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
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:
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
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
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
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
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
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
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)
41 matches
Mail list logo
