[Prototype-core] Re: Assigning an unique ID
I totally agree Michael - there is no need to remove a level of general use
utility by making this method have to actually assign an id to an object.
The dev can handle doing whatever he wants with the newly gotten id...
someElement.id = $getId();
var newId = $getId("foo");
...do something with newId that may or may not involve assigning it to
something (who knows what this dev needs it for)
On 7/19/07, Michael Peters <[EMAIL PROTECTED]> wrote:
>
>
> Ken Snyder wrote:
>
> > Brainstorming in specifics, what about a method called
> > Object#assignGuid? After all, we are reading/writing a property of an
> > object.
>
> Why does this method have to assign the id to anything? Why can't it just
> create
> the id and return it? Then we could use it however we wanted. And if the
> most
> common use case is to assign as an elements id attribute, then we could
> also
> create the Element.identify() method that uses this
> static-uid-generating-method-thingy-with-no-name-yet.
>
> Also, guid is bad since the g stands for "globally", which it isn't. It's
> not
> unique to anything but the current page right? When I think of a guid I
> think of
> it being unique not just to the currently running context, but for any and
> all
> contexts in the future.
>
> --
> Michael Peters
> Developer
> Plus Three, LP
>
>
> >
>
--
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 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
-~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
On Jul 18, 2007, at 10:08 PM, Ken Snyder wrote:
> Object.assignGuid = function(object, prefix) {
> if (prefix === undefined) prefix = '__guid';
> if (!object.id) {
> object.id = prefix + (arguments.callee.nextId++);
> }
> return object.id;
> };
> Object.assignGuid.nextId = 0;
I like your version (although, I'd echo the argument that Guid isn't
appropriate because we're not generating _globally_ unique IDs),
however, a slight tweak:
Object.assignId= function(obj, prefix) {
if (obj.id)
return obj.id;
return obj.id= (prefix||"uniqueid_" +
arguments.callee._nextId++;
}
Object.assignId._nextId= 0;
Then we could add:
Element.Methods.assignId = Object.assignId;
So we have both a generic ID assigning method _and_ we have a method
on extended elements to assign an ID.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
Ken Snyder wrote: > Brainstorming in specifics, what about a method called > Object#assignGuid? After all, we are reading/writing a property of an > object. Why does this method have to assign the id to anything? Why can't it just create the id and return it? Then we could use it however we wanted. And if the most common use case is to assign as an elements id attribute, then we could also create the Element.identify() method that uses this static-uid-generating-method-thingy-with-no-name-yet. Also, guid is bad since the g stands for "globally", which it isn't. It's not unique to anything but the current page right? When I think of a guid I think of it being unique not just to the currently running context, but for any and all contexts in the future. -- Michael Peters Developer Plus Three, LP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
Sorry for the triple posts, as you may have noticed, Google Groups went really crazy today, and I really thought my messages just weren't going through. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
Hi again, Wrote a patch: http://dev.rubyonrails.org/ticket/9012 I ended up quite liking the "identify" method name so I went with it. It's obviously still open for discussion. Adding scope is trivial, so if there's a real use case we can do that too. Regards, Tobie --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
> Actually, this should really be so general as to not even be > specific to Element(s)... just a good old general purpose method > will do. While having a general purpose method would be nice, I think this is really something that ought to act on an element. The original use for assignId stems from a widget definition where the designers might have assigned an ID for styling purposes to sub- nodes of the widget. So rather than write: if (!node.id) this._myId= node.id= newUniqueId(); I found the following more convenient: this._myId= newUniqueId(); --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
> Jeff, Ryan: could you give me a use case for the scoped prefixes ? My > intial thought is to think they're overkill / too specific... but I > don't mind being prooved wrong. I don't exactly have a use case. I can see the overkill tendency. It's not the end of the world to create your own if this is a _really_ important feature. > I'm also concerned about naming the method adequately. Sam suggested > Element#denominate which looks nicer than (generate|assign)Id but > which I fear could be confused with setting the "name" attribute. The > only other option I came up with is Element#identify. Thoughts on this > issue ? I lean towards making the method name explicit: `assignId`. To my mind, `denominate` doesn't actually tell me what the method does. And `getId`, as Ken suggested, is not quite right, because it says nothing of the true purpose of the method: assign a new id if the node doesn't have one. If I liked to type more, I'd vote for `assignUniqueId`. > Also, I'm wondering whether the method should return the element - for > chaining purposes and to follow the general pattern of the other DOM > methods - or the generated id itself, which IMHO would proove more > useful here. Again, what are your thoughts ? Definitely return the id. You already have the node. And if you want the ID, which is presumably why you assigned one in the first place, it's inefficient to request it again later. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
Ken Snyder wrote: > The function seems more useful if it returns the id. I'd vote for the > name Element#getId(). Not getId() since that implies that the id already exists and this is simply retrieving it. createId() would be more indicative of what it does. But since all this does it create a unique identifier in the context of the current page, why limit it to just being a part of elements? I've used unique id generation stuff before that had nothing to do with an element's actual id. Here's some other possible names: String.createId() String.uniqueId() $id() $uid() -- Michael Peters Developer Plus Three, LP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
Well, in Ext, they just have something called Ext.id() which does something
similar.
I think in our case, just calling it .getId() would be good. I don't agree
though, that it should be an instance method on all elements, but rather
just a static method (Element.getId()) - therefore no question about what to
return (you're not doing it on any element, nor passing in an element -
you're just getting a new unique id), and also doesn't preclude developers
from having their own element level getId() implementations, which may or
may not exist already and may or may not necessarily even be related to
this. I really think applying new instance members to base object types
should be done only when _needed_ to avoid a lot of potential
integration/interop headaches.
so:
someElement.id = Element.getId();
The ability to specify the prefix could come in handy, for instance if
you're creating a grid control. You want developers to create an instance of
your grid control and give it whatever id they want, but then when you
generate the rows/cells you want to prepend that given widget instance id.
so:
var myGridInstance = new Grid("myGrid"); //sets this.id on the Grid instance
to "myGrid"
...add a dataset, tell it to render...
inside the Grid code where it creates the rows:
this.GenerateRows = function() {
...some loop...
var newRow = this.CreateRow(Element.getId(this.id + "_rows_"));
}
then somewhere else where I want to just get a quick reference:
var firstRow = $('myGrid_rows_0');
This is an exaggerated example, as you could just handle the row id
generation internally as well - but also consider the case where you have an
instance to your Grid, and then later want to add rows.
Anyway, I think there are probably enough cases to warrant the prefix
specification.
On 7/18/07, Tobie Langel <[EMAIL PROTECTED]> wrote:
>
>
> Pretty funny I actually ended up needing this very feature two days
> later...
>
> Anyway, working on a patch for it.
>
> Jeff, Ryan: could you give me a use case for the scoped prefixes ? My
> intial thought is to think they're overkill / too specific... but I
> don't mind being prooved wrong.
>
> I'm also concerned about naming the method adequately. Sam suggested
> Element#denominate which looks nicer than (generate|assign)Id but
> which I fear could be confused with setting the "name" attribute. The
> only other option I came up with is Element#identify. Thoughts on this
> issue ?
>
> Also, I'm wondering whether the method should return the element - for
> chaining purposes and to follow the general pattern of the other DOM
> methods - or the generated id itself, which IMHO would proove more
> useful here. Again, what are your thoughts ?
>
> Thanks for your valuable input,
>
> Tobie
>
> On Jul 14, 2:32 pm, Tobie Langel <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > 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;
> >
> > Regards,
> >
> > Tobie
>
>
> >
>
--
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 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
-~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
Ryan Gahl wrote: > -1 for identify (we're not talking about the act of identifying > something, but generating a unique id) -1 for same reason > -1 for making it an instance method on elements (see my last post for > reason) -1 for same reason > +1 for getId I actually like "create" better than "get" because "get" implies that it already exists. And I like "Uid" better than "Id" because it's not just an id, it's a unique id. > +1 for static method only (Element#getId) +1 > Actually, this should really be so general as to not even be specific to > Element(s)... just a good old general purpose method will do. > > +1 for pulling out to a general level +1 Just some random thoughts: maybe putting it in String since it returns a string? String.createUid()? Or maybe hanging it off of Prototype itself (seems like that would set a bad precedent for hanging tons of useful methods off of the Prototype namespace). In Perl land we have Data::UUID for stuff like this, so maybe we should introduce a Data namespace? -- Michael Peters Developer Plus Three, LP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
-1 for identify (we're not talking about the act of identifying something,
but generating a unique id)
-1 for making it an instance method on elements (see my last post for
reason)
+1 for getId
+1 for static method only (Element#getId)
Actually, this should really be so general as to not even be specific to
Element(s)... just a good old general purpose method will do.
+1 for pulling out to a general level
and of course,
+1 for allowing the dev to supply the prefix
...
+100 for whatever you decide to actually implement, because you're the one
doing the work :-)
On 7/18/07, Tobie Langel <[EMAIL PROTECTED]> wrote:
>
>
> Hi all,
>
> Don't know what's up with the google groups today... I posted an
> earlier message which hasn't appeared anywhere yet.
>
> Anyway, this is just to advise you that I posted a patch:
> http://dev.rubyonrails.org/ticket/9012
>
> I went with "identify" as a method name as I thought it's definition
> (establish or indicate who or what (someone or something) is) nicely
> fit what the method does and clearly refers to the id attribute.
> Obviously, that's still still open for discussion.
>
> Also, I didn't implement the scoping some of you suggested, but if
> there's a real use case for it, implementing it is trivial, so please
> speak up.
>
> Regards,
>
> Tobie
>
>
>
>
> On Jul 18, 10:57 am, Ken Snyder <[EMAIL PROTECTED]> wrote:
> > Tobie Langel wrote:
> > > ...
> > > I'm also concerned about naming the method adequately. Sam suggested
> > > Element#denominate which looks nicer than (generate|assign)Id but
> > > which I fear could be confused with setting the "name" attribute. The
> > > only other option I came up with is Element#identify. Thoughts on this
> > > issue ?
> >
> > > Also, I'm wondering whether the method should return the element - for
> > > chaining purposes and to follow the general pattern of the other DOM
> > > methods - or the generated id itself, which IMHO would proove more
> > > useful here. Again, what are your thoughts ?
> >
> > > Thanks for your valuable input,
> >
> > > Tobie
> >
> > The function seems more useful if it returns the id. I'd vote for the
> > name Element#getId(). Then you can call the function and always get an
> > id back regardless of whether the element has an id already. I like
> > Jeff Watkin's exact implementation. I think that the namespacing idea
> > is interesting but an edge case--creating groups of elements is as easy
> > as creating a hash:
> >
> > {"group1": [el1, el2, el3], "group2": [el4, el5, el6]}
> >
> > - Ken
>
>
> >
>
--
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 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
-~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
Hi all,
Don't know what's up with the google groups today... I posted an
earlier message which hasn't appeared anywhere yet.
Anyway, this is just to advise you that I posted a patch:
http://dev.rubyonrails.org/ticket/9012
I went with "identify" as a method name as I thought it's definition
(establish or indicate who or what (someone or something) is) nicely
fit what the method does and clearly refers to the id attribute.
Obviously, that's still still open for discussion.
Also, I didn't implement the scoping some of you suggested, but if
there's a real use case for it, implementing it is trivial, so please
speak up.
Regards,
Tobie
On Jul 18, 10:57 am, Ken Snyder <[EMAIL PROTECTED]> wrote:
> Tobie Langel wrote:
> > ...
> > I'm also concerned about naming the method adequately. Sam suggested
> > Element#denominate which looks nicer than (generate|assign)Id but
> > which I fear could be confused with setting the "name" attribute. The
> > only other option I came up with is Element#identify. Thoughts on this
> > issue ?
>
> > Also, I'm wondering whether the method should return the element - for
> > chaining purposes and to follow the general pattern of the other DOM
> > methods - or the generated id itself, which IMHO would proove more
> > useful here. Again, what are your thoughts ?
>
> > Thanks for your valuable input,
>
> > Tobie
>
> The function seems more useful if it returns the id. I'd vote for the
> name Element#getId(). Then you can call the function and always get an
> id back regardless of whether the element has an id already. I like
> Jeff Watkin's exact implementation. I think that the namespacing idea
> is interesting but an edge case--creating groups of elements is as easy
> as creating a hash:
>
> {"group1": [el1, el2, el3], "group2": [el4, el5, el6]}
>
> - Ken
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
Tobie Langel wrote:
> ...
> I'm also concerned about naming the method adequately. Sam suggested
> Element#denominate which looks nicer than (generate|assign)Id but
> which I fear could be confused with setting the "name" attribute. The
> only other option I came up with is Element#identify. Thoughts on this
> issue ?
>
> Also, I'm wondering whether the method should return the element - for
> chaining purposes and to follow the general pattern of the other DOM
> methods - or the generated id itself, which IMHO would proove more
> useful here. Again, what are your thoughts ?
>
> Thanks for your valuable input,
>
> Tobie
>
The function seems more useful if it returns the id. I'd vote for the
name Element#getId(). Then you can call the function and always get an
id back regardless of whether the element has an id already. I like
Jeff Watkin's exact implementation. I think that the namespacing idea
is interesting but an edge case--creating groups of elements is as easy
as creating a hash:
{"group1": [el1, el2, el3], "group2": [el4, el5, el6]}
- Ken
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
Pretty funny I actually ended up needing this very feature two days later... Anyway, working on a patch for it. Jeff, Ryan: could you give me a use case for the scoped prefixes ? My intial thought is to think they're overkill / too specific... but I don't mind being prooved wrong. I'm also concerned about naming the method adequately. Sam suggested Element#denominate which looks nicer than (generate|assign)Id but which I fear could be confused with setting the "name" attribute. The only other option I came up with is Element#identify. Thoughts on this issue ? Also, I'm wondering whether the method should return the element - for chaining purposes and to follow the general pattern of the other DOM methods - or the generated id itself, which IMHO would proove more useful here. Again, what are your thoughts ? Thanks for your valuable input, Tobie On Jul 14, 2:32 pm, Tobie Langel <[EMAIL PROTECTED]> wrote: > Hi, > > 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; > > Regards, > > Tobie --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
Ryan, that's a great idea. Although I don't anticipate using it often, I can easily see how this would be indispensable in some circumstances. On Jul 17, 2007, at 6:32 AM, Ryan Gahl wrote: > 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 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
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 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
Hi, 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; Regards, Tobie --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Assigning an unique ID
Jeff Watkins wrote:
> ...
> Element.Methods.assignId = function(element) {
> element= $(element);
> if (!element.id)
> element.id= "uniqeId_" + (arguments.callee._nextUniqueId++);
> return element.id;
> }
> Element.Methods.assignId._nextUniqueId=0;
> ...
+1 for such an addition. It is especially useful for object
hashing--being able to look up some data by element. It looks like the
YUI library uses a similar function called generateId() in their drag
and drop, menus, treeviews and more.
- Ken Snyder
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
