[Prototype-core] Prototype's Ajax object : motivations implementation
Hi everyone,
I just joined the group.
I glanced at the archive and was not able to find suitable answers to
my various questions regarding the motivations behind certains
features of the Prototype-1.6.0.2's Ajax object and their
implementations.
I will try to keep short but precise.
1) Ajax.Request's onStateChange() callback
Documentation states that onLoading callback (when readyState == 1)
is not guaranteed. It is more than that : it is *disabled by the
implementation* (1.6.0.2)
onStateChange: function() {
...
if (readyState 1 ...) fire_the_callback
}
A readyState value of 1 will result in *not firing* the callback.
I'm missing the reason for this (should it not be '=' ?)
2) Ajax.Response objects
A *new* Ajax.Response object is created *each time* the above callback
is fired.
I'm not sure to understand why is this necessary.
Instead, I envision a *single* Ajax.Response object per Ajax.Request,
to be updated as many times as necessary while the XHR progresses to
completion (readyState value).
The actual implementation results in some identical actions being
performed several times. For instance the slots
'responseText' (=String.interpret(transport.responseText)) and
headerJSON are computed twice, once when readyState becomes equal to 3
(Interactive), again when it becomes equal to 4(Complete).
What is the reason to this ?
3) JSON
A XHR can result in yielding a Javascript object in two ways :
- (a) from the X-JSON header
- (b) from the XHR responseText
These do not appear to be unified in the actual implementation.
For instance the option flag evalJSON (which defaults to true) does
not prevent the JS object from being built when JSON emerges from (a),
but does it when the JSON emerges from (b).
Moreover, the results are stored in two different slots : headerJSON
for(a) and responseJSON for (b), which might create confusion to the
casual Prototype programmer not attracted to reading the source code.
Again, I may be missing the real reason to this.
If possible, I would advise for a more unified interface.
I'm currently working at it through subclassing Ajax.Request in an
attempt not to modify the actual Prototype source code.
I would prefer to slightly modify the actual implementation, if
necessary and advisable, and offer my help for this.
Cheers,
Franck PORCHER
--~--~-~--~~~---~--~~
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: Prototype's Ajax object : motivations implementation
Franck Porcher, Docteur ès Sciences (Paris VI), Informatique théorique -- SMART Technologies Les solutions intelligentes -- Société de Services et d'Ingénierie en Informatique Solutions Open Source Linux FreeBSD 1995-2008 : Premier fournisseur en Polynésie française Tél: (689) 711 911 Email:fporcher(at)smartech(dot)pf Web: www(dot)smartech(dot)pf -- You can analyze the past but you have to design the future. Ignacio Coloma wrote: 2) Ajax.Response objects Instead, I envision a *single* Ajax.Response object per Ajax.Request, to be updated as many times as necessary while the XHR progresses to completion (readyState value). I know that every JavaScript implementation is single-threaded, but--theoretically--couldn't this lead to race conditions? (Eg. when Response instance changes while you're processing it) But if you spot places where you can reduce processing being done, optimization patches are always welcome. My humble opinion: I could store the response object elsewhere, and there is no real reason to forbid me from doing so (I hate when frameworks reuse the objects they handle to the developer). Is this not the case with the XHR ; being updated by low level Core Javascript while handled by the developper through whatever 'onreadystatechange' callback ? As such, the theoretical race condition mentionned by Mislav is intrinsic, wether we use Prototype's actual higher level callback API, or the low level Core XHR. And yes I do too hate when frameworks reuse objects they handle to the user. But I reconcile here by considering a Prototype Ajax.Request as kind of a temporal object (as opposed to snapshot object), going through states in a *monotonic* way (readyState only increases). In this light, I (the user) expect the object to evolve (another way of saying that the framework updates it), and I monitor it until it reaches its final state. So it bothers me to get different Ajax.Response objects over time. I feel that it would be easier to extract instantaneous views of a temporal long lived Ajax response object (cloning operation), should the need arise, than to build a temporal view from various independant instantaneous response objects. A matter of taste ;-) --~--~-~--~~~---~--~~ 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] Status of property 'name' within Class.create(d) functions
Hello,
I have been trying for days o understand what I have missed.
I have narrowed down the problem to this, where I create a simple class
'foo' that I extend to assign a private member 'name' set to 'FOO':
var foo = Class.create({});
Object.extend( foo, { name : 'FOO' } );
Then :
alert(foo.name)
surprisingly displays
klass
(instead of FOO)
Samething if I explicitely force the value to 'FOO'
foo.name = 'FOO'
Is there someone in the position to tell me what is going on, and why
foo's private member 'name' does not hold its value. This does not
happen if I choose another name for the private member.
This has been most upsetting to me for days now, and I fail to
understand what I am missing.
So thank you to anyone who would help me understand my mistake if this
is not a bug.
Franck PORCHER
--~--~-~--~~~---~--~~
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: Status of property 'name' within Class.create(d) functions
Yes Jeff, I'm using Firefox (Linux FreeBSD plat-forms).
And peering at the source code, one can see that Class.create() defines
an explicit klass() function, hence the 'klass' display.
Apparently, this property in not mutable. Something of a pain :-[
I will be reviewing prtotype's Class.create to see if we cannot achieve
the same result with an anonymous function, for which Firefox JS engine
*does not* expose anything in the name slot (I already tested this).
Franck
Franck Porcher, Docteur ès Sciences (Paris VI), Informatique théorique
--
SMART Technologies Les solutions intelligentes
--
Société de Services et d'Ingénierie en Informatique
Solutions Open Source Linux FreeBSD
1995-2008 : Premier fournisseur en Polynésie française
Tél: (689) 711 911
Email:fporcher(at)smartech(dot)pf
Web: www(dot)smartech(dot)pf
--
You can analyze the past but you have to design the future.
Jeff Watkins wrote:
Off the top of my head, I'd guess you're using FireFox. I know the JS
engine in FireFox (SpiderMonkey) exposes the name of a function via
the `name` property, however, I don't know whether that property is
mutable.
My guess, from the behaviour of your code, is `name` is not a mutable
property.
On 8 Jun, 2008, at 9:06 PM, Franck PORCHER wrote:
Hello,
I have been trying for days o understand what I have missed.
I have narrowed down the problem to this, where I create a simple
class 'foo' that I extend to assign a private member 'name' set to 'FOO':
var foo = Class.create({});
Object.extend( foo, { name : 'FOO' } );
Then :
alert(foo.name)
surprisingly displays
klass
(instead of FOO)
Samething if I explicitely force the value to 'FOO'
foo.name = 'FOO'
Is there someone in the position to tell me what is going on, and why
foo's private member 'name' does not hold its value. This does not
happen if I choose another name for the private member.
This has been most upsetting to me for days now, and I fail to
understand what I am missing.
So thank you to anyone who would help me understand my mistake if
this is not a bug.
Franck PORCHER
--~--~-~--~~~---~--~~
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: Status of property 'name' within Class.create(d) functions
Matter resolved.
Thanks to all of you.
Franck PORCHER
T.J. Crowder wrote:
I will be reviewing prtotype's Class.create to see if we cannot achieve
the same result with an anonymous function, for which Firefox JS engine
*does not* expose anything in the name slot (I already tested this).
Yes it does; it exposes a blank string:
function go()
{
var f;
f = function() { return 5; };
alert(typeof f.name == + typeof f.name);
}
...alerts typeof f.name == string not typeof f.name == undefined.
And the property is still read-only:
function go()
{
var f;
f = function() { return 5; };
alert(f.name (1) == + f.name);
f.name = flibbergibbett;
alert(f.name (2) == + f.name);
}
The second alert still shows the name as a blank string.
--
T.J. Crowder
tj / crowder software / com
On Jun 9, 5:50 am, Franck PORCHER [EMAIL PROTECTED] wrote:
Yes Jeff, I'm using Firefox (Linux FreeBSD plat-forms).
And peering at the source code, one can see that Class.create() defines
an explicit klass() function, hence the 'klass' display.
Apparently, this property in not mutable. Something of a pain :-[
I will be reviewing prtotype's Class.create to see if we cannot achieve
the same result with an anonymous function, for which Firefox JS engine
*does not* expose anything in the name slot (I already tested this).
Franck
Franck Porcher, Docteur ès Sciences (Paris VI), Informatique théorique
--
SMART Technologies Les solutions intelligentes
--
Société de Services et d'Ingénierie en Informatique
Solutions Open Source Linux FreeBSD
1995-2008 : Premier fournisseur en Polynésie française
Tél: (689) 711 911
Email:fporcher(at)smartech(dot)pf
Web: www(dot)smartech(dot)pf
--
You can analyze the past but you have to design the future.
Jeff Watkins wrote:
Off the top of my head, I'd guess you're using FireFox. I know the JS
engine in FireFox (SpiderMonkey) exposes the name of a function via
the `name` property, however, I don't know whether that property is
mutable.
My guess, from the behaviour of your code, is `name` is not a mutable
property.
On 8 Jun, 2008, at 9:06 PM, Franck PORCHER wrote:
Hello,
I have been trying for days o understand what I have missed.
I have narrowed down the problem to this, where I create a simple
class 'foo' that I extend to assign a private member 'name' set to 'FOO':
var foo = Class.create({});
Object.extend( foo, { name : 'FOO' } );
Then :
alert(foo.name)
surprisingly displays
klass
(instead of FOO)
Samething if I explicitely force the value to 'FOO'
foo.name = 'FOO'
Is there someone in the position to tell me what is going on, and why
foo's private member 'name' does not hold its value. This does not
happen if I choose another name for the private member.
This has been most upsetting to me for days now, and I fail to
understand what I am missing.
So thank you to anyone who would help me understand my mistake if
this is not a bug.
Franck PORCHER
--~--~-~--~~~---~--~~
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: Prototype vs Ext
Thanks Ryan. It's true, I love the feel of Prototype's OO model. I did some research and foudn in Ext's FAQ the following : /Up until version 1.0.1a, Ext required one of the following base libraries to be included: YUI, jQuery or Prototype/Script.aculo.us. Ext contains adapters that provide some of the basic plumbing utilities from those libraries, including Ajax support, animation, DOM manipulation, event handling, etc. Beginning with version 1.1, Ext includes a native Ext adapter, so the external libraries are no longer required(...)At the present time, Prototype/Scriptaculous support should still be considered experimental as there are several known bugs and unsupported functions that can cause problems with Ext./ Regarding your statement /My biggest message to you would be that they are _not_ mutually exclusive, and in fact work very well together/, looks like things are changing... Franck PORCHER www / smartech / pf -- --~--~-~--~~~---~--~~ 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: Prototype vs Ext
Thanks kangax Tobie for these excellent pointers. If I can stay out of Ext (no one knows for sure how it will evolve), I'd rather go for it. Best, - Franck --~--~-~--~~~---~--~~ 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] Unexpected/unwanted porn here
Receiving unexpected porn ads through this mailing list :-( Owner, thanks for removing the sender adress ([EMAIL PROTECTED]) from this group. Original Message Received: by 10.106.193.17 with SMTP id q17gr2758prf.0; Tue, 24 Jun 2008 15:13:57 -0700 (PDT) X-Sender: [EMAIL PROTECTED] Received: by 10.100.153.6 with SMTP id a6mr177245ane.0.1214345637102; Tue, 24 Jun 2008 15:13:57 -0700 (PDT) Date: Tue, 24 Jun 2008 15:13:56 -0700 (PDT) X-IP: 80.93.116.194 Message-ID: [EMAIL PROTECTED] Subject:[Prototype-core] Escort guide west michigan From: lasvegas [EMAIL PROTECTED] To: Prototype: Core prototype-core@googlegroups.com Reply-To: prototype-core@googlegroups.com Sender: prototype-core@googlegroups.com X-Google-Loop: groups Mailing-List: list prototype-core@googlegroups.com; contact [EMAIL PROTECTED] List-Id:prototype-core.googlegroups.com List-Post: mailto:prototype-core@googlegroups.com List-Help: mailto:[EMAIL PROTECTED] List-Unsubscribe: http://googlegroups.com/group/prototype-core/subscribe, mailto:[EMAIL PROTECTED] X-BeenThere:prototype-core@googlegroups.com Hot porn movies watch cool!!! There is free video. ... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [Prototype-core] Array toJson
Hi, Now, the conversion of array in Json String is managed in function Object#toJSON. Franck, On Thu, Feb 25, 2010 at 7:20 PM, Mila76 mil...@gmail.com wrote: Hi to all, thanks for all work on prototype js. I have a simple question, on this submit http://github.com/sstephenson/prototype/commit/038a2985a70593c1a86c230fadbdfe2e4898a48c array toJson is removed. Exist a better solution for this conversion? I use this function on my intranet program Thanks for your replies -- 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 prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -- 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 prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en
