Well, in Ext, they just have something called Ext.id() which does something

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.

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.

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

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
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 

Reply via email to