Remember a lot of us aren't Ruby-jockies... keep the function names _descriptive_ please :-) "unique" is better than uniq IMHO
On 8/14/06,
Thomas Fuchs <[EMAIL PROTECTED]> wrote:
That method should be named "uniq" (to match the ruby enumerables, which
Prototype heavily borrows from), and should be added to the Prototype
enumerables-- seems like a nice extension. :)
-Thomas
Am 14.08.2006 um 00:06 schrieb Martin Ström:
> And the little more elegant, prototypish way ;)
>
> Object.extend(Array.prototype, {
> unique: function() {
> return this.inject ([], function(array, value) {
> if (!array.include(value)) array.push (value);
> return array;
> });
> }
> });
>
> _$$_old = $$;
>
> function $$() {return _$$_old.apply(null, arguments).unique()}
>
> Ciao
> Martin
>
> On 8/13/06, Brian Peiris <[EMAIL PROTECTED]> wrote:
> Hey Sam, Seth,
> thank you both for your replies.
> Seth:
> Now I see why $$('#tree .node .nodeChildren') returns duplicates,
> and it looks like $$('#tree > .node > .nodeChildren') doesn't work
> ($$ probably doesn't support direct decendents yet, it returns and
> empty array).
> $$(' .nodeChildren') wouldn't work for me, elements with class
> '.nodeChildren' could be under two different trees ('#tree1' and
> '#tree2' for example).
>
> Sam:
> I agree with you, I discovered this problem while using
> event:Selectors to toggle an element on a click event, it took me a
> while to figure out that the toggle function was being called
> twice. It is un-intuitive that $$ returns duplicates, even though
> it is technically correct, I don't see where it would be useful,
> especially since it doesn't support direct descendants yet.
> Perhaps it is a bug, or perhaps we just have to wait till more
> advanced CSS selectors are supported
>
> Anyway,
> I just added few lines to the $$ function to return a unique array.
> If anyone wants to take a look at it quickly, there's probably a
> better way to do it (using prototype's array functions)
>
>
> function $$() {
> var nodes = $A(arguments).map(function(_expression_) {
> return _expression_.strip ().split(/\s+/).inject([null], function
> (results, expr) {
> var selector = new Selector(expr);
> return results.map(selector.findElements.bind
> (selector)).flatten();
> });
> }).flatten();
> var uniqueNodes =[];
> var i=0;
> for(i=0;i<nodes.length;i++){
> if(uniqueNodes.indexOf(nodes[i])==-1)
> {
> uniqueNodes.push(nodes[i]);
> }
> }
> return uniqueNodes;
> }
>
> Thanks,
> Brian
>
> On 8/13/06, Seth Dillingham <[EMAIL PROTECTED]> wrote: On
> 8/13/06, Sam wrote:
>
> > The node id node_3_children satisfies the criteria $('#tree .node
> > .nodeChildren') once for nodeID node_1, and once again for nodeID
> node_3.
> > The problem here is #tree .node .nodeChildren allows any number
> of elements
> > to appear between these attributes: e.g., there may be 3 <div
> > class="node">, all of class .node, between #tree .node
> and .nodeChildren.
> > If you want to specify direct descendents only, you could try $$
> ('#tree >
> > .node > .nodeChildren'), but I don't know if $$ supports direct
> descendents.
> > It probably does, but I've never had the opportunity to test.
> In my
> > experience, nothing works until you see it work.
>
> Sam,
>
> I think his point is that he wants a unique list from $$. It doesn't
> matter if there are ten ways to get to the same element, it should be
> checking to make sure an item is NOT already in the list before
> pushing it onto the list.
>
> You'd find it very frustrating if getElementsByTagName() returned the
> same element more than once in the result list. That's because you
> usually want to *do* something with the items in the list, and you
> don't want to process any of them more than once.
>
> If getElementsByTagName() did return some elements more than once, and
> the browser vendors explained that the reason is because of how they
> build the list, we'd all be quite disgusted. In this case, knowing WHY
> $$ returns the same element twice doesn't matter... that's not what we
> expect the function to do.
>
> Looks like a bug to me, Brian.
>
> Seth
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>
>
>
> --
> ============================
> Brian Peiris
> Brampton, Ontario, Canada
> [EMAIL PROTECTED] or [EMAIL PROTECTED]
> ============================
>
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>
>
>
>
>
> --
> burnfield.com/martin
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
