[Prototype-core] Re: Assigning an unique ID

2007-07-19 Thread Michael Peters
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

[Prototype-core] Re: Assigning an unique ID

2007-07-19 Thread Jeff Watkins
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

[Prototype-core] Re: Assigning an unique ID

2007-07-19 Thread Ryan Gahl
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

[Prototype-core] suggestion: Object.applyDefaults

2007-07-19 Thread Jeff Watkins
This is similar to Object.extend, but you get back the original object and keys aren't overwritten: Object.applyDefaults = function(obj, defaults) { obj= obj||{}; if (!defaults) return obj; for (var p in defaults) { if (p in obj) continue;

[Prototype-core] Code formatting

2007-07-19 Thread Jeff Watkins
Does anyone know why the majority of code seems to get mangled like the first block? My guess is that Google is trying to be clever... On Jul 19, 2007, at 10:43 AM, Jeff Watkins wrote: > This is similar to Object.extend, but you get back the original > object and keys aren't overwritten: > >

[Prototype-core] Re: Code formatting

2007-07-19 Thread Mislav Marohnić
On 7/19/07, Jeff Watkins <[EMAIL PROTECTED]> wrote: > > Does anyone know why the majority of code seems to get mangled like the > first block? > I know. Google hates you because you don't use Pastie :) --~--~-~--~~~---~--~~ You received this message because you are

[Prototype-core] Help! Very werid behavior of Ajax.Request, I am desperate...

2007-07-19 Thread Paladin
Very simple task to do but never get it work. say I have a class called track function Track(){ this.id = 'a'; this.content = 'b'; } Track.prototype.update(){ this.content = 'b'; alert(this.content) //alert1 options.onSuccess = this.handle.bind(this); new Ajax.Request(url, option

[Prototype-core] Re: Help! Very werid behavior of Ajax.Request, I am desperate...

2007-07-19 Thread Paladin
And I found this weird behavior in ie and firefox. In ie it seem to work but in firefox no. On Jul 19, 4:08 pm, Paladin <[EMAIL PROTECTED]> wrote: > Very simple task to do but never get it work. > say I have a class called track > > function Track(){ > this.id = 'a'; > this.content = 'b'; > > } >

[Prototype-core] Re: suggestion: Object.applyDefaults

2007-07-19 Thread Jacob Rockowitz
Object.setConfig = function(defaults, config){return Object.extend(Object.clone(defaults), config || {});} I wrote this code using a suggestion posted to the Prototype.js support group. Personally, I don't think it needs to be in the core prototype.js code. I assumed it was one of those functio

[Prototype-core] Re: Help! Very werid behavior of Ajax.Request, I am desperate...

2007-07-19 Thread Skip Baney
If I understand you correctly, you are asking why alert3 doesn't show your response text. That's because the ajax request executes asynchronously this.content is still 'b' at that point and has yet to be changed by your handler method. If you need to execute the ajax request synchronously, th

[Prototype-core] Re: Help! Very werid behavior of Ajax.Request, I am desperate...

2007-07-19 Thread Paladin
I figured out the issue. It turned out that IE and firefox handles the function ajax calls in different way. I have to modify the prototype.js, to add a session id passed to Ajax.Request. So instead of function(transport, json), i modified it to function(transport, json, id) <- to mark a unique se

[Prototype-core] A Lightweight Set

2007-07-19 Thread Jeff Watkins
I've often found myself using an object literal as a Set and after wishing I had some real Set operators, I finally found the time to write them. I don't know whether this is core-worthy, but it might be helpful for someone else out there. Just a note, a

[Prototype-core] Re: A Lightweight Set

2007-07-19 Thread Tobie Langel
Hi Jeff, Wouldn't those methods be a better fit for the Enumerables or Hash ? Regards, Tobie On Jul 20, 1:04 am, Jeff Watkins <[EMAIL PROTECTED]> wrote: > I've often found myself using an object literal as a Set and after > wishing I had some real Set operators, I finally found the time to

[Prototype-core] Re: A Lightweight Set

2007-07-19 Thread Jeff Watkins
> Wouldn't those methods be a better fit for the Enumerables or Hash ? Both Hash and Enumerable add numerous keys to the "set". Or said another way, I can't store "keys", "values", "map", "find", etc in a Hash (unless I'm missing something clever). --~--~-~--~~~-

[Prototype-core] Re: A Lightweight Set

2007-07-19 Thread Tobie Langel
> Or said another way, I can't store "keys", "values", "map", "find", etc in a > Hash (unless I'm missing something clever). Yes you can... but they override the existing methods. So for example: $H({map: 2}) works as expected except you won't be able to use map or any method that relies on it