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. > > -sam > > > > > -- Ryan Gahl Manager, Senior Software Engineer Nth Penguin, LLC http://www.nthpenguin.com -- Architect WebWidgetry.com / MashupStudio.com Future Home of the World's First Complete Web Platform -- Inquire: 1-262-951-6727 Blog: http://www.someElement.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
