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) {
v
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 )
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
On Jun 11, 3:
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) {
case1 : $(this).css({ color: 'blue' }): break ;
case 2 : $(this).css({
> 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)
{
> ...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
> 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' });
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?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
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-cas
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; ihttp://groups.google.com/group/jquery-d
Am I too late for my good old If ElseIf Else ?
Its logic was different from every other plugin if I am not wrong:
http://plugins.jquery.com/project/IfElseIfElse
Regards
On Wed, Jun 10, 2009 at 7:08 PM, "Cowboy" Ben Alman wrote:
>
> Well, since we're nit-picking, I should've used call instead of
Well, since we're nit-picking, I should've used call instead of apply,
because it would net a 2 byte bandwidth savings!
- Cowboy
On Jun 10, 1:55 pm, "stephb...@googlemail.com"
wrote:
> P.S. Oh, and also, if !callback then we know predicate is not a
> function, so we shouldn't need to then test
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!
--~
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
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
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 s
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
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 seei
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
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 :)
On Jun 3, 2:25 pm, ajpiano wrote:
> In all
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
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 t
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 not
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
co
On Jun 2, 1:06 pm, ajpiano wrote:
> Over the years there has been considerable interest in providing
> conditional chaining functionality to jQuery, though nothing has ever
> been cemented.
I still don't understand the desire to do all this chaining. How is it
at all beneficial?
You take perfec
25 matches
Mail list logo
