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 n
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 yo
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
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:
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
--~--~-~--~~-
> 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 s
> 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 t
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
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 ab
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
-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 s
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
(est
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. Thoug
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 conc
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 pref
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
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
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 G
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 u
19 matches
Mail list logo
