> This happens anytime one needs to reference an element without id:
>
> $$('[name="'+prop+'"]')[0]; // get element by name
> $$('tbody tr:first-child')[0]; // get first row of a table
> $$('img[src^="data:image"]')[0]; // get image with specified src
> attribute
Sure, that makes much more sense to me than '#sidebar #expandAll'.
> > ...But separately, if we think it's common to need to
> > select a single element on the basis of a CSS selector, I'd suggest an
> > explicit means of doing that (e.g., a separate function -- $$First()
> > comes to mind)...
>
> Another global function? ; )
Nah, we're namepsacing it, remember? ;-) Seriously, though, if it's
common to need to select a single element not by ID and act on it,
let's make that an explicit and efficient thing, rather than bending
the API of the node list thingy to suit the case of only *really*
wanting the first element. Doesn't matter (much) whether it's another
top-level function (although please, not literally with the name "$
$First()" -- blech) or an extension to something else (although I'd
leave $() -- which is otherwise very tempting -- lean and mean),
whatever. But using $$() to go get a single element seems wasteful to
me, it'll continue its recursive descent even after it has what you
want, and then it goes and puts a list around it, all to be thrown
away because you're just going to use the first element anyway.
FWIW.
-- T.J. :-)
On Aug 21, 3:45 pm, kangax <[EMAIL PROTECTED]> wrote:
> On Aug 21, 9:21 am, "T.J. Crowder" <[EMAIL PROTECTED]> wrote:
>
>
>
> > Hiya,
>
> > > > 2. FWIW, it seems to me that calling an accessor on a list should
> > > > return a list of the accessor results for each list element. Always.
> > ...
>
> > > This is tricky : )
> > > On one hand, having accessor act on all elements seems most intuitive
> > > and consistent with the current API. On the other hand, I can clearly
> > > see a case when getting "first value" is much more convenient.
> > > Considering that NodeList items can not be accessed via brackets,
> > > wouldn't we end up with a somewhat verbose syntax?
>
> > > $$('#sidebar #expandAll')[0].observe('click', function(){});
>
> > > becomes:
>
> > > $W('#sidebar #expandAll').source[0].observe('click', function(){});
>
> > Maybe I'm not understanding the example; I'm not a CSS guru by any
> > means. To me that looks like you're selecting an element with the ID
> > 'expandAll' if and only if it exists within an element with the ID
>
> Correct.
>
> > 'sidebar'. If so, that seems like quite an edge case to me (wouldn't
> > you know whether it was inside the sidebar?), but again, I think I
> > probably just don't get it.
>
> This happens anytime one needs to reference an element without id:
>
> $$('[name="'+prop+'"]')[0]; // get element by name
> $$('tbody tr:first-child')[0]; // get first row of a table
> $$('img[src^="data:image"]')[0]; // get image with specified src
> attribute
>
> etc.
>
>
>
> > > Perhaps, if we give NodeList a `first` method, it will make things a
> > > little less cryptic:
>
> > That sounds good. But separately, if we think it's common to need to
> > select a single element on the basis of a CSS selector, I'd suggest an
> > explicit means of doing that (e.g., a separate function -- $$First()
> > comes to mind) that returns a NodeWrapper (or undefined, of course)
> > and is optimized for that operation -- specifically, it stops as soon
> > as it's found one. More readable, perhaps slightly faster.
>
> Another global function? ; )
>
>
>
> > > > 3. Still don't like "source". That word is just way too overloaded,
> > ...
>
> > > I really like `source` but let's keep the naming aside for now : )
>
> > No problem. But you know I'll come back to it. :-)
>
> I know : )
>
>
>
>
>
> > > > 4. get() and set() methods: Great to have them, but I think it's
> > > > important that we not expect/require that people _use_ them.
> > ...
> > > Sure. We should recommend using them wisely and whenever it makes
> > > sense.
>
> > Good good, just checking.
>
> > > > 5. How will the list wrapper handle indexing into the list? E.g.:
>
> > > > var items;
> > > > var n;
> > > > items = $$('div.item');
> > > > for (n = 0; n < items.length; ++n)
> > > > {
> > > > items[n].update('This is item ' + n);
> > > > }
> > ...
>
> > > "each" always passes index as a second argument to iterator function:
>
> > I don't use each() unless I have a really good reason for the added
> > overhead or I know I'm dealing with so few elements that the added
> > overhead (dramatic, in IE's case) doesn't matter. I don't want people
> > to think I'm dissing each() and I don't want to start an each()
> > conversation. But it seems like people get so caught up in the
> > coolness of this stuff they they forget that function calls have a
> > cost, inline closures have an even higher cost. each() is really cool
> > and I love it, love the idea of it, love the expressiveness of it.
> > And implementations are making progress. But for now my default mode
> > will continue to be boring old-fashioned for/next loops (backward if
> > it doesn't matter and time is *really* of the essence) barring a
> > strong reason to do something else.
>
> JS1.7 introduces iterators but as of now they are of little use (in a
> web environment) : /
> If `each` is out of the question, then yes, your previous example
> should be fine.
>
>
>
> > > > 6. Question on $$(): I think the idea so far is that it returns a
> > > > NodeListWrapper. I'm guessing that that's a list of NodeWrappers
> > > > around the results of the query, right?
> > ...
> > > Yep, `source` of NodeList is an array of `Node`s.
>
> > Nodes? Or NodeWrappers?
>
> NodeWrappers.
>
> --
> kangax
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---
