[Prototype-core] Ajax.Request - eval()'ing the responseText
I had a problem today with eval()'ing the responseText after
Ajax.Request.
My problem was that my response was only text/javascript - an object
in JSON:
{
// properties of object using JSON
}
I even haven't notice that the same code worked about a week, and
everything was OK - no error, no exception.
Until I added onException handler to Ajax.Request constructor - my
application started to alerting users with errors.
I have found that:
- Prototype eval()s responseText automatically
- when eval()'ing, JavaScript parser looks for a block of statements/
expressions (?) (eventually enclosed in curly braces {}) and it gets
the object in JSON (surrounded in curly braces too)
- in evalJSON() Prototype encloses the header string with ordinary
braces ()
- the result of eval()'ing responseText isn't saved anywhere :-(
- to get the object represented by my responseText JSON string, I
have to eval() it again (ofc, enclosing in ordinary braces (), which I
have done from the begin).
I have tought a lot about it and wasn't sure who blame for this
exception, for necessity of eval()'ing twice excessively - me or the
Prototype team.
Now I think I should redesign my application and return the data using
X-JSON headers rather than responseText.
I only think it should be stated clearly in API Docs that evaling the
responseText isn't identical to evaling the X-JSON headers and that
the first one should be rather used for scripts to be executed (and
not remebered) and the latter only for JSON.
Or maybe it's a prototype design mistake - returning JSON with
responseText is OK and it shouldn't be evaluated automagically but
only on user demand. Or the other way round - it should be evaluated
but saved.
I'm not sure. Giving it under discussion :-)
Thanks for the great work :-)
DK
--~--~-~--~~~---~--~~
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: Empty catch blocks
On Apr 1, 11:00 pm, Andrew Dupont [EMAIL PROTECTED] wrote: (1) Try.these. I think the empty catch block is justified here. Me too. This code' purpose is to check for exceptions. (3) Event.stopObserving. The empty catch block is encountered in IE only. My guess is that detachEvent throws an exception if the specified observer doesn't exist on the element -- which addEventListener does not, so Event.stopObserving normalizes the behavior. But this is just a theory. It's up to designer of the code if stopObserving() can throw exceptions. Docs say that it U can pass function not attached as a listener previous, not throwing an exception. IMHO it's a very useful option. (2) Ajax.Responders.dispatch. It looks like the catch block is in place to ensure that every callback gets called. Otherwise a previous callback registered by someone else could throw an error and prevent your callback from firing. Does anyone else in Core know more about this? IMO this is the only case to disscuss. Greetings DK --~--~-~--~~~---~--~~ 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: Event.element() oddity
Hmm, maybe it's a little OT but I thought maybe sb doesn't already know, and would like to know :-) Apple Safari 3 public beta http://www.apple.com/safari/ Apple Safari will work on Windows too. On Jun 16, 3:57 pm, Thomas Fuchs [EMAIL PROTECTED] wrote: Note that IIRC the onload event for images is not supported (or rather, broken) on Safari 2. I've done an image loader thing the works cross-browser, but it's pretty much geared towards a specific use, so i really don't want to share this ATM (unless i clean it up first...). Best, Thomas Am 14.06.2007 um 18:17 schrieb jdalton: I created the ticket. It can be found here: http://dev.rubyonrails.org/ticket/8652 --~--~-~--~~~---~--~~ 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: $ function
I agree with jdalton - performance hit.
I agree also that you shouldn't use the same values for name's and
id's.
$() is made for one purpose - to find elements with given id. It
should be VERY fast in every case as it's a base function of
Prototype.
IMO, if found' element's id isn't the same as given, maybe function
should even return null:
[...]
if (typeof element == 'string')
{
var id=element;
element = document.getElementById(element);
// not found
if (element === null || !element.id || element.id!=id) {
return null;
}
}
return Element.extend(element);
[...]
On Jun 17, 11:36 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Wait for your solution, however this performance hit only occur in the
ie and opera and you select the input without an id attribute, maybe
1%'s probability. Will $$(*).detect take a very long time? long than
2 seconds? Is that posibble? Thanks
--~--~-~--~~~---~--~~
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: Inheritance: your thoughts?
On Jun 25, 7:50 am, Andrew Dupont [EMAIL PROTECTED] wrote:
On Jun 24, 7:48 pm, Tobie Langel [EMAIL PROTECTED] wrote:
I personally prefer the following syntax:
var Animal = new Class({
...
});
var Cat = new Class(Animal, {
...
});
I abhor this syntax. I wish I could put it any more mildly.
In languages with class-based inheritance, class creation and class
instantiation are two separate concepts. Defining a class is done
within a control structure. I can think of nothing more confusing than
instantiating Class to create your class, then instantiating your
class to create an instance of the class you just instantiated with
Class.
Yes, but JavaScript is different. The class is really a (function)
object in JavaScript - it isn't common, but this makes JavaScript a
very flexible language. We can't compare JavaScript in everything to
other OO languages.
This approach (using new) is very interesting and innovative for
me :-)
But other solutions are pretty too :-)
Also, I think that this.sup or this.$super would be safer than using
this.parent, which, in the realm of DOM scripting might be used pretty
often inside classes already.
this.$super is fine with me
parent is very popular name for an attribute. Please don't use it.
The most natural, IMHO, seems to treat all new attributes and methods
added by prototype as magic and prefix them with anything (as
prototype uses the dollar sign ($) frequently for added stuff, it
would be most natural choice again).
--~--~-~--~~~---~--~~
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: Inheritance: your thoughts?
On Jun 29, 8:22 pm, Tobie Langel [EMAIL PROTECTED] wrote:
How is Class a constructor ?
Constructor in JavaScript is a function, which called with
var someObject = new someFunction();
returns an object, which behaves similar to all objects created the
same way.
So in my implementation (as in Prototype) all the classes (the Class
objects), have the similar behaviour - the initialize() method of
their 'prototypes' is the method, run when the object that instantiate
them is created (ie new Animal()).
My Class is a constructor, because it returns such a function. I'm not
sure why is it possible, but it is, that you can overwrite what is
returned when using the 'new' operator in JavaScript. Normally, some
object is created. I return some object too, but this object is a
function in my case - a constructor.
Did I understand the question properly? Did my answer satisfied you?
Properties applied to it's prototype aren't available on the
instances.
Am I missing something here ?
Good notice.
No you don't - I did.
I forgot, that object returned from Class, doesn't have the methods
from Class.prototype. In my example it wasn't important, I think - the
initialize() method was the clue.
But adding such a line in Class function, adds such a requirement:
code
Object.extend(theConstructor, Class.prototype);
/code
Full Class code will look now:
code
/* constructor returning constructor */
var Class = function(classDef) {
// this = function() { } // throws error - assigning to 'this' not
allowed (not to mention it would be very ugly)
var theConstructor = function() {
this.initialize.apply(this, arguments);
}
// Add to the created class, all the methods set under
Class.prototype
Object.extend(theConstructor, Class.prototype);
// add classDef to the definition of the class (add all elements of
classDef to 'this')
Object.extend(theConstructor.prototype, classDef);
// returning class object constructror, instead of Class object
constructor
return theConstructor;
};
/code
So you can do now:
code
// standard class methods available in every class (in every Class
object)
Class.prototype.$super = function() {
document.write('$super(): I am the sublclass of some class...!');
};
/code
And after creating the Animal class, you can call:
code
Animal.$super();
/code
Which will print:
output
$super(): I am the sublclass of some class...!
/output
Corrected example available, as before, under:
http://dawid.krysiak.net.pl/webdev/js/21.js.constructors.for.constructors.html
Tested on the same set of browsers as before.
BTW: My code editor (jEdit 4.2), doesn't like the '$super' name for
the var name - it founds a super keyword (and highlights it like a
keyword), preceded by the $ dollar sign - ugly :-(
--~--~-~--~~~---~--~~
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: Inheritance: your thoughts?
On Jun 29, 8:22 pm, Tobie Langel [EMAIL PROTECTED] wrote: Properties applied to it's prototype aren't available on the instances. My implementation breaks this 'chain' (properties from 'prototype' accessible in objects created by 'new'), so I had to recreate it myself. PS. Sorry for my English. --~--~-~--~~~---~--~~ 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] tests fail in trunk head revision?
Let me preface this message with the fact that I've never contributed to Prototype before. I've been able to to pull down source from svn trunk and rake it but the tests never seem to all succeed in both IE and Firefox. Is there a stable revision that I should be looking at or is the head of the trunk expected to have all tests succeed. -dk --~--~-~--~~~---~--~~ 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: Hide / show bug
On Nov 23, 4:18 pm, Mislav Marohnić [EMAIL PROTECTED] wrote: [...] If CSS is hiding it, you must show it by explicitly setting style.display to block. 'block' if it should be a block, 'inline' if it should be an inline element, bixy, You better not think about other choices and listen to guys above ;-) Greetings --~--~-~--~~~---~--~~ 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] Starting noconflict support - putting $() into a namespace [reposted from Spinoffs group]
Changing topic :-) --~--~-~--~~~---~--~~ 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: Can the Enumarable iterators be changed to accept scope as the first param (optionally)
Enumerable.addMethod(myFunction) that takes care of all the classes that implement or extend it. Hmmm. We have Class#addMethods() already which makes exactly what you're talking about. Everything would be as simple as calling: Enumerable.addMethods(my_hash_of_methods); if Enumerable was a class. But it isn't! What it is when you think of it in terms of OOP? It is abstract class. It has some methods implemented but can't be instantiated and it has one interface method that has to be implemented by child classes. The problem is that Prototype doesn't support such a being.as an abstract class :-( If it did, the problem of extending/changing the Enumerable class (and it's children) would be solved. Just an idea :-) --~--~-~--~~~---~--~~ 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: ie try to load 'http://:/' right after prototype 1.6.x loaded
Why not use about:blank url? On Apr 9, 2:12 pm, John-David Dalton [EMAIL PROTECTED] wrote: This was originally used to allow this method to not have to pull down a real file and to avoid https issues in IE. This ticket:http://dev.rubyonrails.org/ticket/9394 Patches it to use a different method (maybe one that is more stable with IE7 as well) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
