Re: [Prototype-core] Playing with Google's Closure Compiler and got a message for Prototype 1.7.0.0
On May 18, 2011, at 3:22 AM, Richard Quadling wrote: OOI, the Sizzle code wraps the access in a condition. Should this be ported to Prototype? We'll update to the latest version of Sizzle when we release 1.7.0.1. -- 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
Re: [Prototype-core] Playing with Google's Closure Compiler and got a message for Prototype 1.7.0.0
I had to look it up, because that's part of Sizzle [1], but accessing that
property does have a side effect, apparently. It makes the `selected` property
work correctly when something is selected by default.
That strikes me as a spurious thing for GCC to warn about — you wouldn't
typically expect property access to have side effects, but with getters/setters
now in JavaScript, it'll become more and more common.
Cheers,
Andrew
[1] https://github.com/jquery/sizzle/blob/master/sizzle.js#L598
On May 17, 2011, at 11:24 AM, Richard Quadling wrote:
Hi.
Using Google Maps API with Prototype. Playing putting it into Google
Closure Compiler.
Got a message ...
Number of warnings: 1
JSC_USELESS_CODE: Suspicious code. This code lacks side-effects. Is
there a bug? at line 4437 character 3 in prototype.js
elem.parentNode.selectedIndex;
^
which is ...
filters: {
enabled: function(elem){
return elem.disabled === false elem.type !==
hidden;
},
disabled: function(elem){
return elem.disabled === true;
},
checked: function(elem){
return elem.checked === true;
},
selected: function(elem){
elem.parentNode.selectedIndex; // line 4437
return elem.selected === true;
},
parent: function(elem){
return !!elem.firstChild;
},
empty: function(elem){
return !elem.firstChild;
},
It looks like they are right? From what I know, that statement isn't
going to do anything.
To see this in action...
Go to http://closure-compiler.appspot.com/home and enter ...
// ==ClosureCompiler==
// @compilation_level SIMPLE_OPTIMIZATIONS
// @output_file_name default.js
// @code_url
http://ajax.googleapis.com/ajax/libs/prototype/1.7.0.0/prototype.js
// @code_url
http://maps.google.com/maps/api/js?libraries=geometrysensor=false
// ==/ClosureCompiler==
// ADD YOUR CODE HERE
alert(1);
as the code to optimize.
Choose Simple from the list of optimizations.
Click Compile and then look at the warnings tab on the right hand side.
Regards,
Richard.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
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
Re: [Prototype-core] JSON encoding inconsistencies with host objects
On Mar 3, 2011, at 2:40 AM, andris wrote: The question is, should Prototype address it or is it a developers problem? Isn't the work of a JS library to smooth out these kind of inconsistencies - for example either falling back to a non native encoder with WebKit or forcing other browser to follow the same rules? Falling back to a non-native encoder isn't an option; it would result in a _massive_ performance drop, an issue far more severe than the one you're describing. Forcing other browsers to follow the same rules isn't an option; not only would it require us to do non-native JSON encoding for certain code paths, it would also require us to comb an object for any references to host objects to know whether or not we'd need to bypass the native encoder. So it's got to be the developer's problem because there's nothing Prototype can do, even if we wanted to. Cheers, Andrew -- 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
Re: [Prototype-core] IE8: Out of stackspace error
It doesn't sound like it's a JSON issue. Can you set a breakpoint on the first line of _destroyCache and see what path it's taking through the code? That function shouldn't get anywhere near the call stack limit, so I suspect there's accidental infinite recursion happening somehow. Cheers, Andrew On Feb 14, 2011, at 10:22 AM, Johan Arensman wrote: Hey all, I've updated the prototype version in my application from 1.6.0.3 to 1.7. Everything works just fine except for the fact that IE8 gives Out of stackspace errors. The app dynamically loads several html pages / javascript files when you open different 'modules'. After the 1.7 update this still works fine, no errors but when I click a link to move to another page (so actually reload my page, no ajax call) I get the Out of stackspace error. After some Googeling i found: http://groups.google.com/group/prototype-scriptaculous/browse_thread/thread/f5878ea837bbaf3d/d19856a81273df80 with the same error but here it's caused by the JSON parser. I haven't used the JSON object at all, and the pages that are loaded don't use any JSON methods. I've mailed with Tobie Langel to ask what the fix was for the JSON parser, but he replied: Oh, sorry, looked at the bug report again. No, your issue wasn't fixed and the only way I can imagine having it fixed is to either stop using Prototype or not use native JSON in IE8. When I press debug, and take a look at the stacktrace I see that the _destroyCache method is called and the out of stackspace error occurs when stopObserving is called on the registry. Is this the cleanup routine from Prototype on unload? I'm totally lost on how to handle this and I really don't want to revert to 1.6.0.3 Any tips are welcome! Greetings, Johan -- 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
Re: [Prototype-core] Re: Suggested alteration to PrototypeJS' Object.keys implementation.
This is great stuff. Due to its breadth, however, it will have to wait until
1.7.0.1, for which we've got a bunch of other ES5-compatibility fixes planned.
If you and kangax think it would be worth getting the initially-proposed fix
into 1.7, then I'll try my best to do so.
Cheers,
Andrew
On Oct 22, 2010, at 5:41 AM, Andy E wrote:
That's great work. I've found myself on your blog a few times in the
last few weeks, but I hadn't seen this. I hope you don't mind, I used
it to update the example on my blog to:
(function () {
var hasOwnProperty = Object.prototype.hasOwnProperty,
hasDontEnumBug = true,
DontEnums = [
'toString',
'toLocaleString',
'valueOf',
'hasOwnProperty',
'isPrototypeOf',
'propertyIsEnumerable',
'constructor'
],
DontEnumsLength = DontEnums.length;
for (var k in {toString:null})
hasDontEnumBug = false;
Object.keys = Object.keys || function (o) {
if (typeof o != object typeof o != function || o ===
null)
throw new TypeError(Object.keys called on a non-object);
var result = [];
for (var name in o) {
if (hasOwnProperty.call(o, name))
result.push(name);
}
if (hasDontEnumBug) {
for (var i = 0; i DontEnumsLength; i--) {
if (hasOwnProperty.call(o, DontEnums[i]))
result.push(DontEnums[i]);
}
}
return result;
};
})();
You may notice that I sacrificed one of your optimizations for
brevity, I'm not sure the benefits would be noticeable in every day
use. A library like Prototype may benefit from such an optimization,
however.
by the way, I noticed that your implementation will have problems when
walking the DontEnum properties in Internet Explorer - it looks like
you copied and pasted the line of code from the for...in loop to your
for loop but forgot to change the variable that was passed in to the
iterator function.
iterator.call(context || iterator, prop, object[prop]); //
References to `prop` should be `DontEnumProperties[i]`
Or store DontEnumProperties[i] in a variable for a small optimization.
On Oct 21, 9:48 pm, kangax kan...@gmail.com wrote:
On Oct 21, 12:11 pm, Andy E andyearns...@gmail.com wrote:
kangax: I was thinking the same earlier (about caching the
hasOwnProperty), when I realized that my method incorrectly doesn't
allow functions to be passed (not sure about Prototype's original
one). I've updated the function on my blog to:
Object.keys = Object.keys || function (o) {
if (typeof o != object typeof o != function || o === null)
throw new TypeError(Object.keys called on a non-object);
var result = [], hop = Object.prototype.hasOwnProperty;
That's better, but nothing is stopping from taking it a step further,
aliasing `hasOwnProperty` outside of the method.
for (var name in o) {
if (hop.call(o, name))
result.push(name);
}
return result;
};
Regarding the DontEnum bug, you could work around that by checking
them explicitly hasOwnProperty outside of the for...in loop.
Exactly ;)
See for example `Object.forIn()` that I experimented with a couple of
years ago (wow, how time flies...)
—http://github.com/kangax/protolicious/blob/master/experimental/object...
Looking at the code now, I would simplify it slightly, but the idea
holds.
[...]
--
kangax
--
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
Re: [Prototype-core] Re: Suggested alteration to PrototypeJS' Object.keys implementation.
Well, this is the entire change; only unit tests are missing, and I think we
can add those ourselves if need be. Thanks, Andy!
I think this is small enough that it can still make it into 1.7 (which we're
days away from releasing), but others may disagree.
Cheers,
Andrew
On Oct 20, 2010, at 4:05 PM, Tobie Langel wrote:
Patch welcomed.
On Oct 14, 10:45 pm, Andy E andyearns...@gmail.com wrote:
I recently discovered that several compatibility implementations of
Object.keys() on the web will throw an error for DOM objects in
Internet Explorer 8 and lower. This differs from the current browsers
having a native implementation and how the ECMAScript 5th edition
defines the behaviour of Object.keys.
The problem lies with the hasOwnProperty() check, which is not a valid
method on Internet Explorer DOM objects because they aren't instances
of Object. The fix is very simple; borrow hasOwnProperty() from
Object.prototype.hasOwnProperty() instead. The fixed PrototypeJS
implementation would be:
function keys(object) {
if (Type(object) !== OBJECT_TYPE) { throw new TypeError(); }
var results = [];
for (var property in object) {
if (object.prototype.hasOwnProperty.call(object, property)) {
results.push(property);
}
}
return results;
}
I've outlined the issue in more detail on my
blog:http://whattheheadsaid.com/2010/10/a-safer-object-keys-compatibility-
Cheers,
Andy E
--
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
[Prototype-core] Re: CSS object standardisation.
I can't say that we're considering adding this into core, but seems like it would be an excellent plugin. I know I'd use it. Cheers, Andrew On Jul 6, 12:38 pm, John W. Long m...@johnwlong.com wrote: Yes please. Better support for CSS rules would be awesome. --John On Thu, Jul 1, 2010 at 6:23 AM, Richard Quadling rquadl...@gmail.com wrote: Hi. I use Prototype a lot and the one thing I find most useful is the level playing field it provides me. Prototype covers AJAX and HTML Elements very well in this regard. Are there any plans to do the same with CSS? Specifically in using JS to add/remove/alter CSS rules. Code likehttp://www.hunlock.com/blogs/Totally_Pwn_CSS_with_Javascript suggests that this code be a pretty simple task. Regards, Richard. -- 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 athttp://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
Re: [Prototype-core] measure surrounding size
Tom, the margin-height key does the same thing.
Cheers,
Andrew
On May 9, 2010, at 8:02 AM, Tom Nijns wrote:
Hi,
I love the new measure and layout features but like to see something
added.
When creating userinterfaces, I regulary need to know the surrounding
height or width of an element in order to resize it correctly. Now I
use my own function that aggregates padding, border and margin.
Perhaps $(elm).measure('surrounding-height') could do the same.
--
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
Re: [Prototype-core] Any intention of providing a function.throttle?
I like this. I don't particularly care what we call it.
Too late for 1.7, naturally, but perhaps 1.7.1 or 1.8...
Cheers,
Andrew
On Apr 23, 2010, at 10:15 AM, Mislav Marohnić wrote:
On Fri, Apr 23, 2010 at 15:00, Titi Alailima tigreti...@gmail.com wrote:
debounce is a technical term, and it refers to the very case that you are
trying to handle.
Thanks, Titi, for the insightful explanation.
Here is how I would implement a real throttle method:
Function.prototype.throttle = function(t) {
var timeout, scope, args, fn = this, tick = function() {
fn.apply(scope, args)
timeout = null
}
return function() {
scope = this
args = arguments
if (!timeout) timeout = setTimeout(tick, t)
}
}
It's really just a twist on the original method in a way that it fires every
`t` milliseconds, and calls in-between do nothing except update the scope and
arguments. If the first argument is an event object, you definitely want the
last event object of the series rather than the first one.
--
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
Re: [Prototype-core] Wish for Prototype 1.7 final: document.on(submit)
I think jQuery figured out a solution for this — care to do some research,
Mislav?
Cheers,
Andrew
On Apr 23, 2010, at 12:45 PM, Mislav Marohnić wrote:
The submit event doesn't bubble up in Internet Explorer after it originates
in a form. That makes it impossible to catch with event delegation:
document.on(submit, function(e) { ... })
Kangax wrote about a way we can detect even support without browser sniffing:
http://perfectionkills.com/detecting-event-support-without-browser-sniffing/
We have good custom events support, so we should be able to emulate submit
event bubbling in IE. There are a couple of approaches:
1) Stick a real submit handler directly on each form and make it fire a
custom submit event on the form's parent:
$$('form').invoke('observe', 'submit', ...)
Pros: easy.
Cons: doesn't work with dynamically created (or inserted) forms, making this
solution too brittle.
2) Forms can be submitted in two ways: clicking/tapping one of the submit
buttons, or pressing Enter. Both of these events bubble, so we can detect
where the submit originated from and fire a custom event from there.
Pros: works with dynamically created forms.
Cons: potentially complex solution. Unnecessary observing of all clicks and
keypresses on the page?
3) Observe when a form element gains focus with focusin event, then stick a
real submit handler to it which in turn fires the custom event.
Pros: less complex than click/keypress.
Cons: not sure if it's possible to submit a form without triggering a
focusin event first, but if it is then this solution is brittle.
I'll do more testing later. But right now, what are your opinions? Do you
have any other ideas how we could hook into forms on the page and trigger
custom submit events?
--
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
[Prototype-core] Re: getters/setters and patches
On Feb 8, 12:22 pm, Clint Priest cpri...@warpmail.net wrote:
I've been playing with getters and setters lately, namely the get
XXX() { } and set XXX(value) { } format and I've noticed that
prototype 1.6.1 doesn't play well with them.
What doesn't work, specifically? I have a couple ideas, but haven't
tried.
I'd be happy to write a patch for it, don't want to duplicate effort.
Also based on the contribute page of prototypejs.org it mentions
git://github.com/sstephenson/prototype.git but that doesn't look like
its had any development there.
How do you mean? It's an active repo.
What can I do to pitch in and help? I have some other .wrap()
functionality I've written to add features to prototype that would be
useful to patch in possibly.
Patches are always accepted. Submit enhancements to our Lighthouse
tracker (https://prototype.lighthouseapp.com/projects/8886-prototype/
overview).
Cheers,
Andrew
--
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
Re: [Prototype-core] Ajax.Request Interface
Thanks, Joran. We have plans to start from scratch with Ajax in Prototype 2.0; I think our ideas are mostly along the same lines as yours. I also want to fix some of the annoyances of the current API, hopefully for 1.7. Cheers, Andrew On Dec 11, 2009, at 7:07 AM, Joran Greef wrote: From: https://prototype.lighthouseapp.com/projects/8886/tickets/961-ajaxrequestsetrequestheaders-sets-content-type-header-as-content-type-and-sets-it-regardless-of-whether-its-provided-to-the-ajaxrequest-interface-and-other-issues The interface of the Ajax.Request object has a few problems: 1. Too many implicit defaults (Accept, Content-Type, charset etc). 2. Does not model the interface of HTTP. 3. 'requestHeaders' are provided as an option, 'encoding' as an option, 'contentType' as an option, when 'encoding' should be specified as 'charset' as part of the 'Content-Type' header which should be a subset of 'requestHeaders'. 4. If the request headers are provided as 'requestHeaders' then the request body needs to be provided as 'requestBody' not as 'postBody'. REST concepts such as method, uri, headers, parameters, representation should not be fused (e.g. 'XMLHttpRequest' which fuses the content type and the protocol, or 'postBody' which fuses the method and the representation). 5. 'requestHeaders' smells. 6. For method overriding, the 'X-Http-Method-Override' header would be better than the '_method' parameter. 7. It's not memorable. One has to keep looking up the Ajax options in the documentation (and where things get implicit, in the implementation). Here's a better (and more memorable) interface: Http.get/set/unset(uri, options) where 'options' has the following properties: 'headers', 'parameters', 'representation', onSuccess, 'onTimeout', 'onFailure', and where the response object passed to the callbacks has the following properties: 'status', 'headers', 'representation'. Http.delete can't be used as 'delete' is a reserved word. Http.set does a POST with the 'X-Http-Method-Override' header set to 'PUT' so as to be idempotent where the server supports PUT. Http.unset does a POST with the 'X-Http-Method-Override' header set to 'DELETE'. -- 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
[Prototype-core] Re: Element.classNames()
On Nov 3, 2009, at 3:54 AM, Richard Quadling wrote: According to [1], you will get a string back, not an array of strings. Nope — that's the notation for returning an array of strings. Can you supply an example page? I second this request. Cheers, Andrew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Element.Layout class coming in 1.7. Need feedback!
Yes, the Element.Layout class is imminent. In fact, it's already here. Take a look: http://github.com/sstephenson/prototype/blob/layout/src/dom/layout.js I've posted layout code before; this is the same code with a couple more refinement passes. You can read the included PDoc comments to get an idea of how it works. You can inspect it more closely by grabbing the layout branch in the GitHub repository. I've tested in Firefox 3.5, Safari 4, and IE 6-8. All the unit tests pass. But the unit tests are incomplete. So I need a little help. Can you guys let me know of any specific layout/measurement quirks you've encountered? Anything that's a bit obscure? Anything which Prototype 1.6 doesn't measure properly (with Element#getStyle and Element#[positioned|viewport|cumulative]Offset)? Cheers, Andrew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Function.EMPTY and Function.K
On Oct 15, 2009, at 4:22 AM, T.J. Crowder wrote: Hey Andrew, Aren't all functions constants, in that sense? Function.EMPTY isn't more or less constant than Element.extend. Function.IDENTITY and Function.EMPTY are never called directly, though. They're canonical functions. Meh, if I'm the only one who thinks of them that way, I'll shut up. But I want to hear from more people. Cheers, Andrew -- T.J. ;-) On Oct 15, 1:08 am, Andrew Dupont goo...@andrewdupont.net wrote: Weighing in again, decades after starting the thread. First, I'm fine with calling it Function.IDENTITY instead of Function.K. On Sep 25, 2009, at 1:26 AM, T.J. Crowder wrote: Make sense. Shouldn't that be Function.empty and Function.k, though, to follow our naming rules? And perhaps Function.k should have a more meaningful name. I'm very much in favor of all-caps, or at least initial caps, to indicate that these are constants. We don't do this consistently in the framework so far, but I'd like it to match stuff like Event.KEY_ESC. I think the capitalization will also help distinguish it from String#empty and Array#empty, as was mentioned elsewhere. (Aside: I'm also in favor of renaming those methods to `isEmpty` for 2.0.) What do people think about the capitalization? Cheers, Andrew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Function.EMPTY and Function.K
Weighing in again, decades after starting the thread. First, I'm fine with calling it Function.IDENTITY instead of Function.K. On Sep 25, 2009, at 1:26 AM, T.J. Crowder wrote: Make sense. Shouldn't that be Function.empty and Function.k, though, to follow our naming rules? And perhaps Function.k should have a more meaningful name. I'm very much in favor of all-caps, or at least initial caps, to indicate that these are constants. We don't do this consistently in the framework so far, but I'd like it to match stuff like Event.KEY_ESC. I think the capitalization will also help distinguish it from String#empty and Array#empty, as was mentioned elsewhere. (Aside: I'm also in favor of renaming those methods to `isEmpty` for 2.0.) What do people think about the capitalization? Cheers, Andrew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Memory Leak in IE
We've talked about doing this before, but there are a couple problems. First, we can't do what you're suggesting for Element#remove — the function returns the removed element, which may then be appended somewhere else in the document. If the element is going to be discarded, then one ought to remove its listeners; but if it will be reused, the user would expect those listeners to remain. I'm not sure how to get around this. We have also talked about removing event listeners on an Element#update call, but are hesitant to do so automatically for performance reasons. But we may yet implement this. Thanks! Andrew On Sep 30, 2009, at 6:26 AM, kef wrote: Hello, I am currently working on an AJAX application (prototype 1.6.1). As usual, it runs very well on Chrome and Firefox but we encounter difficulties, particularly with Internet Explorer 6. After much research, it appears that the problem is related to the memory leak. In fact, i reload only some parts of page. (I keep always the header and footer) so a large part of the memory used is never released. I found a solution partially responsive to my needs but it involves changing the core prototype. Prior to Ajax call, I clean all events on elements will be replaced (like _destroyCache during the unload of window). There may be a cleaner solution but I have not found. My changes here: remove: function (element) ( / / Begin Fix if (element = $ (element)) element.stopObserving (false, true); / / End Fix element.parentNode.removeChild (element); return element; ) stopObserving function (element, eventName, handler) ( element = $ (element); / / Begin Fix if (handler === true) ( for (var i = 0, length = CACHE.length; i length; i + +) if (CACHE [i]. descendantOf CACHE [i]. DescendantOf (element)) ( Event.stopObserving (CACHE [i], eventName); CACHE [i] = undefined; ) CACHE = CACHE.reject (Object.isUndefined); ) / / End Fix ) In view of the evolution of AJAX and implementation of Internet Explorer browsers, I think it may be advisable to incorporate a equivalent system in core of prototype. Regards, 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 prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Function.EMPTY and Function.K
Unless anyone has serious objections, or has a better idea, I'm going to add these as aliases of `Prototype.emptyFunction` and `Prototype.K`, respectively. They belong better there, since in theory the `Prototype` namespace is for internal stuff, not for stuff that has value to end-user developers. Cheers, Andrew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Style Issues in new API Docs
On Sep 13, 2009, at 5:24 PM, T.J. Crowder wrote: This is already fixed in the latest trunk and so will be fixed quite soon the next time the docs are re-generated from the source. In fact, I re-generated the docs earlier today. Cheers, Andrew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Prototype-Base Overlay and Best Practices
On Jun 4, 2009, at 8:36 PM, Luisgo wrote: 1. Is there a better way to handle callback definition? See lines 7-11. You've got the right idea here. I'd use `Prototype.emptyFunction` instead because there's no reason to define more than one empty function, but this is of negligible importance. 2. Is there a better way of referring to body? See line 33. `$(document.body)` would be more concise. Works in all browsers I'm aware of. 3. Is there a better way of injecting callbacks into functions so I don't have to clutter methods like on and off? See lines 81, 91, 98, 108. You seem reluctant to keep them on the `settings` object — why? Only difference is that you'd call `this.settings.onBeforeOpen()` instead. Scope would be preserved. A _different_ approach to callbacks would be to use custom events — to fire modal:opened:before and modal:opened:after (etc.) — but there are pros and cons for each. 4. Is there a way to use prototype classes that take an element as extensions to such element? Meaning, I would like to be able apply a click observer to the instance of the class directly. Something like: `modal.observe(click, someHandler)` and have that passed to the element to which the class is applied to. In the class: `this.element` or in this example `modal.element` No, but if you wanted that sort of thing, you could write your own `observe` method which passed all its arguments to `modal.element.observe`. Cheers, Andrew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Form.serialize additional functionality ...
On Apr 16, 10:44 am, mr_justin gro...@jperkins.otherinbox.com wrote: Has the topic ever came up to add the ability to serialize elements of a form just but only within a certain container element? Not as such, no. But we've had thoughts to make the serialization logic itself pluggable. The last time we broached this topic, there were heated exchanges about key/value pair serialization, and whether the conventions popularized by Rails and PHP were justifiable defaults. Not quite what you're talking about (which I do think is too esoteric), but should make your thing easier. No idea when we'll get around to that, though. ;-) Cheers, Andrew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Permission denied error from 'rake doc'
On Apr 8, 2:26 am, Richard Quadling rquadl...@googlemail.com wrote: Having refreshed my prototype checkout (along with the submodules), the sprockets issue is still present. Ball's still in Sam's court on that one. If it doesn't get fixed soon I'll ask him for commit access to the Sprockets repo so I can fix it myself. As the file is unique, what benefit does setting the timestamp have? For windows, this will be updated automatically anyway. At that point in the Sprockets code, it doesn't know that it's writing to a tempfile. It could be writing to a file that already exists. Though it is VERY VERY slow. I can build our PHP manual from DocBook XML to CHM in about the same time. And that contains over 8,500 pages from a single 23MB XML file (which is first concatenated from over 12,500 XML files). Yeah, PDoc is slow. We think it's because there's an obscenely large number of objects being created during the parsing phase — and the fact that they're all kept around during the generation phase. (Time to generate grows exponentially — when I switch the task to process only, say, the Ajax files, it takes _far_ less time.) At some point, Tobie and I will change PDoc to include an intermediate stage that takes the objects from the parsing phase and converts them into lightweight objects that have only the information we need. Fun fact: it takes less time to generate docs for Prototype within my Windows VM (in VMWare Fusion, 512MB RAM) than it does in OS X (2GB RAM). Cheers, Andrew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Permission denied error from 'rake doc'
OK, fixed it. This was caused by a recent commit to PDoc that fixed
one problem but introduced another.
Cheers,
Andrew
On Apr 7, 5:44 am, T.J. Crowder t...@crowdersoftware.com wrote:
Thanks Richard. I've opened ticket #647[1] for it, just to track it.
I don't think this needs to get in the way of the doc tickets I'm
trying to clean up.
[1]https://prototype.lighthouseapp.com/projects/8886-prototype/tickets/647
-- T.J.
On Apr 7, 11:15 am, Richard Quadling rquadl...@googlemail.com wrote:
2009/4/7 Richard Quadling rquadl...@googlemail.com:
2009/4/7 Richard Quadling rquadl...@googlemail.com:
2009/4/7 T.J. Crowder t...@crowdersoftware.com:
Thanks. With the latest, on Windows if I also comment out the atime
line, building the docs goes through to completion. However, the
generated doc seems to have issues: For instance, if I go into
index.html, then choose Language Section from the menu, if I click
on $A on the Utilities line on the page, I get a 404 for language
\dollara.html.
Can anyone build the docs without having that problem? I just need to
know whether it's an issue with my setup.
Thanks,
-- T.J.
On Apr 3, 10:41 pm, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Andrew,
Thanks. With the latest, on Windows if I also comment out the atime
line, building the docs goes through to completion. However, the
generated doc seems to have issues: For instance, if I go into
index.html, then choose Language Section from the menu, if I click
on $A on the Utilities line on the page, I get a 404 for language
\dollara.html.
Haven't had a chance to try Ubuntu yet.
-- T.J.
On Apr 3, 6:56 pm, Andrew Dupont goo...@andrewdupont.net wrote:
OK, once I commented out that File.utime line, things went
smoothly.
There was an error in the rendering stage that I had to correct
(something that was showing up with BlueCloth but not with RDiscount)
— so do a git pull once again. Then the docs will build.
The line that needs commenting out is a bug in Sprockets that I've
passed along to Sam, so expect a fix for that sometime soon.
T.J., let me know if you have any further problems.
Cheers,
Andrew
On Apr 3, 11:22 am, Andrew Dupont goo...@andrewdupont.net wrote:
*headdesk*
Had local changes to my PDoc checkout that I had not pushed back to
the repo. Fixed now.
git pull git submodule update
...should do the trick.
Cheers,
Andrew
On Apr 3, 9:28 am, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Richard,
I'm really stumped here. I wonder if the lack of a ...
I'd leave it until Andrew's had a chance to take a look.
-- T.J. :-)
On Apr 3, 3:21 pm, Richard Quadling rquadl...@googlemail.com
wrote:
2009/4/3 T.J. Crowder t...@crowdersoftware.com:
[snip]
I think I've found the problem.
File.utime(timestamp, timestamp, filename)
is trying to amend the time on the open file.
I commented this line and it worked.
Yup, that lets me get past that point as well. Andrew said
he'd be
working on this in his Windows VM soon, so hopefully that
gives him a
leg up.
rake aborted!
undefined method `signature' for
#Documentation::InstanceProperty
Ajax.Response#headerJSON
Yup, here too. Probably a different problem.
-- T.J.
I'm really stumped here. I wonder if the lack of a ...
headerJSON: function() {
...
is causing it. I tried temporarily adding one to response.js,
but it
didn't make a diff.
--
-
Richard Quadling
Zend Certified Engineer
:http://zend.com/zce.php?c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
Please hold, your call will be answered shortly.
--
-
Richard Quadling
Zend Certified Engineer :http://zend.com/zce.php?c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
[07/04/2009 10:26:41] [D:\Personal
Files\Downloads\Software\Programming\Javascript\Prototype\master] []
rake doc
(in D:/Personal
Files/Downloads/Software/Programming/Javascript/Prototype/master)
rm -rf D:/Personal
Files/Downloads/Software/Programming/Javascript/Prototype/master/doc
Parsing source files: C:/DOCUME~1/RichardQ/LOCALS~1/Temp/pdoc.2796.0.
Parsing completed in 51.437 seconds.
Generating documentation to: D:/Personal
Files/Downloads/Software/Programming/Javascript/Prototype/master/doc.
Documentation generated in 566.789 seconds.
Summary:
Sections: 3
Utilities: 7
Namespaces: 34
Mixins: 1
Classes: 23
Constructor methods: 11
Constants: 0
Class
[Prototype-core] Re: Permission denied error from 'rake doc'
T.J., are you sure you're running the latest code? Do a git submodule update from the root Prototype directory. Those sound like issues I had run into, and fixed, several weeks ago. Meanwhile, I'll fire up my Windows VM and see what happens when I try to generate docs from there. Cheers, Andrew On Apr 2, 6:17 am, T.J. Crowder t...@crowdersoftware.com wrote: Hi again, Thought I'd give this a try on the Ubuntu lab machine I'd just built, in hopes that the permissions problem is Windows-specific. I got further, it can read the temp file, but then it runs into a problem in the PDoc Runner where it can't find the file ajax/ajax: * * * * t...@lab06:~/projects/prototype$ rake doc (in /home/tjc/projects/prototype) Parsing source files: /tmp/pdoc20090402-6276-fmbqy1-0. Parsing completed in 81.040395 seconds. Generating documentation to: /home/tjc/projects/prototype/doc. Rendering: ajax_section.html rake aborted! No such file or directory - ajax/ajax /home/tjc/projects/prototype/Rakefile:74 (See full trace by running task with --trace) * * * * (Rakefile:74 is the PDoc Runner call.) I'm guessing it's meant to be in the doc subdirectory, but looking there, there is no subdirectory called ajax. There is, however, one called Ajax (with a capital A): * * * * t...@lab06:~/projects/prototype$ ls -lA doc total 44 drwxr-xr-x 2 tjc tjc 4096 2009-04-02 12:01 Ajax -rw-r--r-- 1 tjc tjc 21681 2009-04-02 12:01 ajax_section.html -rw-r--r-- 1 tjc tjc 12309 2009-04-02 12:01 index.html * * * * Some kind of case sensitivity problem? I wonder if this has only been used successfully on Windows (if even there?), Mac OS X, and the like that don't (by default) have case-sensitive file systems... -- T.J. On Apr 2, 10:08 am, T.J. Crowder t...@crowdersoftware.com wrote: Folks, Can anyone build the docs other than Tobie and Andrew? If so, do you have any idea what's going on? I really want to close the large number of doc tickets on my plate, but there's no point in doing the work if the patches are just going to sit there unused (like this one [1]), that's just a waste of time, and none of us have time to waste. I'm about to hit a phase of a project where I won't have time to do this, so I was trying to clean them up before that. [1]https://prototype.lighthouseapp.com/projects/8886-prototype/tickets/610 Thanks in advance, -- T.J. On Mar 31, 4:00 pm, T.J. Crowder t...@crowdersoftware.com wrote: Hi Andrew, Thanks for the help. Yeah, it is weird, isn't it? :-) And yet we have permission to delete it (apparently, as it does get deleted). Are you logged in as an administrator? I am indeed, and that file is being created in the temp directory associated with my account, which in theory I'd be able to read/write to regardless. Early on, as a test, I created a different directory with a short path with no spaces and that I have full control permissions to and pointed TEMP/TMP at it instead. The directory got used, but I got the same result. -- T.J. :-) On Mar 31, 6:23 am, Andrew Dupont goo...@andrewdupont.net wrote: Christ, that's weird. It's saying you don't have permission to read the temporary file we create to build a concatenated version of Prototype with documentation comments included. The whole point of the temporary-file approach is to avoid permissions issues. Are you logged in as an administrator? Cheers, Andrew On Mar 30, 5:51 am, T.J. Crowder t...@crowdersoftware.com wrote: Hi all, I have a bunch of doc tickets I'd like to resolve (not to mention this ticket[1] discussed here[2] that I've posted a patch for, but seems to be waiting for someone to check that the doc stuff doesn't get broken by blank lines), but 'rake doc' doesn't work on my system. 'rake dist' and 'rake test' both do. [1]http://prototype.lighthouseapp.com/projects/8886-prototype/tickets/610 [2]http://groups.google.com/group/prototype-core/browse_thread/thread/c5... I've installed Ruby, git, rake, etc., cloned the repo, built the submodules, etc., and again dist and test work. But I haven't manually installed anything specific for PDoc -- it'd be a great answer if it were just that I was missing out something. I'd like to get the doc stuff working so I can test my doc changes locally before posting patches. I know nothing about Ruby or rake. Anyone have any idea what's going on here and how to resolve this? * * * * C:\Projects\prototyperake doc --trace (in C:/Projects/prototype) ** Invoke doc (first_time) ** Invoke doc:build (first_time) ** Invoke doc:require (first_time) ** Execute doc:require ** Execute doc:build rake aborted! Permission denied - C:/DOCUME~1/tjc/LOCALS~1/Temp/pdoc.3196.0 C:/Projects/prototype/vendor/sprockets/lib/sprockets
[Prototype-core] Re: Permission denied error from 'rake doc'
*headdesk*
Had local changes to my PDoc checkout that I had not pushed back to
the repo. Fixed now.
git pull git submodule update
...should do the trick.
Cheers,
Andrew
On Apr 3, 9:28 am, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Richard,
I'm really stumped here. I wonder if the lack of a ...
I'd leave it until Andrew's had a chance to take a look.
-- T.J. :-)
On Apr 3, 3:21 pm, Richard Quadling rquadl...@googlemail.com wrote:
2009/4/3 T.J. Crowder t...@crowdersoftware.com:
[snip]
I think I've found the problem.
File.utime(timestamp, timestamp, filename)
is trying to amend the time on the open file.
I commented this line and it worked.
Yup, that lets me get past that point as well. Andrew said he'd be
working on this in his Windows VM soon, so hopefully that gives him a
leg up.
rake aborted!
undefined method `signature' for #Documentation::InstanceProperty
Ajax.Response#headerJSON
Yup, here too. Probably a different problem.
-- T.J.
I'm really stumped here. I wonder if the lack of a ...
headerJSON: function() {
...
is causing it. I tried temporarily adding one to response.js, but it
didn't make a diff.
--
-
Richard Quadling
Zend Certified Engineer :http://zend.com/zce.php?c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Prototype-core] Re: Permission denied error from 'rake doc'
OK, once I commented out that File.utime line, things went smoothly.
There was an error in the rendering stage that I had to correct
(something that was showing up with BlueCloth but not with RDiscount)
— so do a git pull once again. Then the docs will build.
The line that needs commenting out is a bug in Sprockets that I've
passed along to Sam, so expect a fix for that sometime soon.
T.J., let me know if you have any further problems.
Cheers,
Andrew
On Apr 3, 11:22 am, Andrew Dupont goo...@andrewdupont.net wrote:
*headdesk*
Had local changes to my PDoc checkout that I had not pushed back to
the repo. Fixed now.
git pull git submodule update
...should do the trick.
Cheers,
Andrew
On Apr 3, 9:28 am, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Richard,
I'm really stumped here. I wonder if the lack of a ...
I'd leave it until Andrew's had a chance to take a look.
-- T.J. :-)
On Apr 3, 3:21 pm, Richard Quadling rquadl...@googlemail.com wrote:
2009/4/3 T.J. Crowder t...@crowdersoftware.com:
[snip]
I think I've found the problem.
File.utime(timestamp, timestamp, filename)
is trying to amend the time on the open file.
I commented this line and it worked.
Yup, that lets me get past that point as well. Andrew said he'd be
working on this in his Windows VM soon, so hopefully that gives him a
leg up.
rake aborted!
undefined method `signature' for #Documentation::InstanceProperty
Ajax.Response#headerJSON
Yup, here too. Probably a different problem.
-- T.J.
I'm really stumped here. I wonder if the lack of a ...
headerJSON: function() {
...
is causing it. I tried temporarily adding one to response.js, but it
didn't make a diff.
--
-
Richard Quadling
Zend Certified Engineer :http://zend.com/zce.php?c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Prototype-core] New Element.Layout API
I've just committed a couple large API additions in a layout branch
in our Git repository:
http://github.com/sstephenson/prototype/tree/layout
http://github.com/sstephenson/prototype/blob/9d28f04d98307f652a2d85ff35e869f2e0ac7f38/src/dom/layout.js
It's still very preliminary, but Element.Layout is meant to like a
lazy-loading, memoized subclass of Hash. It gives measurements and
offsets of practically any aspect an element's layout box. It's lazy-
loading because some of these computations are costly and shouldn't be
done unless strictly necessary.
In other words, I can do something like this...
var foo = $('foo');
var layout = foo.getLayout();
var width = layout.get('width'); // 144 (or some other number)
var marginBoxWidth = layout.get('margin-box-width'); // 164 (content +
padding + border + margin)
Behind the scenes, it determined the width (i.e., the content box
width) by taking the offsetWidth property from the element (which is
the width of the element's border box) and subtracting the computed
padding and border widths on both sides. When it did this, it cached
the values for many other measurements, like border-box-width,
padding-left, padding-right, and so on. If any of these values are
requested directly, no further computation is necessary.
Furthermore, when we ask for the margin-box-width (i.e., the space
the element truly commands), it knows it needs to fetch margin-left
and margin-right, but the values of all other properties are already
cached.
(A caveat: because of the caching, an Element.Layout object should be
treated like a snapshot of an element's dimensions. When the
dimensions of an object change, you ought to grab a new instance of
Element.Layout.)
Take a look at the code and tell me what you think. The API is far
from complete, naturally, but it'd be great to know if people think
this is the right idea.
Cheers,
Andrew
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Prototype-core] Re: Prototype in 10 steps... what are they?
On Nov 18, 4:11 am, T.J. Crowder [EMAIL PROTECTED] wrote: That list falls neatly into two categories: Basic techniques not requiring *too* much in terms of conceptual understanding (the first five items), then more conceptual (and powerful) stuff (the last five items). I probably would have put Enumerable lower down except that it goes well with the basic techniques group. Yeah, that's the hard part. I think $$ and Enumerable go together because so many novice use cases for Enumerable will involve filtering DOM result sets. So I'd be inclined to move $$ to #5. Nit-picking, Treat functions like first-class objects sounds as though they aren't, but we're treating them like they are. I'd say the focus should be on the student learning that in JavaScript, functions *are* first-class objects. It's one of the most powerful concepts in the language. The phrasing assumes that the user probably hasn't come from a language where functions _are_ first-class objects; that's all that was intended. Thanks for your feedback, everyone. Cheers, Andrew --~--~-~--~~~---~--~~ 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] Prototype in 10 steps... what are they?
I'm thinking about how we can flatten the learning curve. If you were to teach someone how to use Prototype in 10 incremental steps, what would they be? I've got only nine so far, but here they are: 1. Master the $ Function 2. Use instance methods to perform common tasks on elements 3. Master event observing 4. Push the envelope with Ajax 5. Use Enumerable to manage collections 6. Use Prototype's helper methods on built-in objects 7. Treat functions like first-class objects 8. Have your mind blown by custom events 9. Write class-based JavaScript Can you add a tenth to this list? Or do you have a completely different list? Let's hear it. Cheers, Andrew --~--~-~--~~~---~--~~ 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: Style Guide for rewrite branch
On Nov 16, 1:58 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Here is my take, I'm also altogether with this incoming pattern. PDoc blocks could indeed demarcate those sections, and be used to provide (browser|feature)-specific technical documentation. My proposal is the following (http://gist.github.com/25421) I like it. One nitpick: only one implementation of a particular method needs to be PDoc'd, since we're documenting the public API and don't need to inform the user about the internal differences between implementations. We'd still have comments explaining what those differences are, but they wouldn't be PDoc comments. Cheers, Andrew --~--~-~--~~~---~--~~ 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: Style Guide for rewrite branch
Here's what this would look like when genericized into an imaginary API: http://gist.github.com/24571 A couple of things: (1) I'm altogether in favor of this new approach, but it will result in less implicit organization of code. A reader of the code will likely find it harder to scan for the specific method they're looking for. We'll probably have to address this by marking code sections with comments. (2) Also, it now becomes less clear where a PDoc block would go. Technically, it would go at the bottom, where the external API is created, but that'd separate it from the logic of the function and would therefore make it more likely for the code and the docs to get out of sync. (Perhaps PDoc blocks can be used to demarcate, thereby solving both of these problems.) (3) Simple capability/quirk checks, as in the String#escapeHTML example, can go directly into the conditional. More complex checks, like the kind kangax has been working on, will need to be wrapped in anonymous functions and distilled into booleans. I'd prefer these booleans to have the naming conventions of constants (e.g., TREATS_ATTRIBUTES_AS_EXPANDO_PROPERTIES) so that they can be recognized easily in the code. Cheers, Andrew On Nov 13, 6:28 am, T.J. Crowder [EMAIL PROTECTED] wrote: Hi Tobie, I'm actually interested in the pattern, not in the actual code. Yeah, just wanted to make sure we were looking at the right code first. I investigated a bit more re the typos you mentioned. It happens to be an issue with gist which... escaped some of the strings. Lovely. So stating the obvious: The basics are: 1. Use named functions for each variant. 2. Define the functions up front. 3. Test proactive, in an appropriate order, and use the first one that works correctly. Right? -- T.J. --~--~-~--~~~---~--~~ 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: Contributing to the Prototype Documentation
Write up your proposed additions in a text file, create a ticket on Lighthouse, and attach your additions as a patch. Thanks! Cheers, Andrew On Oct 13, 1:08 pm, ijayasin [EMAIL PROTECTED] wrote: Hi, I was wondering how people could contribute to the Prototype documentation. One part of the documentation that has room for improvement is Element.insert. In fact, if I were to contribute to the documentation, this is the first place I'd start. :) Thanks, Indika --- --~--~-~--~~~---~--~~ 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.js (1.6.0.3) breaks Firebug (1.2.1) Options allegedly.
Only in the sense that Prototype seems not to be safe to use inside a Firefox extension. But even that isn't clear. I posted in the thread to try to cut through the hearsay and speculation. Thanks, Richard. Cheers, Andrew On Oct 14, 8:49 am, Richard Quadling [EMAIL PROTECTED] wrote: Hi. There's been this recent thread in the FireBug Google Group -http://groups.google.com/group/firebug/browse_thread/thread/095caa522... Is there any real issue here? -- - Richard Quadling Zend Certified Engineer :http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! --~--~-~--~~~---~--~~ 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: Bug : Object.isNumber() and Hash.toQueryString()
I shall end the shitstorm here and now.
To quote the rhino book:
Once we've created a string object S [through `new String`], what can
we do with it? Nothing that we cannot do with the corresponding
primitive string value. If we use the `typeof` operator, it tells us
that S is indeed an object, and not a string value, but except for
that case, we'll find that we can't normally distinguish between a
primitive string and the String object.
The same applies to Number and Boolean.
In other words, the purpose of the wrapper objects around primitives
is to drive framework authors insane, since they evade introspection:
they walk, talk, eat, and swim like ducks; ask them what they are,
though, and they'll claim to be ostriches.
The reason you've seen such skepticism from kangax in this thread is
because he probably can't think of a single case in which it's
_useful_ to use the wrapper objects instead of the primitives they
wrap. Nor can I. But, hell, if people want it, it's easy enough:
Object.isString = function(object) {
return object.valueOf typeof object.valueOf() === string;
};
Object.isNumber = function(object) {
return object.valueOf typeof object.valueOf() === number;
};
The `valueOf` method will return the primitive behind the wrapper
object. And this will avoid the cross-frame issues we had with
Object.isArray.
We'll put this into the queue for either 1.6.0.4 or 1.6.1, even though
it makes my head hurt.
Cheers,
Andrew
--~--~-~--~~~---~--~~
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: Bug : Object.isNumber() and Hash.toQueryString()
No, you were completely right — either it should support both the primitive and the wrapper _or_ we need to document why it does not. I was prepared to say we'd do the latter, since I didn't want to deal with the differences between the two, but it turns out there _are_ no differences, save for the `typeof` problem. If the fix weren't so simple I'd have pushed back hard. Cheers, Andrew On Oct 8, 2:15 pm, Tom Gregory [EMAIL PROTECTED] wrote: On Oct 8, 2008, at 11:29 AM, Andrew Dupont wrote: I shall end the shitstorm here and now. ... he probably can't think of a single case in which it's _useful_ to use the wrapper objects instead of the primitives they wrap. Honestly, I can't either. I don't see any reason to use the object wrappers in the first place, and would thus never encounter the issue. (I would go a step further, and suggest use of the object wrappers to be less-good design because of the extra code required to use 'em.) At a higher level, the question I wanted to raise is the balance between principles of good design (e.g. POLS) and requiring a use case to be common enough before any changes are made--because there should be a balance; one view is not always correct. That wasn't the discussion I was hearing; that's why I joined the conversation. I'll try and shut up now. =) TAG = “Always be the worst guy in every band you’re in. If you’re the best guy there, you need to be in a different band. And I think that works for almost everything that’s out there as well.” ~Pat Metheny (h/t Pragmatic Thinking Learning: Refactor your wetware) --~--~-~--~~~---~--~~ 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: Official (or unofficial) compressed version of Prototype 1.6?
Google's version is gzipped. Prototype 1.6, when gzipped, is only 28K over the wire. And with Google's content distribution network and proper cache settings, it'll be downloaded only once. This is what people should be using if they want a compressed version. (http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.3/prototype.js) If they want a self-hosted compressed version, and can't use gzip, then they should use JDD's protopacked distribution. Cheers, Andrew On Oct 3, 7:23 am, Tom Gregory [EMAIL PROTECTED] wrote: Isn't that what I said? The advantage from Google is not compression, but caching (if multiple sites use it). There was talk at one point of releasing an official compressed version so Google could use it. I don't remember the outcome of that conversation. TAG On Oct 3, 2008, at 5:04 AM, Yanick wrote: Hi Tom, The Prototype version hosted by Google seems not to be compressed. I haven't look deep, but if it loads this URL http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js, then it is not compressed. yanick On Oct 3, 12:22 am, Tom Gregory [EMAIL PROTECTED] wrote: There is also the Google-hosted version. It's not compressed, but if your users visit other sites that also access the URL, it'll be cached.http://code.google.com/apis/ajaxlibs/ --~--~-~--~~~---~--~~ 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: 1.6.0.3 status: Where we're at
On Sep 22, 7:16 pm, Valentin [EMAIL PROTECTED] wrote: I didn't hijacked anyone's thread. This is about the upcoming 1.6.0.3 so what I posted is directly related. The purpose of a JS library is to 1) provide compatibility among browsers using the same code 2) reduce the time the programmer has to spent to do certain tasks. Also in today's day IE7 has BY FAR the highest market share, and also the object tag is the XHTML requirement to presenting Java applications, flash objects, and the like which, now, more than ever, appear on Web 2.0 pages. If Prototype can't hadle these two things than it is missing it's point, and it's users. I'm not talking here about a pet problem, but about some fundamental facts. Your most basic function doesn't work on the most used browser with one of the most common tags in XHTML (that are called in JS events). Therefore you are building a house on a crappy foundation, and it will fall. You want to make this about me submitting or not submitting a bug? Really I already told you what is wrong, how to recreate it, so any developer of the ones that have read this topic could have taken the time to fix it instead of replying back 3 pages long of messages on how I should have done this. Stop for a second. Read back over this thread. You reported the problem; someone asked for a test case. You posted the test case (thanks for that; a lot of people don't bother). kangax noted that the problem is not in extending the OBJECT tag, it's in calling the update method, because I'm guessing OBJECT nodes don't have an innerHTML property in the IE DOM. You keep expressing disbelief at how nobody else has encountered this before. That should tell you one of two things: either your scenario isn't as commonplace as you think it is; or others have encountered this problem and found it too big to solve in JavaScript. Internet Explorer doesn't handle OBJECT tags right [1]; it thinks they're all ActiveX controls because that's all the element was for when Microsoft introduced it. There's no way around this. (This is the reason why, for instance, people use SWFObject [2] to insert Flash content without using invalid markup.) Prototype aside... if you think you're going to get the OBJECT tag to work the XHTML way in IE7, you're sorely mistaken. Prototype isn't our product; it's our side project. We ask that bug reports and test cases be filed through the proper channels because it ensures they won't get missed. The less time we spend copying and pasting from Google Groups into our bug tracker... the more time we spend writing code. If that makes us seem anal to you, then I'm OK with that. Cheers, Andrew [1] http://lists.w3.org/Archives/Public/w3c-wai-ig/2002AprJun/0865.html [2] http://code.google.com/p/swfobject/ --~--~-~--~~~---~--~~ 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: Firefox 2.0.0.x Event.element()
I believe we've fixed this since 1.6.0. Update to 1.6.0.2 and see if
it still happens.
Cheers,
Andrew
On Sep 2, 8:47 am, therutz [EMAIL PROTECTED] wrote:
Using prototype.js 1.6.0 and Firefox 2.0.0.x and Event.element()
returns the wrong element. Instead of an HTMLImageElement it's
returning the document. Looks like a general bug with these versions
of Firefox, both PC and Mac.
I found that same problem and a fix in a site about Rails.
From line: 3775
element: function(event) {
//var node = Event.extend(event).target;
//return Element.extend(node.nodeType == Node.TEXT_NODE ?
node.parentNode : node);
event = Event.extend(event);
var ct, node = event.target, t = event.type;
/* get correct target for Firefox */
if(ct = event.currentTarget){
var tagName = ct.tagName.toUpperCase();
if((tagName == 'IMG' /^(load|error)$/.test(t)) ||
(tagName == 'INPUT' ct.type == 'radio' t == 'click'))
node = ct;
}
return Element.extend(node node.nodeType == Node.TEXT_NODE ?
node.parentNode : node);
},
Don't know if this has been covered elsewhere, but I think it should.
--~--~-~--~~~---~--~~
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: lighthouse marked my ticket as spam
I think this was during the one day that Lighthouse's spam verification service went down and it was marking everything as spam. Would you mind re-submitting the ticket? I can't seem to find a way to un-mark it. Thanks, Andrew On Sep 1, 9:34 am, Ihárosi Wiktor [EMAIL PROTECTED] wrote: Hi, I reported a bug in May to the new lighthouse but it has been marked as spam. I didn't have too much time in summer, but I have check it again and it is still in spam status and I can't do anything with it. :( I changed my password, I logged in but I can't edit it. If I try to edit the ticket I got Invalid ticket comment. message. What should I do in this case? http://prototype.lighthouseapp.com/projects/8886-prototype/tickets/92... Thanks in advance! Wiktor --~--~-~--~~~---~--~~ 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 onmouseleave
[1] http://msdn.microsoft.com/en-us/library/ms536956(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/ms536910(VS.85).aspx (Just pretend I included these in the original message.) On Jun 12, 8:20 pm, Andrew Dupont [EMAIL PROTECTED] wrote: On Jun 12, 5:46 am, Nick Stakenburg [EMAIL PROTECTED] wrote: I've been saying this for some time but custom events seem to be used as an excuse not to implement this properly, like other frameworks have done. Of course it can be done with custom events but it's clearly not the best approach. Ah well, I guess this needs more time before others draw the same conclusion. Nick, I have no opinion on whether or not mouseenter/mouseleave should be rolled into core, but if they are I think they should be implemented as custom events, just like we implemented dom:loaded. I'm highly reluctant to give the former a special treatment that we didn't give the latter. As we discussed on GitHub, the solution is to enhance Element#fire so that one can tell a custom event not to bubble. In most browsers this is easy. In IE, as you noted, the fireEvent method gives no control over bubbling behavior. But IE also implements a bunch of proprietary events that nobody ever uses, and some of these are *by their nature* non-bubbling. For instance, there's onpropertychange, which is IE-only and not part of any standard [1]. Just like we borrow ondataavailable for custom events, so can we borrow onpropertychange to get non-bubbling custom events. Some quick code confirms this works. I've set this as a to-do for 1.6.1. Fun fact: originally I'd wanted to use the onbounce event [2], which is one of three different events that IE reserves for MARQUEE elements. It does not bubble, but is cancelable, so it would've been _perfect_. Sadly, IE throws an error when you try to trigger an onbounce event on a non-MARQUEE element. I promise I'm not making this up. Cheers, Andrew --~--~-~--~~~---~--~~ 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: Using GIT
http://github.com/sstephenson/prototype/ http://github.com/madrobby/scriptaculous/ Those are the GitHub pages for Proto/Scripty, respectively. Those pages have the repo URLs for each — or you can download tarballs from there if you're not keen on git. Everything else works the same way. Cheers, Andrew On Apr 25, 5:52 am, Richard Quadling [EMAIL PROTECTED] wrote: Hi. Where do I point my git to get RubySpinoffs now? Or is git now only for prototype? I assume once I've got the spin offs, I am still using rake dist to build my version for testing? -- - Richard Quadling Zend Certified Engineer :http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! --~--~-~--~~~---~--~~ 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: $_SESSION of PHP doesn't work with AJAX
On Mar 27, 9:29 pm, Nouv Vitou [EMAIL PROTECTED] wrote: But if I have two different domains taiyocambodia.com and khmer-web.com. I would like to use the session to be used for both. How can I? Can't do it with cookies. Track your sessions on the server-side. Again let me suggest that this isn't the right list for you. This is for discussion of the development of Prototype and is not for support questions of any kind. I'd try a PHP mailing list (http://www.php.net/ mailing-lists.php). Good luck, Andrew --~--~-~--~~~---~--~~ 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: methodize parseInt parseFloat
On Jan 29, 3:41 am, artemy tregoubenko [EMAIL PROTECTED]
wrote:
Well, I'm using this one:
Object.extend(String.prototype, {
parseInt: parseInt.methodize(),
parseFloat: parseFloat.methodize(),
});
Clever. :-)
In ECMAScript 4, parseInt and parseFloat are becoming static methods
on Number, not on String (i.e., Number.parseInt(3)). I could more
easily see adding String#toNumber, but it's not a must-have for me.
What do others think?
Cheers,
Andrew
--~--~-~--~~~---~--~~
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: New Element()
I think he meant it as a workaround, not as a bug fix.
Thanks, David!
Cheers,
Andrew
On Jan 10, 11:06 am, Mislav Marohnić [EMAIL PROTECTED]
wrote:
In other words, you eliminated the cache?
We would rather fix the problem than lose the cache (and the speed increase
it provides). You could first try and checkout the library from Subversion
(described on prototypejs.org/contribute), create the build and open
test/unit/dom.html in Mozilla. If there really are failing tests, open a new
ticket in Trac and describe the issue there.
I don't have the chance to test it today, but here are the Mozilla builds
for those who might wish to test Prototype
with:http://www.mozilla.org/releases/
Thank you for the bug report.
- Mislav
On Jan 10, 2008 4:18 PM, David [EMAIL PROTECTED] wrote:
Hello
New Element('div', {'class': 'test'});
throw an error with Mozilla 1.7.12 :
Error : cache has no properties
Source File : prototype.js
Line : 1565
I did something like this to make it work :
(function() {
var element = this.Element;
this.Element = function(tagName, attributes) {
attributes = attributes || { };
tagName = tagName.toLowerCase();
var el=document.createElement(tagName);
Object.keys(attributes).each(function (item) {
el.writeAttribute(item, attributes[item]);
});
return el;
};
Object.extend(this.Element, element || { });
}).call(window);
--~--~-~--~~~---~--~~
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: Fwd: [prototype-core] Event#unloadCache not available in 1.6.0
I think our official recommendation is that anyone who needs Event.unloadCache should write it and make its contents the same as that of destroyCache. The code duplication is small enough that it doesn't bother me; anyone who's doing proactive GC probably has written enough JS already that they won't mind an extra five lines. I think we could've handled the 1.6 deprecations a bit better. Sorry if they caught anyone by surprise. Cheers, Andrew On Dec 12, 12:50 pm, Ken Snyder [EMAIL PROTECTED] wrote: (BUMP) Original Message Subject:[prototype-core] Event#unloadCache not available in 1.6.0 Date: Mon, 03 Dec 2007 15:07:03 -0700 From: Ken Snyder [EMAIL PROTECTED] To: prototype-core@googlegroups.com http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thr... Based on the above discussion on the rails-spinoffs list, I'm wondering if the prototype authors would consider making the destroyCache() functionality available as a public method like Event#unloadCache() was before 1.6.0. Some consider this a compatibility issue and even a bug that should be fixed in 1.6.1. What are your thoughts? Thank you, Ken Snyder --~--~-~--~~~---~--~~ 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: Version 1.6 and XPath in Safari/WebKit 3
The Selector class translates to XPath in browsers that support it. Some of the Selector unit tests failed in Safari 3 -- seemingly because WebKit doesn't correctly implement some XPath functions. If I recall, the failures are related to the :first-of-type/:first-child pseudoclasses (and their brethren). Considering the JS engine performance gains that were made in Safari 3, I decided to disable the XPath translation in that browser for 1.6. (The slow lane in Safari 3 is still pretty damned fast.) One of my tasks for the 1.6.0.1 release is to re-enable the XPath approach for Safari 3, circumventing it only when necessary. I've glossed over some implementation details of the Selector class, so let me know if this doesn't make sense. Cheers, Andrew On Nov 27, 8:30 am, Mazdak Rezvani [EMAIL PROTECTED] wrote: Hi All The SVN commit messages for Prototype 1.6 says that XPath is disabled in Safari 3 (Webkit 3) because of some problem. I wonder if you can be more specific about what's broken with the WebKit 3 XPath? Also, has anyone checked to see if the release version still has this problem? Thank you --~--~-~--~~~---~--~~ 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: features request
On Nov 22, 10:29 am, Mislav Marohnić [EMAIL PROTECTED] wrote: Because of the silence of other core members at the moment, Keep in mind the western faction has been asleep, and it is a holiday in America. ;-) it would be best for you to make a plug-in script that is included after Prototype library. Then you can share it on this ML with specific proposals what you think should be core functionality. Think it through, though; we are very picky about what gets included in the library. This is a good way to proceed. Prototype 2.0 will place greater focus on HTTP transports other than Ajax (embedded IFRAMEs, SCRIPT tags, etc.). Until then it works best as a plugin. Cheers, Andrew --~--~-~--~~~---~--~~ 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: $super and Function.toString()
There are other popular scripts that rely on this behavior, most notably Dean Edwards's original base.js inheritance script. It should also be noted that this behavior does not comply with ECMA-262, which states that Function.prototype.toString shall return a string that has the syntax of a function declaration. I'm sure it was necessary to get a JS environment running on mobile devices, but the point remains. Prototype supports the major desktop browsers, but I don't think we have any _official_ level of support for browsers on mobile devices. Cheers, Andrew On Nov 11, 3:57 pm, Mislav Marohnić [EMAIL PROTECTED] wrote: On Nov 11, 2007 10:16 PM, Artemy Tregoubenko [EMAIL PROTECTED] wrote: some time ago one of Opera developers warned in his blog ( http://my.opera.com/hallvors/blog/2007/03/28/a-problem-with-john-resi... ) against relying on function serialization. He said that mobile devices are limited in resources and thus may lack this functionality. Hi Artemy, Yeah, the $super argument is a hack. Class instances will misbehave if the JavaScript interpreter is unable to serialize functions. But this issue aside, can we expect the rest of the framework to work if the JS interpreter is limited? --~--~-~--~~~---~--~~ 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: Scripaculous 1.8 compressed?
Prototype script.aculo.us don't release official compressed versions, but there are a few different people who make unofficial compressed versions for each major release. I'm sure one will be available shortly after the 1.6 final release (which will be soon). Cheers, Andrew On Nov 1, 8:25 pm, EGBlue [EMAIL PROTECTED] wrote: Is there an intention to release a compressed version of 1.6 RC1 and 1.8? Thanks in advanced. --~--~-~--~~~---~--~~ 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: combinator selectors in Element#select
I'm not crazy about it. Deviations from the CSS3 spec are troublesome
because they're not discoverable and they violate POLS. If we're going
to go down that slippery slope, selector.js will get even larger than
it already has.
The extended Enumerable#grep semantics in 1.6 make kangax's
alternative code shorter:
var matches = element.childElements().grep(new Selector('.foo'));
Anything that has a match method can now be used as a filter.
Cheers,
Andrew
On Oct 17, 10:17 am, Mislav Marohnić [EMAIL PROTECTED]
wrote:
On 10/17/07, kangax [EMAIL PROTECTED] wrote:
In a nutshell, element.select(' foo') does not return the correct
result
+1 for fixing it, regardless of the fact it may not be a valid selector ...
it's a valid fragment of a selector.
I want to be able to select immediate descendants this way. Do others feel
the same?
--~--~-~--~~~---~--~~
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: Getting patches reviewed and applied
Historically the JS libraries haven't seen enough patch volume to justify the process overhead. I feel like we're turning the corner there, though; we should probably start following the Report 12 process for Prototype. What does the rest of Core think? Any message that proposes a new feature is most welcome on this list, so feel free to post here first if you want to gauge how well a patch would be received. I'm qualified to answer only the Prototype half of your question. I'll let Thomas speak to the Scriptaculous half. Cheers, Andrew On Oct 13, 7:39 pm, Ryan McGeary [EMAIL PROTECTED] wrote: I've got one prototype patch and one scriptaculous patch awaiting review from the core team. I went through the process of getting them both reviewed and verified under the new Rails process, but I didn't realize the javascript spinoff teams didn't track Report 12. It took a comment from Koz for me to realize this. What's the best way to receive feedback from the core team? Does it make sense for prototype and scriptaculous to follow the same Report 12 process that Rails is using? Add optional 'distance' and 'duration' options to Effect.Shakehttp://dev.rubyonrails.org/ticket/8637 Add optional context argument to Number#timeshttp://dev.rubyonrails.org/ticket/9252 Thanks, Ryan --~--~-~--~~~---~--~~ 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: :not() selector bugs
The CSS2 and CSS3 specs disagree on this, annoyingly enough. [1] I'd originally written :not to throw an exception on selectors with more than one token, but then I saw the conflicting definitions and relented. All the other major libraries seem to allow this confusing syntax. Not being able to use the descendant combinator after a :not clause, however, is a bug. Wiktor, feel free to report it; I'll try to fix it before 1.6 final. Cheers, Andrew [1] http://www.w3.org/TR/REC-CSS2/selector.html#q2 On Sep 26, 10:51 am, kangax [EMAIL PROTECTED] wrote: Interesting, From w3c specs (http://www.w3.org/TR/2001/CR-css3-selectors-2003/ #negation): The negation pseudo-class is a functional notation taking a simple selector (excluding the negation pseudo-class itself and pseudo- elements) as an argument. Now what is simple selector (http://www.w3.org/TR/2001/CR-css3- selectors-2003/#simple-selectors-dfn) ? A simple selector is either a type selector, universal selector, attribute selector, ID selector, content selector, or pseudo-class. One pseudo-element may be appended to the last sequence of simple selectors. Looks like your 'a:not(a[rel$=nofollow]' is not quite a simple selector (but rather a combination of type and attribute ones) Besides, a:not(a[rel^=external]) doesn't make sense in the first place (just like div:not(div) which will never match) : ) Why select a that are not a with some condition when you could just specify condition on its own. It will be tested against all a anyway: a:not([rel^=external]) Hope this helps, kangax --~--~-~--~~~---~--~~ 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: Opera contentLoaded gotcha with external stylesheets.
That very blog post points to HTML5 work on the issue. If you're brave, Mislav, you could ask for a spec clarification on the HTML5 mailing list. Cheers, Andrew On Sep 5, 10:20 am, Mislav Marohnić [EMAIL PROTECTED] wrote: On 9/5/07, jdalton [EMAIL PROTECTED] wrote: I just saw a post on this Opera bug. I don't suggest a fix or anything just wanted to let you know: http://my.opera.com/nicomen/blog/2007/07/08/domcontentloaded-gotcha-w... DOMContentLoaded should be standardized. Is there some effort by W3C or WHATWG anyone knows about? --~--~-~--~~~---~--~~ 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: simulated DOMContentReady event
On Sep 1, 5:18 pm, Nicolás Sanguinetti [EMAIL PROTECTED] wrote: Anyway, the custom event solution seems tidy enough. What do the w3c specs say on xmlhttprequests and contentloaded, if anything? They don't. Despite its name, the DOMContentLoaded event is not part of any standard. --~--~-~--~~~---~--~~ 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: simulated DOMContentReady event
On Aug 31, 2:12 am, Mislav Marohnić [EMAIL PROTECTED] wrote: On 8/31/07, Jeff Watkins [EMAIL PROTECTED] wrote: Let me see if I'm getting this correctly. You are saying that you need to inject content in the DOM received by XHR ... while the current page is still being loaded? That is strange to me. No. He's talking about what you hint at in your second paragraph. Imagine you've got a page with some inline code that assigns stuff to DOMContentLoaded. Now imagine it's a fragment, not a full page, and you're loading it via Ajax. Jeff, my suggestion is to write your own Event.onReady function (or something like it) that wraps around the 1.6 event code. Cheers, Andrew --~--~-~--~~~---~--~~ 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: Predefined custom events handled as 'dataavailable' (1.6.0_rc0)
This is probably the most glaring flaw in RC0: any event types that are not part of the DOM L2 Events spec, but are nonetheless honored by one or more browsers, are handled incorrectly by Prototype as custom events. We've got to figure out a way around this, even if it means we create a whitelist of all known event types to work in modern browsers. The convenience of handling both custom and standard events with the same API shouldn't make it harder to (for instance) skate on the bleeding edge of Web Forms 2. I'll make sure we figure this out before RC1. Cheers, Andrew On Aug 17, 8:12 am, Wiktor Ihárosi [EMAIL PROTECTED] wrote: The new prototype is under heavy test and I find another intresting bug... The modified observe method try to get the name of the passed eventName by getDOMEventName but this is limited to the well-known events. Any unknown event will handled as 'dataavailable'. This cause problems if you use predefined events, for example using fantastic repetitionmodel (webforms2 now) implementation by Weston Ruter which implements new Web Forms 2 events. But the problem is same if you use Opera9, it has native support for these events. Here is an example page:http://devidens.hu/spacergif/2007/08/17/predefined-custom-events-hand... Please check in Opera, and click on the Add Row button. You should see two alerts, but you will only one. Unfortunately I am not good at the event model, so I don't know what is the reason of the 'dataavailable', but my dirty hack is to return eventName is condition fail. It works for me. :) if (!Event.DOMEvents.include(eventName)) return eventName; instead of if (!Event.DOMEvents.include(eventName)) return dataavailable; --~--~-~--~~~---~--~~ 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 and js-packer
No - that'd be incorrect in both cases. Semicolons are needed when a line is ended with the closing brace of a function literal or object literal, but not when a line is ended with the closing brace of a control structure. Cheers, Andrew On Aug 7, 1:09 pm, Mislav Marohnić [EMAIL PROTECTED] wrote: Looks OK. How does the rest of the core team feel about this? Do we need semicolons after: 1. conditional blocks, 2. function definitions (not function literals)? Thanks, - Mislav On 8/6/07, jdalton [EMAIL PROTECTED] wrote: Repatched per Mislavs request: http://dev.rubyonrails.org/ticket/9140 --~--~-~--~~~---~--~~ 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: : in '#myForm:myText' is not recognized when using CSS selector function
Have you tried *[id='myForm:myName']? That ought to work, though it wouldn't surprise me if it did not. A colon is a valid character in ID attributes, so it should be supported. Part of me thinks that the attribute selector approach (if it works) would be sufficient -- but another part of me thinks we should follow jQuery's lead here and just special-case the double- escaped colon in all contexts. (Out of curiosity, what happens when you try to target #myForm:myText with a CSS selector? The use of the colon to denote pseudoclass would seem to be a problem in CSS as well.) Cheers, Andrew On Jul 11, 10:43 am, kangax [EMAIL PROTECTED] wrote: I stumbled upon a href='http://www.zachleat.com/web/2007/07/10/ javascript-frameworks-and-jsf/'this page/a which compares how various JS frameworks interpret ':' inside a CSS selector function. I don't know if it's easy to implement, but would definitely be a good addition (as of now only jQuery understands such syntax). Do you think it's worth adding something like that? --~--~-~--~~~---~--~~ 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: Syntax question
On Jul 4, 1:52 pm, Vincent [EMAIL PROTECTED] wrote: I agree on the multiple declaration syntax, but in the cases above, those variables have already been declared earlier in the code and are simply assigned new values in the reported lines. Yeah, it's a mistake, but it's an innocuous one. SpiderMonkey raises a warning; other engines don't seem to care. That said, this is the sort of syntax thing that I'll correct if I'm writing a patch that touches that code anyway. So this'll eventually get fixed. Cheers, Andrew --~--~-~--~~~---~--~~ 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: document.getElementByClassName appends undefined elements
for(element in elements) {
That's the problem. Use elements#each [1] or a for loop with an index
to iterate through arrays. You can read more about this issue here
[2].
Cheers,
Andrew
[1] http://prototypejs.org/api/enumerable/each
[2]
http://andrewdupont.net/2006/05/18/javascript-associative-arrays-considered-harmful/
--~--~-~--~~~---~--~~
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, 4:41 am, Gareth Evans [EMAIL PROTECTED] wrote: Is Base an option for the naming of the parent class? I'd vote against it assiduously. It was my problem with Dean's original naming as well. In a deep class structure (Organism Animal Cat) it implies that the method being called is the *root* class's method, not the parent class's method. On Jun 25, 4:54 am, Kjell Bublitz [EMAIL PROTECTED] wrote: Yes, keep it lower-case and add an s so it reads better :) Cow-Class extends Animal (and) includes Eatable, Breadable ... We can't; extends is a reserved word in JavaScript, just like super. On Jun 25, 4:39 am, Kjell Bublitz [EMAIL PROTECTED] wrote: Parent: Please don't overuse the $ sign. It should be used for utilities and nothing else. Don't mix it in other areas, such as classes. Not quite. It's popularly used for utility methods (in Prototype and elsewhere) because it's: (a) short; (b) a valid character in identifiers; (c) obscure, reducing the chance of naming collision. Also note its use in $break (and the deprecated $continue) as an approximation of a reserved word. On Jun 25, 4:05 am, DK [EMAIL PROTECTED] wrote: 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 isn't the point I'm making. I question whether new Class makes sense as an equivalent to Class.create. The new keyword connotes an instance in JavaScript -- with its own scope and method chain. Not all things being *created* are instances. I've stated in our internal discussions that whatever we come up with should *feel* like class-based inheritance, not prototypal inheritance wearing a Groucho Marx mask. Both systems have their strengths and weaknesses, which is why it's a good idea to keep them separate so that you can choose according to your task. Mixing them up will just confuse the hell out of people. Cheers, Andrew --~--~-~--~~~---~--~~ 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?
I agree with everything Mislav said and would adopt that syntax in a heartbeat. My only concern is with the signature of Class.create and Class.extend. I feel like having instance methods and class methods in adjacent arguments can hurt the readability of the code. If you're skimming a file you might miss the closing of one object literal and the opening of another -- thus missing the transition from instance methods to class methods. Then again, there are ways around that; perhaps it's up to the individual developer to solve that problem. On Jun 25, 9:48 am, Mislav Marohnić [EMAIL PROTECTED] wrote: You can't achieve this in JavaScript. Simply let it go. I agree. Trying to emulate keywords with methods is hard enough; trying to emulate them with magic property names is even harder. It will lead to despair. Let's focus on solving the 80% problem in this release; if we need to add bells and whistles later on, we can, but if we put them in now we won't be able to remove them later. Cheers, Andrew --~--~-~--~~~---~--~~ 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, 11:29 am, Ken Snyder [EMAIL PROTECTED] wrote: I'd also like to throw in the idea that we need to prove the final OO-design decisions with use cases. We can write animal-sounds code all day long, but JavaScript is such a unique language, I think we ought to prove the design by creating some actual web-app Widgets that become quicker to write and become more maintainable and extensible by using OO patterns. There are very few opportunities for inheritance in the Prototype source code, but take a look at ajax.js in the inheritance branch; I refactored it to use the new (proposed) syntax. Perhaps someone could volunteer to convert a piece of Scriptaculous or Rico just for illustration purposes? On Jun 25, 2:30 pm, Mislav Marohnić [EMAIL PROTECTED] wrote: I sincerely doubt that people will need properties or methods named superclass or subclasses in their code. But, maybe this feature is a bit too much. We just don't know what the possible use-cases can be. After some thought, I'm in favor of keeping them the way they are. Consider the built-in constructor property -- arguably an implementation detail, but one that's worth exposing for introspection. I'd want superclass and subclasses to *feel* like constructor. Cheers, Andrew --~--~-~--~~~---~--~~ 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: Template Class (documentation related)
It's got nothing to do with luck. Arrays are implemented as a very light veneer on top of Objects; the only real difference between them is the literal syntax ([]) and the magic length property that counts your numeric keys. (In fact, the numeric keys aren't really numbers, since all object properties are coerced into strings.) Considering that the Selector class uses Template strings with arrays, I wouldn't call it improper, either. We can argue about whether it's hacky or not, but it's a behavior that deserves to be documented. Thanks for bringing this up, Jon; I'll put this on our documentation to-do list. Cheers, Andrew On Jun 24, 9:36 pm, jdalton [EMAIL PROTECTED] wrote: I find using the object is easier to read, also looking at the source its really meant for objects to be used, you got lucky in that object['days'] is also the same syntax used by array[0]. That is why indexes would work for your array and not for the object and why the property 'days' would work for the object and not the array. I don't think the documentation should support improper usage. I would classify using an array instead of an object as hacky implementation. --~--~-~--~~~---~--~~ 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
On Jun 21, 6:30 am, Rebecca Blyth [EMAIL PROTECTED] wrote: Finally, an aside on not having control over the HTML source: I ran into this issue when using the radio_button_tag helper method in Rails, which inconveniently used the name of the input as the id - unhelpful, as all the radio buttons in a group have the same name in order to group them. That's somewhat brain-dead behavior on the part of Rails. I'd encourage you to file a bug report on the ActionView component. Cheers, Andrew --~--~-~--~~~---~--~~ 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: bracket notation
On Jun 21, 2:35 pm, sed [EMAIL PROTECTED] wrote:
I'm not sure why this worked before, it must be related to the html/
script being generated into the div from the ajax.updater rather than
just being on the page.
Nope. It's sillier than that. Let's say you've got an element with an
ID of foo on the page:
var f = new String(foo);
$(f); //- null
document.getElementById('foo') //- [object HTMLElement]
This can be traced to JavaScript's bizarre String constructor --
`typeof f` returns object, not string. Looking at `f` in Firebug
will reveal ['f', 'o', 'o']. This is a crack in the object/primitive
duality of types like String and Number.
The $ function uses the typeof operator to figure out if the passed
argument is a string. Since it doesn't appear to be one, it doesn't
get run through document.getElementById.
You've found the solution already -- the new String call is
superfluous.
Cheers,
Andrew
--~--~-~--~~~---~--~~
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
On Jun 18, 2:01 am, Mislav Marohnić [EMAIL PROTECTED]
wrote:
There are only 3 possible options we're facing:
1. Don't change the $ function, leave everything as-is;
2. Fix the issue in $ by using $$('*[id=foo]');
3. Don't fix the issue, throw error instead.
My vote is for #1. The $ function is intended to be a light wrapper
around document.getElementById. The impulse is noble to want to
correct IE's incorrect behavior (and Opera's emulation thereof), but I
think it's just a little too heavy.
Cheers,
Andrew
--~--~-~--~~~---~--~~
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
On Jun 17, 8:34 am, Mislav Marohnić [EMAIL PROTECTED]
wrote:
Am I right when saying that this will fail if the ID was dynamically set (in
other words, it was not an attribute in HTML source)?
Adam's test is correct -- even dynamically-set ID attributes will
still be picked up by readAttribute in IE.
As for the difference between $('*').detect and $('*[id=foo]'): the
second is much faster in IE. The first must past each element on the
page through Element.extend. The second will extend only the matched
element.
I suggest using Element.down, since it always returns one node:
return $(document.body).down('*[id=foo]');
Cheers,
Andrew
--~--~-~--~~~---~--~~
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: Opera and Form.serialize
On Jun 3, 9:06 am, Mislav Marohnić [EMAIL PROTECTED] wrote: That doesn't make any sense. element.form.serialize should work in FF andOpera because they support native DOM prototypes. It shouldn't work in IE because the form element is not DOM extended by Prototype. And now you're telling us it works in IE, but doesn't in Opera? Nothing makes sense in the strange world of DOM level 0. The only explanation I have is that it works in IE because Christoph's script had previously done something with the form element (thus it had already been extended) and Opera's form property is just borked. Cheers, Andrew --~--~-~--~~~---~--~~ 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: next(Number) slowdown in Internet Explorer (6,7)
On May 24, 5:53 am, Mislav Marohnić [EMAIL PROTECTED] wrote: Andrew, it doesn't matter - getElementsByClassName tends to extend EVERY node in the document! If that isn't slow I don't know what is. No, it doesn't. It extends only those nodes that match the class name. I've personally spent quite a bit of energy to ensure that getElementsByClassName performs as well as possible under the circumstances, even in IE. To the author: nothing has changed about the behavior of getElementsByClassName since 1.5.0 final. It's *possibly* slower than it was in 1.4 final (because of the cost of extending each node with instance methods) -- but there have been some optimizations since 1.4, too. If it seems slower to you in the future, try doing a side-by-side comparison -- the Test.Unit framework packaged with the full source of Prototype makes it easy to run benchmarks. That way we can get some hard numbers. Cheers, Andrew --~--~-~--~~~---~--~~ 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: next(Number) slowdown in Internet Explorer (6,7)
On May 23, 7:16 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: With the latest prototype (1.5.1), the next() function (and probably also prev() and the rest of the navigation function) cause a tremendous slowdown in IE if they are used with the following syntax: next(Number). From what I saw in the code, that translates to a Selector with a '*' expression. Using next(null, 1) solves the slowdown problem. This is troubling to me. I could've sworn I fixed this back when I wrote the Selector code, but perhaps I just fixed it for the no- arguments case and not the one-numeric-argument case. We'll address this in 1.5.2. Also, since this might be related, getElementsByClassName is also very slow in this release. Compared to which release? Care to post some benchmarks? Cheers, Andrew --~--~-~--~~~---~--~~ 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: Class.create() and method binding
Dan Webb wrote: It's not a bad cause, I just think the solution is a performance eater. Imagine: the loop runs on every object instantiation. It wraps every function inside another and it needs $A for that. After that, every function call internally calls another, triggering $A one more time. To me it's a terrible waste considering the total number of objects and their respective instance method calls. And for what, solving event handling gotchas? Surely we could do some implicit binding only in places where it makes sense (for instance in the Event or Ajax modules for some operations). Yeah, your right on that point. It was my main concern. It could be streamlined a fair bit though (getting rid of $A would be fine) and I wondered how many classes that are created with Class.create() really get instantiated in a typical project. I'm interested to see the impact it does have...I'll write some tests. I think you're right though, it's probably not going to be worth the performance hit. Saying that, I use base.js quite a bit which wraps functions in quite a bit of code and I've not noticed the performance hit. My objection is not the performance hit -- it's violation of POLS. (Even though I do feel the pain this is meant to address.) The refurbished system in the events branch corrects scope automatically in IE, so that this refers to the element that received the action. This means that calling Event.observe(someElement, 'click', foo); (where foo is a function) would fire the event in someElement's scope, but calling Event.observe(someElement, 'click', Foo.bar); (where bar is a function) would fire the event in Foo's scope. I think that events firing in class scope should remain opt-in, whether through the existing `bind`: Event.observe(someElement, 'click', Foo.bar.bind(Foo)); or through an extra argument: Event.observe(someElement, 'click', Foo.bar, Foo); I prefer the latter, since it'd deprecate the useCapture argument (which won't work in IE, so we shouldn't expose it). In JavaScript, context binds in execution scope, not definition scope (though this will change for classes in ES4). I think we'd be stepping into a minefield if we introduced new magic conventions for what this means on any given line of code. It's hard enough to keep track of already. Cheers, Andrew --~--~-~--~~~---~--~~ 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: Class.create() and method binding
Would it? ;) The new Event code binds whatever it gets in IE to someElement. It doesn't know anything about Foo. I wasn't being very clear -- sorry. Those first two examples illustrate what would happen if we implemented *both* the stuff in the events branch as it is now *and* Dan's proposal to bind class methods automatically. --~--~-~--~~~---~--~~ 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
I don't know much about the code in question, but I believe those
catch blocks are in place to intercept thrown exceptions that are
extraneous (i.e., can occur sporadically without changing the result
of the code or have no bearing on the result). I can't be sure,
though, so let's take them one by one:
(1) Try.these. I think the empty catch block is justified here. The
function is designed to envelop an arbitrary number of functions that
may or may not throw exceptions. So the developer is saying, I know
this may throw an exception, but I don't care about the details
thereof: just let me know if this works or not.
(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?
(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.
Question for all: in each of these cases, if it's agreed that we need
to suppress the exception, can we re-throw it at a later time? Or
find some other way to indicate that an exception has occurred?
Cheers,
Andrew
On Apr 1, 3:33 pm, Ben Weaver [EMAIL PROTECTED] wrote:
Hello,
I've recently started using prototype 1.5 or a large project. It's
been a great experience so far.
As I've been developing, I noticed that many times exceptions raised
by errors in my code (such as, say, trying to use some property of a
null object, etc.) would not show up in my javascript console (I am
using Firebug). More troubling were exceptions that the code
explicitly threw that also mysteriously vanished.
I just worked around this for a while by interspersing console.log
statements at key places in the code I was working on, but I
eventually became curious about why errors would sometimes appear and
other times not.
I looked more closely at prototype.js and found 3 empty catch blocks
(Try.these, Ajax.Responders.dispatch, Event.stopObserving). The one
that was affecting me was in dispatch(). I found that
Ajax.Request.dispatchException() invokes Responders.dispatch for
onException callbacks, so I added
Ajax.Responders.register({ onException: function(req, e) { throw
e; } });
to my code, but the empty catch block in Ajax.Responders.dispatch()
catches all exceptions raised by responders and discards them. I
tried editing dispatch() to always throw errors that it catches;
afterwards exceptions successfully appear in my console.
I'm using this workaround now:
Ajax.Responders.register({ onException: function(req, e)
{ console.log(e); } });
and it works well for me.
I wanted to relate this experience to you because I feel that the
empty catch block in dispatch() (I can't comment on the others),
violates the principle of least surprise. I expected (and perhaps I
shouldn't have?) uncaught exceptions to show up in my console and stop
execution since this is the default behavior. Perhaps there are
strong reasons for choosing to use an empty catch block in dispatch(),
but if there are not I would suggest allowing exceptions raised by
responders to be thrown, or at least to do something like this
(admittedly ugly) compromise:
dispatch: function(callback, request, transport, json) {
var dispatched = false, exception = null;
this.each(function(responder) {
if (typeof responder[callback] == 'function') {
try {
responder[callback].apply(responder, [request, transport,
json]);
dispatched = true;
} catch (e) { exception = e; }
}
});
if (!dispatched exception (callback == 'onException'))
{ throw exception; }
}
Thanks for developing such a useful library.
Best wishes,
-Ben
--~--~-~--~~~---~--~~
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: Form.serialize, Ajax.Request, Hash.toQueryString, .toQueryParams
After a whole bunch of heated discussion about a subject that I had no idea was so controversial, my inclination is to stick to a very spec- compliant and unambitious Hash serializer for 1.5.1. Those who need more out of their serialization (proper handling of nested hashes, arrays, etc.) can write their own serialization logic. They're not forced to use the default. And down the road (1.6 and beyond) we'll try to make the whole serialization system more modular so you can plug your own in more easily. Sam, do you have an opinion here? I know we delayed the final release candidate because of this very issue. Cheers, Andrew --~--~-~--~~~---~--~~ 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: CSS syntax for node creation?
That's an interesting idea.
Parts of CSS3 parser could be reused. You could certainly use the
regexen we define to identify various CSS tokens.
My first thought was that combinators should not be allowed in that
syntax (i.e. new Element('div#mynode div.someClass'), but then I
suppose you could use such a syntax to mean create a div with a class
of 'someClass', then append it to the already-existing div with an id
of 'mynode'. That could get pretty complicated pretty fast, though.
What do other people think?
Cheers,
Andrew
On Mar 20, 3:31 pm, Colin Mollenhour [EMAIL PROTECTED] wrote:
Just a thought, if a future version of prototype were to include a
simple element creation method, what about using CSS syntax for
specification of id and class? i.e.:
var node = new Element('div#mynode.someClass');
Could the new CSS3 parser be easily reused to implement this? I looked
at it briefly but it's pretty complex :)
Good idea or bad?
--~--~-~--~~~---~--~~
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: $$() and :nth psuedo-elements
This is what I came up with for the XPath version: http://pastie.caboo.se/47671 It's a direct port of the logic of parseNth (albeit not yet tested). I'll look at yours and see if it makes more sense, though. Cheers, Andrew On Mar 17, 4:51 pm, Trevan Richins [EMAIL PROTECTED] wrote: Andrew Dupont wrote: This site might be useful:http://gallery.theopalgroup.com/selectoracle/ I'd found that site as well, but it seems to get stuff wrong. If I ask it to explain ulli:nth-child(n+2), it replies with: Wow, I didn't notice that one. The parseNth code looks better. I'm wondering, though, how you are going to convert it to Xpath? This is what I came up with:http://pastie.caboo.se/47653. It is similar to the patch I submitted in the original bug but is slightly more condensed. It first reduces the selection to the elements that fit the bth item from groups of a. Then, in the resulting selection, it grabs the elements that have a position (in this new selection, not the original one) that are = b/a (for a 0) or = b/a (for a 0). Trevan --~--~-~--~~~---~--~~ 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: Hash.toQueryString changes
You act as if the web isn't built upon conventions, even arbitrary
ones.
I think this is a POLS issue, only we disagree on which behavior is
least surprising. But since Prototype is designed to go hand-in-hand
with Rails, and since JavaScript methods can be redefined at runtime,
I think the empty brackets convention is the way to go here. If you
disagree (or if whatever server framework you use disagrees), you can
monkeypatch in your own serialization logic.
Cheers,
Andrew
On Mar 15, 5:51 pm, Marius Feraru [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Colin Mollenhour wrote:
WTF!?!?!? This is the fifth time I have posted a reply to a thread via
google groups and it says the post was successful and then it never
shows up!!
Sorry, web toys have this nasty habit of eating bytes :(
Anyway, desktop apps have it too, especially when using bleeding edge
releases, they always crash right in the moment when you really do NOT
want them to crash :))
Look, I installed and tested this on Rails (using
CGIMethods.parse_query_parameters) just for this thread and it NEEDS
brackets, ok?
Sorry x2, proving that this occult bracket convention was inherited by the
Web2.0 kings doesn't prove anything more than the fact that Rails folks
inherited it from Web1.0 kings (PHP) :))
(Which was already mentioned by Mislav, so you really wasted your time for
this - sorry x3) ;-)
If you think you're right, run a test and prove it.
Try this echo service:
request:http://www.neohub.com/ws/echo?foo=1;foo=2;foo=3;bar=4
answer:
{'bar':4,'foo':[1,2,3]}
I'd like to see tests on other platforms as well to see how brackets and
numeric indexes are handled (PHP as arrays, Rails as hashes) but I'll
leave that up to people on those platforms who give a damn (probably
nobody).
Hehe, now you reminded me that I wasted some time today too reading all the
crap^Wstuff athttp://www.php.net/manual/en/language.variables.external.php
trying to understand how does your PHP bracket convention really work.
Look quite clear that if you want arrays, you have to apply some magic to
HTML name attributes (adding []).
So, if you are using this funky serialization engine for serializing your
magic HTML forms (as Prototype currently tries to do), I'd say yes, it
should do exactly what you expect.
OTOH, as I said in my previous message, folks here seem to be trying making
up some abstract serialization engine, so this discussion is bogus, as you
don't want a perfect Form.serialize(), but just to apply some PHPism into
this application/x-www-form-urlencoded serialization engine. Why don't you
keep on using the same convention you already use in your HTML with this
toy? It should work the same. For instance:
$H({'foo[]':[1,2,3]}).toQueryString()
foo%5B%5D=1foo%5B%5D=2foo%5B%5D=3
Isn't it what you want?
- --
Marius Feraru
-BEGIN PGP SIGNATURE-
iD8DBQFF+c3ntZHp/AYZiNkRAuZWAJ9m5wHxfVbGBiAo3xQ9AOZIsqO1nwCgu95z
/m71y5jtI2XYb8Xs16gpi7E=
=JHTD
-END PGP SIGNATURE-
--~--~-~--~~~---~--~~
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: Hash.toQueryString changes
Marius, I don't want you to stop participating on this list because of a misunderstanding. Let me clarify what I'm saying. Prototype is not solely for use with Rails, obviously. I've spent the last year using it completely outside of Rails. I'm saying that when in doubt I'd do what Rails does, espcially since Rails didn't just pull it out of thin air. We *are* trying to implement a serialization method compatible with application/x-www-form-urlencoded, but you yourself concede that this falls outside the scope of the specification. Can we get a few more opinions on this issue? I don't want this to be decided only by the handful of people who've posted in this thread. Cheers, Andrew On Mar 15, 6:30 pm, Marius Feraru [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Dupont wrote: You act as if the web isn't built upon conventions, even arbitrary ones. No idea how you got to this conclusion. I think this is a POLS issue, only we disagree on which behavior is least surprising. But since Prototype is designed to go hand-in-hand with Rails, and since JavaScript methods can be redefined at runtime, I think the empty brackets convention is the way to go here. And this is really amazing, as it contradicts with what I heard about Prototype (as not being tied with Rails). I liked that, and tried to defend that. OFC, I may have heard it wrong, as I'm reading/using Prototype for just about a couple of days, so you all have my apologies for this misunderstanding. If you disagree (or if whatever server framework you use disagrees), you can monkeypatch in your own serialization logic. It's not about one server framework or another, but merely about my yet another mistake to presume your were discussing about creating an application/x-www-form-urlencoded compatible serialization engine. Anyway, hopefully no real harm done for you - besides Collin's headache -, I'll keep quiet from now on, as I'm not currently interested in Rails. Thank you all very much for supporting me and my deepest apologies for all my mistakes. Prototype was a great experience thanks to all of you. Best regards. - -- Marius Feraru -BEGIN PGP SIGNATURE- iD8DBQFF+db6tZHp/AYZiNkRAmCyAJ9jQXTdADmCHNsygN+9kmTTb5g6jACgoMoW fI+TE8VAX2r3ItKN/Cg2hzI= =lEJO -END PGP SIGNATURE- --~--~-~--~~~---~--~~ 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: Hash.toQueryString changes
#4 looks fine to me.
On #1 and #2: perhaps the answer is...
{ foo: undefined } = foo=
{ foo: null } =
I don't know if this is useful or not, but it would allow you to
distinguish between these two cases, since null and undefined are
distinct values with different meanings.
I have no opinion on #3. That's an edge case that makes my brain cry.
Cheers,
Andrew
On Mar 2, 10:48 am, Mislav Marohnić [EMAIL PROTECTED]
wrote:
I'm combining Tobie's and mine Hash patches to see how they work out. These
changes fix 3 bugs and remove some premature optimization from toQueryString
method. Now, ticket #7494 by Skirch is about nested hash support - I like it
and am thinking about rolling it in for the next release. There are a number
of questions regarding all these changes, though. I'd like to sort out the
inconsistencies.
1. undefined (or null) values are currently serialized as empty
strings - should those key/value pairs be skipped instead?
2. undefined (or null) values are currently skipped if they're inside
an array value - should it be consistent with #1?
3. should array values be flattened when serializing? (#7494 does
this)
4. should we support nested hashes?
Same questions expressed in JS code:
1. { foo:null } = foo=
2. { foo:['a', null, 'b']} = foo=afoo=b; { foo:[null] } = foo=
3. { foo:['a', ['b'], 'c']} = foo=afoo=[object]foo=c
4. { foo:{bar:'baz'}} = foo[bar]=baz
Remeber, the toQueryString is all about sending that data to the server. The
result strings are also used inside Prototype to check if the form has been
modified.
Please, state your opinions.
--http://dev.rubyonrails.org/ticket/7494
--~--~-~--~~~---~--~~
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: Ajax.Request Breaks on Firefox 2.0.0.1
On Feb 23, 4:37 pm, Colin Mollenhour [EMAIL PROTECTED] wrote: Man this is getting annoying.. I wish json.org would change their code or Prototype would use $H().each in setRequestHeaders or both (preferable) would happen soon. This is popping up on Rails Spinoffs at least twice a day it seems. I agree. Mislav, can you work on a focused patch for this, as opposed to the Object.prototype vaccine you'd proposed earlier? It's got to be worth it to get this issue off the mailing lists. Cheers, Andrew --~--~-~--~~~---~--~~ 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] New branch for $$/Selector rewrite
If you bleeding-edgers do an SVN update you'll notice that there's a new selectors branch. The version of selector.js contained therein is another major advancement from the previous version (attached to patch #7658). Christophe's excellent code reviews and revisions have been indispensible; now that this code is in SVN I hope all interested Core team members will pitch in. You'll notice that selector.js now has many, many more lines of code than it did before. In the name of optimization I was forced to write bare-bones versions of functions that exist elsewhere in the framework (document.getElementsByClassName, Element.next/prev, etc.) so that I can squeeze every possible millisecond out of the matching logic. Until it's abundantly clear which are worthwhile and which are extraneous, I'm simply writing code for every possible optimization I can think of. Happily, the benefits are being reaped in the benchmarks: see the updated test page (http://andrewdupont.net/test/ double-dollar) for illustration. I'd really like to go into more detail about all this, but my eyes refuse to remain open. I might try to write more tomorrow morning. Cheers, Andrew --~--~-~--~~~---~--~~ 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: From rubyonrails-spinoffs: is Element.setStyle a resource hog?
On Feb 18, 12:22 pm, Marius Feraru [EMAIL PROTECTED] wrote: So, the only issue still standing in this paragraph is how to detect different versions. People [1] think the right choice is not browser detection, but object detection. This is a very weary subject, I don't really want to reiterate it. FWIW, I'll just say Prototype folks did the (almost) right thing by never-saying-never (to browser detection) and you have seen examples right in setStyle (kludging opacity with filter for all versions of MSIE, or choosing to replace full opacity - 1 - with 0.99 for all Geckos). Yes, it's a real PITA, but we really have to deal with all these annoying bugs. I'm sure there are better ways, we just have to discover them. So, please help us ;-) We recognize this issue and are working on a better way to handle the browser checks in Prototype. Ticket #6800 [1] is our attempt to standardize browser checks and remove redundancy. I expect Sam to apply this patch soon, at which point we can change nasty stuff like... if (/Konqueror|KHTML|Safari/.test(navigator.userAgent)) to... if (Prototype.Browser.WebKit) I also think Mislav's patch (moving the browser checks from inside the functions to outside) is a very important one. The patch itself is outdated, but I think it's an issue we need to revisit. Depends on your purposes. Now that you mentioned ruby, AFAICT ruby folks don't give a rat's ass about performance (yet), they want to create an elegant programming language. Performance? Later on, they're still young. Maybe that is (should be) the case with Prototype too ;-) The modus operandi for Prototype these days is to optimize after the fact. First we try to write elegant code; only then do we make sacrifices in the name of optimization. On the small scale, this often means replacing Enumerables with ordinary for loops; on the large scale, it means a total rewrite of $$ like the one that's happening right now. To illustrate: I'm not interested in making $$ the fastest selector query engine on Earth. To shave milliseconds off of DomQuery or dojo.query would take far more lines of code than I'm willing to write. I'm interested in making $$ *fast enough* that it's practical to use on a regular basis. Performance is not our chief goal, but it shouldn't be a deal-breaker. Cheers, Andrew --~--~-~--~~~---~--~~ 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: Proposed rewrite of $$/Selector
Thanks for the compliments, guys. Alex Russell's post on the subject (http://blog.dojotoolkit.org/ 2007/02/04/dojoquery-a-css-query-engine-for-dojo) has stirred some diplomatic talks. It looks like Alex, John Resig, Jack Slocum, Dean Edwards, and I are going to pitch in toward some sort of site where all the different CSS-querying implementations can be benchmarked against uniform, real-world examples. I think this is a great idea and can only make all our engines better. I don't think this project has any sort of timetable, though, so when I have a moment I'll clean up what I've got so far and submit a patch so we can start discussing this. And once Sam opens up branches I think it'll be much easier to collaborate on this code. ATTENTION TO ANYONE WHO READS THIS LIST: If you're an XPath rockstar, I need to talk to you. Cheers, Andrew On Feb 5, 12:35 am, Christophe Porteneuve [EMAIL PROTECTED] wrote: I certainly concur with Mislav. I've been looking at your code twice, and it looks pretty good to me. I especially like the feature modularity thing. Yes, it weights twice as much as the current selector implementation, but then, its way faster, much more modular, and compressed JS is there for us anyhow. Submit the patch, and tickle Sam until he works with it :-) -- Christophe Porteneuve a.k.a. TDD [They] did not know it was impossible, so they did it. --Mark Twain Email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Another magical IE bug, breaks Element.extend
If setting the expando to a function, rather than a boolean, prevents
it from persisting when it should not, then that's fantastic. It'd
also solve the similar problem where cloned nodes say they're extended
but are not. Write a patch!
Andrew
On Feb 8, 12:05 pm, Mislav Marohnić [EMAIL PROTECTED]
wrote:
Two days ago I closed tickets #7497 and #7376. Both sample scripts exhibited
the same behavior in IE: after some interaction they fail because
Element.Method methods are invoked on an *extended* node, but still are not
found.
This took me a while to figure out (thanks Joe for Firebug Lite) - suppose
you have a document:
div id=test
div id=ellyI'm magical!/div
/div
If you use $('elly') somewhere in your JavaScript then elly would get
extended, right? Prototype sets the obscure property _extended to true.
Now, suppose you do some string arithmetics after that to add some HTML:
$('test').innerHTML += spanI'm a span!/span
Notice the operator. This call rewrites content in test (including
elly) and adds a SPAN to the end.
But elly is still the same element, right? It remained unchanged? WRONG.
$('elly')._extended // - true
$('elly').show // - yeah, you wish. ALL added methods are lost
So, method properties are gone, but _extended property remained.
Element.extend() never re-applies Element.Method on the node because it
thinks it is already extended.
Workaround? Easy. When we extend a specific element, we shouldn't set
_extended to a boolean true, but to some function:
element._extended = Prototype.emptyFunction
Now when all methods are wiped from the element, _extended property will
be wiped, too, giving Element.extend() a chance to re-apply DOM extensions.
--http://dev.rubyonrails.org/ticket/7497
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
