> > var el = new Prototype.Element(element);
> > el.raw, or el.obj, or el.wrapped, or el.source.
> > I kinda dig el.source
>
> `source` sounds good.
It's not very important, but I can't say "source" appeals. I think it
will be confusing in discussion. The underlying element is as much a
target as a source, and source is already an overloaded word. When
you call item.update(), the target (not source) of the update is the
underlying element. In terms of it being overloaded, suppose you have
a container element and you use select() to get an 'item' element from
somewhere within it. At that point, it's easy (but wrong) to read
"item.source" as meaning the container, since you got the item "from"
the container.
"raw" has grown on me. It's not overloaded, and it's pretty clear in
conversation: "Q. How do I get the tag name of a wrapped element? A.
From the raw element it's wrapping. Q. How do I get the real nodelist
from a wrapper? A. Use the 'raw' property to get the raw nodelist."
It's also short (we'll be using this a lot). The biggest negative I
see to it is that it's typed entirely with the left hand (if you're a
touch typist).
raw:
* * * *
var wel;
wel = $('mydiv');
if (wel.raw.childNodes.length == 0)
{
wel.update('<p class="note">No content</p>");
}
* * * *
vs. source:
* * * *
var wel;
wel = $('mydiv');
if (wel.source.childNodes.length == 0)
{
wel.update('<p class="note">No content</p>");
}
* * * *
Just for the sake of completeness, there's always the symbolic route,
for instance "_":
* * * *
var wel;
wel = $('mydiv');
if (wel._.childNodes.length == 0)
{
wel.update('<p class="note">No content</p>");
}
* * * *
...but that gets pretty cryptic pretty quickly. Mind you, the code
does look a bit like it's smiling at us. ;-)
All told, I think "raw" makes good sense.
--
T.J. Crowder
tj / crowder software / com
On Aug 18, 11:53 pm, kangax <[EMAIL PROTECTED]> wrote:
> On Aug 18, 11:27 am, John-David Dalton <[EMAIL PROTECTED]>
> wrote:
>
>
>
> > If a cache is to be used it can be uniquely marked via the same
> > approach as elements in the event system
> > element._prototypeWrapperId = [arguments.callee.id++];
> > the id is unique and doesn't transfer if you clone the node.
>
> > var instance = Prototype.Element.cache[ element._prototypeWrapperId ];
> > if (instance) return instance;
>
> > This would work well with this patch (allowing Class.create to return
> > a value).http://dev.rubyonrails.org/ticket/11481
>
> > Some host objects may not allow the addition of custom properties
> > though, and in
> > those cases they wouldn't get cached.
>
> > I like having a common property for the wrapped object (+1 for the
> > suggestion):
> > var el = new Prototype.Element(element);
> > el.raw, or el.obj, or el.wrapped, or el.source.
> > I kinda dig el.source
>
> `source` sounds good. I just looked at YUI3 and it seems like they
> only expose `_yuid` as a public property of their wrapper
> implementation - everything else is accessed via `get`/`set` (which is
> great, imo).
>
> I think having Node and NodeList wrappers should be enough from the
> start. NodeList could be returned by `$$` and implement some DOM
> methods which would operate on the entire collection:
>
> $('foo').show(); // operates on an element
> $$('div.foo').show(); // operates on a NodeList
>
> --
> 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
-~----------~----~----~----~------~----~------~--~---
