On Aug 21, 7:13 am, "T.J. Crowder" <[EMAIL PROTECTED]> wrote:
> Hey folks,
>
> Weighing in briefly (being hammered at work and at home, and not in
> that fun way). Great stuff so far! Thoughts/opinions/questions:
>
> 1. IMHO, $$() should _always_ return a list/array/whatever, even if
> there's only one element; it should never return the NodeWrapper
> itself. Two reasons: A) Having a function that returns a list in
> some situations and a single element in another situations just means
> that every use of it has to check what it got back, leading to
> unnecessarily-verbose code and confusion on the part of users. If
> people are doing things like $$("#thingy"), tell them to use $(),
> that's what it's for. :-) If there's a really really good reason
> they're using $$() (for instance, they don't know what the selector
> is, it's supplied from elsewhere), well, then they should always be
> expecting to get back a list. B) That's what it does now.
>
> > > I don't think there would be confusion with things like $$
> > > (..).getValue() here.
>
> > > Keep in mind users do use the equiv of $$('#myId') and that in those
> > > cases you are expecting 1 result
> > > so the desired behavior of a readAttribute, or getValue or anything
> > > getting a property
> > > is to return from the only matched item.
>
> > True.
> > We could reduce ambiguity by having some kind of a generic rule - e.g.
> > "all accessor methods always act on the first item". This should be
> > fine, as long as there are no (or not many) exceptions.
>
> 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.
> Similarly, calling a setter on the list [e.g., $$
> ('.blarg').update('yada')] should call the setter on all list
> elements.
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(){});
Perhaps, if we give NodeList a `first` method, it will make things a
little less cryptic:
$W('#sidebar #expandAll').first().observe('click', function(){});
>
> > 1) NodeWrapper always exposes a public `source` property, which is a
> > reference to a wrapped element:
>
> 3. Still don't like "source". That word is just way too overloaded,
> and again, it's as much a target (e.g., of an update() call) as a
> source. "raw" is the best general term I've thought of, but I'm not
> married to it. Whatever we use should be *short* (so not
> "wrappedThingamajig") and as clear as feasible. Maybe we should give
I really like `source` but let's keep the naming aside for now : )
> up on the generic term (I *know* it was my idea, but...) and just use
> something meaningful for each wrapper, e.g. NodeWrapper.node,
> ListWrapper.list, etc. Keep 'em short, document 'em, and if people
> forget what the property for the wrapped thingy inside a
> NodeListWrapper is, too bad, at least the terms are short and clear.
>
> 4. get() and set() methods: Great to have them, but I think it's
> important that we not expect/require that people _use_ them. We're
> not, right? I don't want to make a function call to access tagName,
> I'll want to use "wrapper.source.tagName" (or "wrapper.raw.tagName")
> without the wrapper getting confused somehow.
Sure. We should recommend using them wisely and whenever it makes
sense.
>
> 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);
> }
>
> I'm not aware of a standard, widely-supported JavaScript feature that
> lets us define the subscript operator, so I'm guessing the above is
> out. Again I hate to introduce a function call for simple access
> [e.g., list.item(n), a'la Microsoft collections], so would I go to the
> underlying "raw/source"?
"each" always passes index as a second argument to iterator function:
$$('div.item').each(function(node, n) {
node.update('This is item ' + n);
});
>
> 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? So I could reliably rewrite
> my code above like this (I'll use 'source' rather than 'raw' here):
>
> var items;
> var list;
> var n;
> items = $$('div.item');
> list = items.source;
> for (n = 0; n < list.length; ++n)
> {
> list[n].update('This is item ' + n);
> }
>
> ...because although I'm accessing the raw list, it contains wrapped
> nodes. Is that the idea?
Yep, `source` of NodeList is an array of `Node`s.
--
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
-~----------~----~----~----~------~----~------~--~---
