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:

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.



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 

Reply via email to