If this does make it to core, I would then also suggest allowing the
developer to specify the prefix of the ID (default to "uniqueId").
Optionally, go so far as to track a separate incremented value per new
prefix, allowing the dev to essentially set up element groups. This would be
considered like namespacing the ids.
So you just need one more small step to store a hash of prefixes and their
corresponding current _nextUniqueId values.
On 7/14/07, Sam Stephenson <[EMAIL PROTECTED]> wrote:
> On Jul 14, 2007, at 1:32 PM, Tobie Langel wrote:
> > I'm failing to see what advantage it has over directly storing a
> > reference to the element like so:
> > this.myElement = $(e);
> > ...
> > var e = this.myElement;
> I'm using a similar technique in a couple of applications where I
> needed to cache references to parent nodes of certain elements. In
> order to avoid circular references, the parent nodes' IDs are stored
> in custom attributes and dereferenced with $().
> It's not always convenient to give those nodes IDs in HTML, so I
> settled an Element#denominate method that assigns IDs if they don't
> exist using a string prefix + new Date().getTime(). (I do like Jeff's
> suggestion of using an auto-incrementing value instead of a timestamp.)
> It's a good fit for core, IMO.
Manager, Senior Software Engineer
Nth Penguin, LLC
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at