[Prototype-core] Re: Element wrapper draft notes
kangax wrote:
...
Ken,
I wanted to keep $W consistent with the rest of the library - be a
simple shortcut for creating a new instance of NodeWrapper. Just like `
$H` returns `new Hash` and $R returns `new ObjectRange`, $W should
probably return `new NodeWrapper`. $W is also responsible for
transforming string parameter into an actual element (via
`document.getElementById`):
...
this.$W = function(element) {
if (typeof element == 'string') {
element = document.getElementById(element);
}
return new Prototype.Node(element);
};
...
Using such proxy helper ($W) also ensures NodeWrapper is always
called as a constructor. There are less chances that a user will
mistakenly call `NodeWrapper` as a function and pollute the global
scope. It, therefore, allows us to get rid of this instanceof
Prototype.Node check:
new Prototype.Node('foo'); // returns a wrapper
Prototype.Node('foo'); // boom! returns undefined and creates a global
`source`/`raw` property
That makes sense. I was just thinking where it might be confusing that:
$W('foo') instanceof Prototype.Node; // true
but seeing it written out like that does make sense.
Good point about passing a wrapper into a wrapper : ) Would it make
sense to return a wrapper itself or a clone of it? Would there ever
be a need for a cloned wrapper?
The only case I can think of is when there is an item in memory with the
same id as one on the page. I don't know how we would handle that case.
Maybe the caching system could handle that somehow.
As far as caching, I'm afraid that storing reference to a wrapper on a
node itself could lead to circular references (which as we know leak
in IE's JScript). Having a separate cache-table and map elements to
wrappers by an element's id (or a custom property of an element) seems
more appropriate.
What about this caching idea: http://gist.github.com/6609
I also think that #update, #insert, #replace, etc. should allow to
accept a wrapper (besides an element or a string):
$W('foo').insert($W('bar'));
This should be as easy as giving wrapper `toElement`/`toHTML` methods
(since `update`/`insert` delegate to those when available)
Definitely.
--
kangax
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: Element wrapper draft notes
kangax wrote:
...
If the node list returns 1 element then methods like $$
(...).getValue() should return the value of that element.
(this is how jQuery handles it)
This could lead to ambiguity. We should probably discuss it more.
I agree that it is ambiguous. I find the selector result object one of
the most curious and confusing aspects of jQuery. I like the
functionality to deal with one element separate from the functionality
to deal with multiple elements. I like the concept of having methods
like NodeListWrapper#addClassName() or NodeListWrapper#setAttribute().
Once you start trying to merge the functionality of $() and $$(), code
becomes hard to follow. Furthermore, unless you use $$('#mydiv') instead
of $('mydiv') there are few cases that it is safe to assume that the
NodeListWrapper object contains only one item.
I think $A should return a ListWrapper, maybe ListWrapper could be the
$super for NodeListWrapper.
ListWrapper would have methods of Array Additions and Enumerable
methods.
Definitely a possibility if we stop extending Array.prototype.
Otherwise, I don't see much usefulness in this. NodeListWrapper
encapsulates an array of `NodeWrapper`s and its methods operate
directly on those `NodeWrapper`. A custom `_each` and mixed-in
Enumerable would take care of iteration. Am I missing something?
--
kangax
I think he means that it appears that the Enumerable mix-in concept is
necessitated the fact that native Array objects can't inherit from
Enumerable. Consider this hierarchy assuming we use a ListWrapper
instead of Array.prototype:
Enumerable (each, collect, inject, invoke, etc.)
+--ListWrapper (Enumerable + first, last, reduce, reverse, etc.)
+--NodeListWrapper (ListWrapper + addClassName, setAttribute, etc.)
+--ObjectRange (ListWrapper + overrides)
+--Ajax.Responders (ListWrapper + register, unregister, dispatch)
+--Hash (Enumerable + get, set, keys, toQueryString, etc.)
- 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: Element wrapper draft notes
...
I forked prototype, and started working on NodeWrapper/NodeListWrapper
- http://github.com/kangax/prototype/tree/master/src/element.js
Accompanying tests are there as well (although the test suite is far
from being complete).
--
kangax
Exciting to see in code! What about adding caching instances and maybe even
using a double-duty constructor instead of Class.create? See what I mean
below.
- Ken Snyder
Prototype.Element = function(element) {
if (this instanceof Prototype.Element) {
// constructor
element.__prototypeWrapper = this;
this.raw = element;
} else {
// getInstance function
// allow element to be string, dom node, or Prototype.Element instance
element = (typeof element === 'string' ?
document.getElementById(element) : element);
if (element instanceof Prototype.Element) {
return element;
}
if (element element.__prototypeWrapper) {
return element.__prototypeWrapper;
} else {
return new Prototype.Element(element)
}
}
};
$W = Prototype.Element;
var myDiv = document.getElementById('someDiv');
var myWrappedDiv = $W('someDiv');
myWrappedDiv === $W(myDiv); // true
myWrappedDiv === $W(myWrappedDiv); // true
// although $W() is called 3 times, only one instance is created
--~--~-~--~~~---~--~~
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: Roadmap for 1.6.1 (My take)
Is avoiding document.write() for IE dom:loaded included in 1.6.1? I think the core team concluded that doScroll was the way to go, but I'm not sure. What about fixing String#escapeHTML for IE and WebKit? What about enhancing Element#siblings to accept a selector? (http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thread/4dd057addb2b0be1/c354acd62c1fbe43?lnk=gstq=siblings+check#c354acd62c1fbe43) What are the thoughts on adding an Object.isEmpty or Object.hasProperties? (http://dev.rubyonrails.org/ticket/10356) Thanks, - Ken John-David Dalton wrote: I haven't seen the official roadmap for 1.6.1. So here is my take on it. 1.6.0.3 was a bug fix release. I see 1.6.1 as an optimization and new feature/API release. I see things like: * Use of documentFragment (Huge IE boost in spots), * Use of _each instead of each in places were we can * Remove the event onunload mechanism for IE (I have a working prototype of it) * Avoiding wrapped methods internally (Element.method(element) instead of element.method()) * Implement hasOwnProperty for Safari 2.0.4 (can finally use it in the rest of the code) * Make $H(...).include() work properly * Pass optional conditionals to methods like Element#show, Element#hide and others) * Optimize the Template class. * Make Element#getStyle automatically convert units to px and handle the inherit style. * Use of Dimensions class * Create various methods where needed: - Object.isNodeList() - Element#isOrphaned - Element#getNumericStyle [cssToNumber] * Ajax Fixes: - Network error fixes - Timeout added - Abort added - Detect when status 0 is allows (when its ftp or file protocols) I am sure I missed a few, but the good news is almost all of these listed features/modifications have already been programmed. We should be able to create the tickets and unit tests rather fast. Do yall have anything else to add? Here is a list of tickets currently marked to be addressed for 1.6.1 (not nessesarily included in 1.6.1) http://prototype.lighthouseapp.com/projects/8886-prototype/tickets?filter=page=1q=state%3Aopen+milestone%3A1.6.1 - JDD --~--~-~--~~~---~--~~ 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 method on Element
dobby wrote:
Hi,
The show, hide, toggle methods are great on the element object but it
would also be nice to have a setVisisble(boolean) method. This allows
you to set the visibility of an element depending on a Boolean
expression. With the current api you have to if else this behavior.
Example:
$(myelement).setVisible(element.checked);
With the current api you would have to do something like this:
if(element.checked){
$(myelement).show();
}else {
$(myelement).hide();
}
FWIW, here are two other possibilities:
// ternary statement
$(myelement)[element.checked ? 'show' : 'hide']();
// custom Element method
Element.addMethods({
setVisible: function(element, visible) {
element = $(element);
return element[visible ? 'show' : 'hide']();
}
});
$(myelement).setVisible(element.checked);
--~--~-~--~~~---~--~~
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: Capturing revert in draggable
Diodeus wrote:
I've seen a few posts about this, but no answers.
I would like to be able to call a function when a draggable revert
occurs. What I'm trying to do is replace a photo with an icon on drag
(which I've accomplished), but I need to swap it back if the revert
fires.
I really, really wish there were an onRevert() option, but there
isn't, so I guess I'll have to hack my own.
...
I propose putting it as a beforeStart call in the Effect.Move
function.
Does this make sense?
Oh yes! I've copied and pasted that function many many times. I would
like to see the callbacks beefed up with a custom event system that
would allow something like this:
myDraggable.observe('revert', function(event) {
if (myCriteria) {
event.stop(); // prevent the default revert effect
myRevertFunction(this);
}
});
myDraggable.observe('revert', function(event) {
doSomething(this);
// revert affect continues
});
Looking at Thomas's personal version of effects.js leads me to believe
he has a vision for something like this (
http://script.aculo.us/thomas/effects.js )
- Ken
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Prototype vs Ext
On Tue, Jun 17, 2008 at 5:42 PM, Franck PORCHER [EMAIL PROTECTED] wrote: ... In a few words, and in whatever spare time you Core guys might have, what is the story behind these 2 frameworks, if any, how do they compare in the long run of javascript programming (if any kind of comparison was ever attempted), and how do you foresee the future of both. Franck PORCHER www / smartech / pf A good friend of mine uses Ext because he writes applications that must work with YUI, dojo, /and/ Prototype. Using Ext allows him to write code that will work with any of those libraries. He describes it as an abstraction layer above a framework. As an abstraction, it makes sense that each Ext feature would be limited by the library with the weakest implementation of that particular feature. - 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: IE onmouseleave
Alex K wrote: Hi Guys, I've suffered IE weird bug: this browser sends onmouseout events even if the mouse is actually within the scope of the element, this happens when the mouse is over the child element. There is a way to solve this, IE send the proper event with name 'mouseleave', so my code looks like: //one more weird IE bug var mouse_out_event_name = Prototype.Browser.IE?'mouseleave':'mouseout'; Event.observe(list_item,mouse_out_event_name,this.onmouseout.bindAsEventListener(this)); Just a thought that it can be handled by the lib to save time of other folks, Thanks, Alex It's been pretty tricky to properly add support for mouseenter and mouseleave into the Prototype event system. There are a few patch attempts on the old trac system under this ticket: http://dev.rubyonrails.org/ticket/8354 . Until then, I use a short script that adds two functions Function#bindAsMouseEnter and Function#bindAsMouseLeave that work like Function#bindAsEventListener but change the function to only fire on mouseenter/mouseleave. Here is the demo and source: http://kendsnyder.com/sandbox/enterleave/ BTW, this is not a bug--it is desired behavior, but it is somewhat perplexing in most situations. - 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: Improving String.strip performance
disccomp wrote:
Please see this excellent breakdown of this function on cross-browser
performance to better understand the available solutions.
http://blog.stevenlevithan.com/archives/faster-trim-javascript
Awesome analysis!
I wonder if trim12 might be improved by avoiding calling slice if there
is no trailing white space:
function trim12 (str) {
var str = str.replace(/^\s\s*/, ''),
ws = /\s/,
i = str.length,
len = i;
while (ws.test(str.charAt(--i)));
return i + 1 len ? str.slice(0, i + 1) : str;
}
Also, you did not say it explicitly, but are you saying that /\s/.test()
is faster than whitespace.indexOf() ?
- Ken
--~--~-~--~~~---~--~~
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: DOMContentLoaded for IE
Diego Perini wrote: ... I believe the last comment in the following related thread by liorean says something too (having a separate CSSLoaded event): http://my.opera.com/nicomen/blog/2007/07/08/domcontentloaded-gotcha-with-external-stylesheets ... +1 for a separate CSSLoaded event. I'm not seeing why dom:loaded should have to have anything to do with external files. Not waiting for external files seems like the whole point of using dom:loaded as opposed to window onload. --~--~-~--~~~---~--~~ 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: String methods
braudes wrote:
Hi,
I notice that the String class doesn´t have some simple methods. So, I
added these:
ltrim: function() {
var re = /\s*((\S+\s*)*)/;
return this.replace(re, $1);
},
rtrim: function() {
var re = /((\s*\S+)*)\s*/;
return this.replace(re, $1);
},
trim: function() {
return this.rtrim().ltrim();
},
invert: function() {
var len = this.length;
var str = ;
for (var i = len - 1; i -1 ;i--){
str += this.charAt(i);
}
return str;
}
Trim is called strip in Prototype.
The others may be simple, but probably not used often enough for a place
in the Core library. And as Richard says, there are a bazillion
variations of these types of functions. Feel free to maintain a plugin
and submit it to scripteka.com.
- 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: Ajax.Request.success() request abort bug? (FW: Ajax.Updater Question)
On Fri, Apr 4, 2008 at 11:48 PM, John-David Dalton [EMAIL PROTECTED] wrote: This ticket here: http://dev.rubyonrails.org/ticket/11434 mentions asolution for dropped connections in Firefox. It might work on other browsers as well. Basically they attach a callback to the onError native event handler of the transport. Hmm... That may be another case to consider but I think that using try-catch will yeild the same result as the transport.onerror handler. After researching and testing with ajax network errors (by unplugging my network cable after request but before server response), I see the scenarios below. Requesting an HTTP(S) ajax url Network error scenarios: FF2 Win - throws exception S3 Win - transport.status == 0 O9 - transport.status == 0 IE6/7 - transport.status == (one of the following) 12002: Server timeout 12029: Dropped connection 12030: Dropped connection 12031: Dropped connection 12152: Connection closed by server Requesting a file-based ajax url Success: ALL BROWSERS - transport.status == 0 Failure: ALL BROWSERS - transport.status == 0 Additionally, Tobie mentioned WebKit can sometimes throw a -1004 error for a network exception. I don't know what case that would be. --~--~-~--~~~---~--~~ 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.success() request abort bug? (FW: Ajax.Updater Question)
On Fri, Apr 4, 2008 at 4:01 PM, Jon L. [EMAIL PROTECTED] wrote: [correction] Should it just be? return (status = 200 status 300); - Jon L. status is zero for local ajax calls which are used for unit testing and potentially used for offline development. See my patch, which, as you can see from tobie's comments, does not handle all situations in all browsers. http://dev.rubyonrails.org/attachment/ticket/10191/ajax.js.diff - 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: Ajax.Request.success() request abort bug? (FW: Ajax.Updater Question)
On Fri, Apr 4, 2008 at 11:01 PM, John-David Dalton [EMAIL PROTECTED] wrote: Also a different patch for solving the same problem. I check the window.location.href and the url of the ajax call to determin if its file or ftp protocol then allow zero or not. http://dev.rubyonrails.org/ticket/10030 Cool. I like the comprehensive regex test! One thing I'd like is to avoid an on0 callback. I can't see the need for a callback that would sometimes be triggered by a successful event and sometimes be triggered by an error condition. The other consideration is that 0 (and lots of other unusual numbers) can be thrown when there is a network exception such as dropped connection or timeout--I think all failures to reach the server should return the same code and trigger the same error across all exception types in all browsers. Am I making this more complicated than it needs to be? :D --~--~-~--~~~---~--~~ 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: Array.insert
koozdra wrote:
Thanks for the quick reply.
I ran some tests in ruby:
array = [1,2,3,4]
p array.insert(-3, 'one', 'two')
array = [1,2,3,4]
p array.insert(-1, 'one', 'two')
array = [1,2,3,4]
p array.insert(0, 'one', 'two')
array = [1,2,3,4]
p array.insert(1, 'one', 'two')
array = [1,2,3,4]
p array.insert(10, 'one', 'two')
output:
[1, 2, one, two, 3, 4]
[1, 2, 3, 4, one, two]
[one, two, 1, 2, 3, 4]
[1, one, two, 2, 3, 4]
[1, 2, 3, 4, nil, nil, nil, nil, nil, nil, one, two]
when the index is negative and of greater length than the array, ruby
throws an index out of bounds exception.
Based on that info, below is a revised method. On FF2 it seems to behave the
same as your Ruby examples. I made an index of -5 in your example work the
same as 0.
- Ken
Array.prototype.insert = function() {
var args = $A(arguments), index = args.shift();
index += index 0 ? this.length : 0;
if (index this.length || index -1)
throw new Error('Index out of bounds.');
args = [this[index], 0].concat(args);
Array.prototype.splice.apply(this, args);
}
--~--~-~--~~~---~--~~
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: Array.insert
koozdra wrote:
I propose the addition of Array.insert(index, insertee [,...]). This
method would would be like Ruby's insert. Inserts the given values
before the element with the given index
- http://www.ruby-doc.org/core/classes/Array.html#M002195
var a = ['a','b','c','d']
a.insert(2, 33)
-- ['a','b',33,'c','d']
a.insert(3, 'one', 'two', 'three')
--['a','b','c','one', 'two', 'three','d']
--
Dimitri
I always have mixed feelings about wrappers for Array#splice. It is a
very powerful method that needs no knock off, yet it is very hard to
remember. Anyhow, below is an academic stab at implementing your idea.
My only question is what to do when the index is too low or too high.
I'm not sure what Ruby does; the code below just defaults to 0 when the
index is too low or too high.
- Ken Snyder
Array.prototype.insert = function() {
var args = $A(arguments), index = args.shift();
index = index 0 ? this[this.length - index] : index;
args = [(this[index] === undefined ? 0 : index), 0].concat(args);
Array.prototype.splice.apply(this, args);
}
var a = ['a','b','c','d'];
a.insert(2, 33);
console.log(a);
// [a, b, 33, c, d]
--~--~-~--~~~---~--~~
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: Simple event delegation
Based on this thread, I created flexible Event delegation functions for attaching and removing delegation rules: http://kendsnyder.com/sandbox/delegate/ http://scripteka.com/script/element-delegate - 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: Simple event delegation
kangax wrote: Ken, take a look at my implementation [1] - it looks very much alike, except for the syntax : ) [1] http://code.google.com/p/protolicious/source/browse/trunk/src/event.register.js - kangax Cool! So if I understand it correctly, register() has three differences from mine: - register() registers all rules to the document - register() caches the Selector objects (cool!) - register() requires attaching one selector-handler pair at a time So what is this protolicious? I couldn't find any event delegation scripts on scripteka... is your script in protolicious only? - Ken --~--~-~--~~~---~--~~ 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: How can I access the object when using each?
kojilab wrote:
Hi
I have an object with a method I call run that iterates over some form
elements.
I want to be able to execute a method of that object on each element.
But when I use this in the function within the each() statement,
obviously the this doesn't correspond to the object instance.
Thanks for your help
Code snippet:
MyObject=Class.create();
MyObject.prototype = {
run: function(){
this.formElements.each(function(el, index){
this.doSomething(el);
});
},
doSomething:function(){
return;
}
}
Try $A(this.formElements).each(...);
this.formElements might be a HTML node collection object and not an array.
- 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: readAttribute() differences IE and Firefox
John-David Dalton wrote: ticket + patch for the bug: http://dev.rubyonrails.org/ticket/11092 Spiffy use of clone. Won't the line /name|id/.test(name) catch attributes such as myid? Would ['name', 'id'].include(name) be better? Or you could just add ^ and $. - Ken --~--~-~--~~~---~--~~ 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] Development Roadmap
What features are the authors considering in upcoming releases? Or is public discussion of the Prototype/SAU roadmap limited due to factors such as competition with other frameworks? Based on hints dropped in the lists, I can make a few guesses: - Expand Prototype custom events to fire callbacks for Element methods such as update, setStyle, remove, replace, insert, wrap, writeAttribute, addClassName, removeClassName, scrollTo, etc. - Add support for callback registration and multiple callbacks for SAU Effect events - Streamline SAU Effects to all use Effect#Morph - Add Prototype support for onmouseenter and onmouseleave - Add intuitive Prototype methods for checkbox- and radio-group form elements (e.g. a method to get the value of the currently checked item(s) in based on a group name) Can you confirm these and give us some insight? 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: Development Roadmap
Mislav Marohnić wrote:
...
- Expand Prototype custom events to fire callbacks for Element methods
such as update, setStyle, remove, replace, insert, wrap,
writeAttribute,
addClassName, removeClassName, scrollTo, etc.
That is planned for the next major release. Based on how it performs,
it may be pushed further down the road. We'll see.
Awesome! I've always seen the value for consistently using the wrapper
functions above (i.e. instead of using innerHTML, className, etc.) is
the prospect of callbacks.
- Add support for callback registration and multiple callbacks for SAU
Effect events
Is the current model for callbacks in script.aculo.us
http://script.aculo.us too limiting? It would be better if you would
explain this request with an example.
...
// for example, attach callbacks at any point without having to compose
a new function
var myeffect = Effect.Grow('mydiv', {afterFinish: mycallback1});
//...
myeffect.observe('afterFinish', mycallback2);
// current approach (is this even correct? it is confusing)
var fn = myeffect.options.afterFinish;
myeffect.options.afterFinish = function() {
fn.apply(this, arguments);
mycallback2.apply(this, arguments)
};
--~--~-~--~~~---~--~~
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: Development Roadmap
Mislav Marohnić wrote: ... - Add Prototype support for onmouseenter and onmouseleave This is definitely useful to the majority of users. We are still discussing if it's going to become core and in which version. Meanwhile, read the very insightful article by Andrew about why throwing the support for those events out was really a good idea (we had the working implementations far before the 1.6 release): http://andrewdupont.net/2007/11/07/pseudo-custom-events-in-prototype-16/ (The key is revisiting the same problem with another approach, and finally picking the best one) ... I may not completely understand Andrew's argument, but I think the big counter argument is that most other frameworks already support these events. And with 10 lines extra for mouseenter/mouseleave and 20 lines extra for mousewheel, I'm not seeing the slippery slope to bloated code. Furthermore, it seems that browsers are slowly converging on standards compliance (although mouseenter/mouseleave has not been proposed as a standard afaik) which will eventually simplify or remove the extra code for these events. - Ken --~--~-~--~~~---~--~~ 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: Development Roadmap
I periodically share Michael's feelings as well. For me, those concerns would be eliminated if the authors did two things: 1. Publicly disclosed the enhancements they were /considering/ (not necessarily a formal roadmap) 2. Set up a thriving community for official and unofficial plugins For example, I wouldn't mind at all if support for the mouseenter/mouseleave/mousewheel events were released as a tested and endorsed plugin. Then those who were interested could use something they knew would work with current and future versions. I find it unsatisfying that Prototype is used by so many developers worldwide including Rails and many major companies, yet finding good scripts is a Google hit-and-miss affair. I know that months ago the authors created a private built-on-prototype list, but it either died or I got kicked off :) Did that idea get killed? - Pot-Stirrer Ken Michael Peters wrote: Mislav Marohnić wrote: On Jan 7, 2008 9:25 PM, Ken Snyder [EMAIL PROTECTED] Some ideas are shared with the community while some are kept private for further discussions among core members. Why the secrecy? This is an open source project after all. So, the reason we don't share the exact roadmap to Prototype 2.0 with the public is because even we don't know the roadmap yet, and we don't want to set expectations and then break them. Sounds an awful lot like the IE team's arguments about why they are so secretive with IE development. If you want me to invest my projects, my development time and that of my team (if I'm the decision maker) into prototype/SAU then why not give me the information and confidence that I need to make that decision. I understand not wanting to disappoint, but if you're open about the plans as well as the reasons for failure/delay I'm pretty sure the community will forgive 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: Development Roadmap
This is great. Kudos to Kangax for compiling it! I'm probably dreaming too big, but it would be great if the code was submitted so that it could be hosted on the site and required unit tests to be certified for a certain Prototype version. Plus demos on the site would be fantastic. I really like the ratings system, last modified info and tagging system! - Ken Gareth Evans wrote: Ken, http://scripteka.com/ Prototype extensions library. maintained by 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: Development Roadmap
Mislav Marohnić wrote: ... - Add intuitive Prototype methods for checkbox- and radio-group form elements ( e.g. a method to get the value of the currently checked item(s) in based on a group name) Hmm, we have it for select boxes and multiple selects, why not radio buttons/checkboxes? You could open up an enhancement ticket for this request and propose an API for this. Or find a way to re-use the existing (get/setValue) API? ... Here is a brainstorm: http://pastie.caboo.se/136408 Is it intuitive, though? I would have expected the whole serializing system to go by name instead of element. I think it is too late to change that because it would break the way some people are currently using $F(). But maybe the brainstorm above is a good approach? - Ken --~--~-~--~~~---~--~~ 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] Fwd: [prototype-core] Event#unloadCache not available in 1.6.0
(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/thread/ad88e992ddaceb80 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] Event#unloadCache not available in 1.6.0
http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thread/ad88e992ddaceb80 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: features request
On Nov 21, 2007 3:29 AM, tbela99 [EMAIL PROTECTED] wrote: hello all the guys from the prototype core. I really adore what you're doing. it changed the way I was programming javascript for a while. anyway I have some features that will please me if they are incorporated in the prototype.js file. the first is the ability to dynamically load javascript and css into the page. ... One thing to keep in mind is that using several http requests (even when content is cached) instead of using one is a lot slower. I use a script that combines js and css files on the server side and serves the combined files out of a public cache directory. You can use firebug + yslow to compare the no-cache and prime-cache cases for separate and combined files. For developers, yes, keeping files separate and dependencies mapped can be very quick. That is why I keep a directory called global where I keep lots of files with small snippets. The snippets are compiled into one file for global use. In my environment, firebug + yslow showed an enormous improvement with 1 http request instead of 12 http requests. The primed-cache comparison also showed improvement. - 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: Ticket 10030 - is Ajax.Request.success() broken?
Patch submitted: http://dev.rubyonrails.org/ticket/10191 - Changed Ajax.Request.respondToReadyState() to fire onSuccess for local files and on0 + onFailure for network errors - Changed Ajax.Request.getStatus() to map IE error status codes to 0 - Changed Ajax.Request.success() to define success as a status between 200 and 299 Seems to test fine. Feed back is welcomed. - 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: Ticket 10030 - is Ajax.Request.success() broken?
Tobie Langel wrote: ... Regarding the file protocol issue, that's easy: window.location.protocol is all you need as per SOP. But what about http pages accessing files? I was under the impression that this is the prime testing situation. Just discussed the other points with Andrew. To summarize: - file protocol should always return success. - previously mentioned non-standard status codes for IE should always return a status code of 0. - status code of 0 should trigger an onFailure callback (except obviously for the file protocol). - status code of 0 should trigger an on0 callback. - as the specs don't yet specify that an exception should be raised in case of a network error, we won't implement that for the moment. So a status code of 0 will not trigger an onException callback. You're welcomed to submit a patch. ... Extremely helpful. One question: We want the file protocol to always trigger onSuccess, but what status code should it return? 200? I'm assuming we don't want files to trigger on0 I'll try to submit a patch this week. - 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: Ticket 10030 - is Ajax.Request.success() broken?
Tobie Langel wrote: Some browsers - I can't remember witch - always return a status of 0 for the file: protocol, others don't return a value at all in that case, hence this hack. We're going to be doing more work on Ajax for 1.6.1, but I'm not even sure there is a real solution ot his issue. Regards, Tobie I think the trick here is to return a separate status code for files instead of zero. I believe it is possible to handle all situations. Here is the result of my research on status codes: Calling HTTP(S) ajax url Network error scenarios: FF2 - throws exception S3 - transport.status == 0 O9 - transport.status == 0 IE6/7 - transport.status == (one of the following) 1223 : Client canceled request 12002: Server timeout 12029: Dropped connection 12030: Dropped connection 12031: Dropped connection 12152: Connection closed by server Calling file-based ajax url Success: ALL BROWSERS - transport.status == 0 Failure: ALL BROWSERS - transport.status == 0 Note: for network errors on FF 1.x transport.status == 200 and no exception is thrown so the developer is left to see that the response is empty to know of a failure. I don't think there is a workaround. So how can we know the difference between a network error and a file-based url call?--Both url and location.protocol give clues. IMHO it is important that we properly route all these codes: file-based requests should always fire onSuccess (unless we can figure out how to detect a file-based failure) and any of the network error codes should throw onException. Right now, we get all sorts of kooky callbacks such as on0 and on12029. For more info and links to my sources, see the discussion from Sept: http://groups.google.com/group/prototype-core/browse_thread/thread/1e657fad735d86de/3f25679d7451b816?lnk=gstq=ken+snyder+ajax#3f25679d7451b816 - 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: Hiding a not-yet-rendered DOM node
Ignacio Coloma wrote: Hi, I know that prototype should be kept as simple as possible but this is a common use case IMHO. This is a technique to avoid the brief flash that happens when you want a DOM node hidden if the browser has javascript, but be shown if it does not: ... Why not use noscript? What are the use cases? - 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: JSON conversion isn't adequate
Andrew Red wrote:
...
1. Date#toJSON returns a string, if evaluated, it won't become that
same date again:
I'd like to note that this unit test passes in IE and FF:
testDate: function() {with(this) {
var date = new Date();
assert((eval('new Date(' + (date - 0) + ')') - 0) == (date -
0));
}},
I'd like to propose this method instead of the current one:
Date#toJSON = function() {
return '(new Date(' + (this - 0) + '))';
};
JSON has no special provision for storing dates. They should be stored
as strings. Douglas Crockford's implementations uses ISO format with
UTC time components.
http://json.org
http://www.ietf.org/rfc/rfc4627.txt?number=4627
2. Also, Object.toJSON returns undefined if the argument is Element.
However, it might return a script that re-creates the structure of
their childern.(Like, using your ingenious DOM Bulider.)
What would a server do with the properties of a DOM Element? There are
loads of native JS objects that don't really have any value by
themselves as JSON. (e.g. window, Regexp objects, form objects, etc.)
3. Number.NaN is not null, it's Number.NaN. The string 'Number.NaN'
evaluates to this type and instance of JS object. 'null' evaluates to
null instead, it also loses the original type of the Number object.
NaN is not in the JSON specifications either. Null is the closest
representation to NaN.
Prototype's toJSON methods must play nice with server-side
interpreters. AFAIK, client-server communication is the main use case
for JSON. Also consider that JSON is not eval'ed unless the regex
detects that there are no illegal tokens such as function calls that
would open up a script to hacking.
Also see:
http://www.json.org/js.html
http://www.json.org/json.js
- 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] Ajax.Request.getStatus() new in 1.6
Tobie Langel wrote:
So Tobie, how would you use the file protocol for an ajax request?
It's mainly a backwards compatibility issue (plus it can be useful for
testing purposes).
Tobie,
Looking at John Resig's jQuery, I see that the file protocol is
considered. However, it doesn't account for URLs which have links to
static content as you mentioned might be used in testing.
httpSuccess: function( r ) {
try {
return !r.status location.protocol == file: ||
( r.status = 200 r.status 300 ) || r.status == 304 ||
jQuery.browser.safari r.status == undefined;
} catch(e){}
return false;
},
Below is an untested patch. Is it in line with your vision of
functionality? It allows URLs to call local files, eliminates the on0
callback and calls onSuccess for both local files and successful
requests. My question is: Is it possible to detect when local files
fail to load?
- Ken Snyder
Index: ajax.js
===
--- ajax.js(revision 7468)
+++ ajax.js(working copy)
@@ -74,6 +74,9 @@
request: function(url) {
this.url = url;
+this.isLocalUrl = this.url.indexOf('file:') === 0 ||
+ (location.protocol == 'file:' this.url.indexOf('://') == -1);
this.method = this.options.method;
var params = Object.clone(this.options.parameters);
@@ -162,24 +165,32 @@
success: function() {
var status = this.getStatus();
-return !status || (status = 200 status 300);
+return status == 304 || (status = 200 status 300) ||
(this.isLocalUrl !status);
},
-
+
getStatus: function() {
try {
- return this.transport.status || 0;
-} catch (e) { return 0 }
- },
-
+ var status = this.transport.status;
+ if (this.isLocalUrl)
+return 200;
+ if ([1223, 12002, 12029, 12030, 12031, 12152].member(status))
+return 0;
+ return status;
+} catch(e) {
+ return 0;
+}
+ },
+
respondToReadyState: function(readyState) {
-var state = Ajax.Request.Events[readyState], response = new
Ajax.Response(this);
+var state = Ajax.Request.Events[readyState];
+var json = this.evalJSON();
if (state == 'Complete') {
try {
this._complete = true;
-(this.options['on' + response.status]
+(this.options['on' + (this.getStatus() || 'Exception')]
|| this.options['on' + (this.success() ? 'Success' : 'Failure')]
- || Prototype.emptyFunction)(response, response.headerJSON);
+ || Prototype.emptyFunction)(this.transport, json);
} catch (e) {
this.dispatchException(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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Ajax.Request.getStatus() new in 1.6
Tobie Langel wrote:
So Tobie, how would you use the file protocol for an ajax request?
It's mainly a backwards compatibility issue (plus it can be useful for
testing purposes).
After some testing, I am seeing how using onNetworkError is not
helpful since some network errors (such as dropping vpn connection)
produce exceptions anyway. It makes more sense if all network errors
trigger the onException callback.
As far as local file support: Tobie, would the folllowing isLocalUrl
test be sufficient to test if the file protocol is used? I'm not real
familiar with file protocol behavior, especially across OSs and Browsers.
I'm just thinking it would be best to submit a patch that addresses both
issues since you mention that requesting local files looks like a
network error due to transport.status = 0.
- Ken Snyder
Ajax.Request = Class.create(Ajax.Base, {
...
request: function(url) {
this.url = url;
// we have a local request if:
// the url begins with file OR
// the window url begins with file and the url does not contain
://
this.isLocalUrl = (this.url.indexOf('file') === 0 || (
window.location.href.indexOf('file') === 0
this.url.indexOf('://') == -1
));
this.method = this.options.method;
...
}
});
--~--~-~--~~~---~--~~
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.getStatus() new in 1.6
jdalton wrote: I like the idea of having one handle for those cryptic error codes. Would onNetworkError be different than onException ( does the onException get called as well??) In my current implementation, a network error triggers onNetworkError, onLoaded, onComplete, then onFailure. I find the onNetworkError to be important because the developer can stop sending ajax requests until the user indicates that a connection has been re-established. Or, perhaps connection-testing ajax requests can be sent on a periodic basis. Throwing an exception is fine as long as the exception is clearly distinguishable from other exceptions. A custom onNetworkError callback seems more useful than having to test the exception. So Tobie, how would you use the file protocol for an ajax request? For including a client's local file with static content? Is there any other indication that it is a local file other than the url having file* ? - Ken --~--~-~--~~~---~--~~ 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] Ajax.Request.getStatus() new in 1.6
I see that Sam added a new function to 1.6
svn--Ajax.Request.getStatus(). I'm curious because I just did some
research on status codes when the network connection is dropped and
wondered if any of you (especially Sam) have any additional insight.
To summarize the situation: when ajax calls encounter network errors,
FF2 throws an exception when reading transport.status; Opera 9 and
Safari 3 show transport.status = 0; IE6 and IE7 show transport.status =
12029 (or one of 5 other values).
I see the new getStatus() function now accounts for exceptions and
transport.status of 0 (O9, S3, FF2), and thus has an on0 callback. I
propose adding IE support and changing the callback name to
onNetworkError.
Here is the code (I will submit a patch):
Ajax.Request = {
...
success: function() {
var status = this.getStatus();
return status != 'NetworkError' status = 200 status 300;
},
getStatus: function() {
try {
var status = this.transport.status;
if ([0, 1223, 12002, 12029, 12030, 12031, 12152].include(status))
return 'NetworkError';
return status;
} catch(e) {
// allow callback functions to access properties without
generating an Exception
this.transport = {};
return 'NetworkError';
}
},
...
Network error scenarios:
FF - throws exception
IE6/7 - transport.status = 12029 (or other, see below)
S3 - transport.status = 0
O9 - transport.status = 0
IE status Error codes:
1223 : Client canceled request
12002: Server timeout
12029: Dropped connection
12030: Dropped connection
12031: Dropped connection
12152: Connection closed by server
Also of note is that FF 1.x returns a status of 200 on network errors
(no Exception), so the developer is left to see that the response is
empty to know of a failure.
references:
http://dev.rubyonrails.org/changeset/7265
http://developer.yahoo.com/yui/docs/connection.js.html
http://www.thescripts.com/forum/thread573352.html
http://trac.dojotoolkit.org/ticket/2418
- 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: Indiscriminate use of breaking into words function $w()
Andrew Red wrote: Gentlemen, I notice a function which breaks a string into array of words ( $w() ) is used along the code very indiscriminately just when a simple array would suffice. ... Andrew, I'm also new to the Ruby world. It seems that the $w() function has an analogous %w() in Ruby and qw() in Perl so apparently the concept is quite widespread. As you know, Ruby and Perl are pioneers of short function names and shorthand notation which can be quite foreign to those like you and I coming from other languages. In many situations $w() does save a lot of space and makes things _more_ readable, so, for consistency, the idea is to use it everywhere within the framework. - 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: simulated DOMContentReady event
Andrew Dupont wrote: ... 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. ... If I remember correctly, this situation happens anytime a script fragment just before /body/html tries to attach a handler onDOMContentLoaded: the content registers as loaded before the script fragment can finish executing. I found it essential that the wrapper account for situations where events are attached to onDOMContentLoaded after onDOMContentLoaded has fired. - 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: string number check
Don't forget other forms such as -3000 +3000 and 3e4
An alternative to regexes:
function isNumeric(str) {
return parseFloat(str) == str;
}
It will return true for strings that JS would automatically convert to a
number.
- Ken Snyder
Frederic Gaus wrote:
Hi eggie
eggie5 schrieb:
How would I check if a string is a number?
Please use the prototype-user ml for these questions. By the way, this
question is not even prototype-related - you can do this simply with
native JS-Functions:
01122302.match(/[^0-9]/g) = true
0.23232.match(/[^0-9]/g) = false
0.23232.match(/[^0-9.,]/g) = true
abc.match(/[^0-9]/g) = false
Greetings
Frederic
--~--~-~--~~~---~--~~
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] Date prototype functions [BUMP]
Mislav Marohnic' wrote:
...
Ken, these are nice and certainly useful, but I don't think most of
the people have a need for them. Most of the heavy-duty date/time
logic should be kept in your application (server-side). But I'll let
other core members speak for themselves.
You're encouraged to keep maintaining this extensions and releasing
them open-source so people who do need them can benefit.
...
I understand and do plan to release a full-featured version as a
plugin. However, I'd like to submit the following idea for adding 47
lines to core. Again, I understand that it is probably outside of core
functionality--it is unusual that an app needs date fields or date
calculation on every page. I'm just thinking that Prototype has no date
functionality and if ever desired, this is a creative direction.
The snippet below combines some date and date prototype methods along
with Nicolas's suggested number prototype methods. I also have a short
strftime-like format function that I love, but it is short as in 50 more
lines. I'll submit this lean version as a patch once tested.
- Ken
(function() {
var multipliers = {
year: 365.25 * 24 * 60 * 60 * 1000,
month: 30 * 24 * 60 * 60 * 1000,
week: 7 * 24 * 60 * 60 * 1000,
day: 24 * 60 * 60 * 1000,
hour: 60 * 60 * 1000,
minute: 60 * 1000,
second: 1000,
millisecond: 1
};
for (var unit in multipliers) {
multipliers[unit + 's'] = multipliers[unit];
}
for (unit in multipliers) {
Number.prototype[unit] = function() {
return this * multipliers[unit];
};
}
Object.extend(Date.prototype, {
succ: function() {
return new Date(this.getTime() + (24 * 60 * 60 * 1000));
},
add: function(number, unit) {
this.setTime(this.getTime() + (number * multipliers[unit || 'day']));
return this;
},
diff: function(dateObj, unit, allowDecimal) {
dateObj = $D(dateObj);
if (dateObj === null) return null;
var ms = this.getTime() - dateObj.getTime();
var unitDiff = ms / multipliers[unit || 'day'];
return (allowDecimal ? unitDiff : Math.floor(unitDiff));
},
toJSON: function() {
return '' + this.getFullYear() + '-' +
(this.getMonth() + 1).toPaddedString(2) + '-' +
this.getDate().toPaddedString(2) + 'T' +
this.getHours().toPaddedString(2) + ':' +
this.getMinutes().toPaddedString(2) + ':' +
this.getSeconds().toPaddedString(2) + '';
}
});
Object.extend(Date, {
create: function(str) {
if (str.constructor === Date) return str;
var ms = Date.parse(str.replace('-', '/'));
return isNaN(ms) ? null : new Date(ms);
}
});
})();
$D = Date.create;
String.prototype.toDate = function() {
return $D(this);
};
// example usage
// $D() is like $(): it can accept a string or a Date object yet always
returns a Date object
$D('08/23/2007 00:00:00');
// Date.prototype.add() [chainable]
$D('August 23, 2007').add(5.months());
// Date.prototype.succ()
$R($D('Aug 23 2007'), $D('Aug 25 2007')).invoke('getTime');
// Date.prototype.diff()
$D('23 Aug 2007').diff('08-25-2007', 'hours'); // 48
--~--~-~--~~~---~--~~
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] Date prototype functions [BUMP]
What is the feeling on adding functions to Date.prototype? As mentioned
in March (see message at bottom), adding Date.prototype.succ() would
allow some helpful iterating. I would suggest an optional argument to
succ for time period and I also would like to throw out several more
possible methods (below).
- Ken Snyder
// format
var d = new Date().format('%Y-%m-%d'); // 2007-08-17
// create(static)
Date.create('8-17-07').format('%Y-%m-%d'); // 2007-08-17
// add
var d = new Date().add(2, 'month').format('%Y-%m-%d'); // 2007-10-17
// diff
new Date().diff(d, 'month'); // 2
// succ
new Date().succ('year').format('%Y'); // 2008
// isEqual
new Date().isEqual('2007-08-17', 'day'); // true
// isBefore
new Date().isBefore('08-18-2007 7:00pm'); // true
// isAfter
new Date().isAfter('8/16/2007'); // true
// withinRange
new Date().withinRange('8/1/2007', '8-31-07'); // true
// daysInMonth (static)
Date.daysInMonth(2007, 2); // 28
// ISO (static property)
Date.create('8-17-2007').format(Date.ISO); // 2007-08-17 00:00:00
If the team is interested, I could refactor my current implementation
for these functions and submit it as a patch for close review. I
understand users would probably want it lean and light if included at all.
2007-03-10 agrath wrote:
...
This is a succ function for the date prototype and could be a worthy
addition.
Date.prototype.succ = function(){
return new Date(this.getFullYear(), this.getMonth(), this.getDate()
+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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: 1.6 release; suggestion for templates
Andriy Mykhaylyuk wrote: Hello guys, thanx for update, and my congratulations, looks like a lot of people loves new updates. And I have a feature suggestion for templates system. That will be great if templates will support some sort of cycles with internal templates or table building. Something like gridview in ASP.NET for example. For a table builder it's good if we will have supported following templates : Row, AlternatingRow, Header, Footer, EmptyData. What do you think about ? I agree that more robust templating isn't a good fit for core. I had a similar need and came up with a compiled template class that is made for using a server-side html template to repeatedly generate content in JavaScript. Now that html5 embraces innerHTML, it is time to take advantage of it's speed. I have a piece of code in production that you can see here: http://rafb.net/p/jxjGr139.html. I'm working on making it more robust, but it is completely extensible and would allow you to add simple functions to give the table functionality you mention. When I finish, I'll do a full write-up on my web site. - 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] Date prototype functions
What is the feeling on adding functions to Date.prototype? As mentioned
in March (see message at bottom), adding Date.prototype.succ() would
allow some helpful iterating. I would suggest an optional argument to
succ for time period and I also would like to throw out several more
possible methods (below).
- Ken Snyder
// format
var d = new Date().format('%Y-%m-%d'); // 2007-08-17
// create(static)
Date.create('8-17-07').format('%Y-%m-%d'); // 2007-08-17
// add
var d = new Date().add(2, 'month').format('%Y-%m-%d'); // 2007-10-17
// diff
new Date().diff(d, 'month'); // 2
// succ
new Date().succ('year').format('%Y'); // 2008
// isEqual
new Date().isEqual('2007-08-17', 'day'); // true
// isBefore
new Date().isBefore('08-18-2007 7:00pm'); // true
// isAfter
new Date().isAfter('8/16/2007'); // true
// withinRange
new Date().withinRange('8/1/2007', '8-31-07'); // true
// daysInMonth (static)
Date.daysInMonth(2007, 2); // 28
// ISO (static property)
Date.create('8-17-2007').format(Date.ISO); // 2007-08-17 00:00:00
If the team is interested, I could refactor my current implementation
for these functions and submit it as a patch for close review. I
understand users would probably want it lean and light if included at all.
2007-03-10 agrath wrote:
...
This is a succ function for the date prototype and could be a worthy
addition.
Date.prototype.succ = function(){
return new Date(this.getFullYear(), this.getMonth(), this.getDate()
+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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Enumerable.pluck()-like setter
Tom Gregory wrote:
...
apply: function(iterator, attribute, value) {
return this.map(function(item, index) {
item[attribute] = value;
});
},
...
I've run into a need for this as well. I'd vote for including it under
a name 'setAll' or 'setEach'.
Or, what is the exact opposite of pluck? Pin? Place? Affix? :P
- 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: RegExp#escape
Sam Stephenson wrote: ... Good idea. Ruby has this, too, and I've missed it in JavaScript. Could you submit a tested patch to trac? -sam Patch with tests are posted. (http://dev.rubyonrails.org/ticket/9094) - ken --~--~-~--~~~---~--~~ 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: Assigning an unique ID
Tobie Langel wrote:
...
I'm also concerned about naming the method adequately. Sam suggested
Element#denominate which looks nicer than (generate|assign)Id but
which I fear could be confused with setting the name attribute. The
only other option I came up with is Element#identify. Thoughts on this
issue ?
Also, I'm wondering whether the method should return the element - for
chaining purposes and to follow the general pattern of the other DOM
methods - or the generated id itself, which IMHO would proove more
useful here. Again, what are your thoughts ?
Thanks for your valuable input,
Tobie
The function seems more useful if it returns the id. I'd vote for the
name Element#getId(). Then you can call the function and always get an
id back regardless of whether the element has an id already. I like
Jeff Watkin's exact implementation. I think that the namespacing idea
is interesting but an edge case--creating groups of elements is as easy
as creating a hash:
{group1: [el1, el2, el3], group2: [el4, el5, el6]}
- Ken
--~--~-~--~~~---~--~~
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] Assigning an unique ID
Michael Peters wrote:
...
Just some random thoughts: maybe putting it in String since it returns a
string?
String.createUid()? Or maybe hanging it off of Prototype itself (seems like
that
would set a bad precedent for hanging tons of useful methods off of the
Prototype namespace). In Perl land we have Data::UUID for stuff like this, so
maybe we should introduce a Data namespace?
Having a general object utility is a good idea. And, as Ryan points out,
a prefix can provide a simple convention for future access to elements
without caching the ids.
Brainstorming in specifics, what about a method called
Object#assignGuid? After all, we are reading/writing a property of an
object. Below is Jeff's original function reincarnated. I think it is
simple and widely useful.
Object.assignGuid = function(object, prefix) {
if (prefix === undefined) prefix = '__guid';
if (!object.id) {
object.id = prefix + (arguments.callee.nextId++);
}
return object.id;
};
Object.assignGuid.nextId = 0;
Then, if we wanted to cater to the high-use-case Element or
Element.Method scenario:
Element.assignGuid = function(element, prefix) {
return Object.assignGuid($(element), prefix);
};
- 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: Assigning an unique ID
Jeff Watkins wrote:
...
Element.Methods.assignId = function(element) {
element= $(element);
if (!element.id)
element.id= uniqeId_ + (arguments.callee._nextUniqueId++);
return element.id;
}
Element.Methods.assignId._nextUniqueId=0;
...
+1 for such an addition. It is especially useful for object
hashing--being able to look up some data by element. It looks like the
YUI library uses a similar function called generateId() in their drag
and drop, menus, treeviews and more.
- 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] Inheritance: your thoughts?
Mislav Marohnic' wrote: ... In conclusion, my philosophy is: * no magic properties except initialize * keep the inheritance support code simple and short , otherwise it makes no sense in having it * leave room for users to make their own additions to the inheritance support code * no dollar-signs and underscores because they indicate bad design (exceptions from this rule are $super/$parent) * don't try to make defining of classes look like you're writing Ruby, it simply won't work. This is EXACTLY how I feel--your whole post. Much better than I could say it. As far as the superchaining property, I like (1) $super, (2) $parent. +1 for simple and short support for inheritance in Prototype 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. The need for advanced OO JavaScript is such an edge case right now--I think we need to prove its real-world value. --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: Inheritance: your thoughts?
Mislav Marohnic' wrote:
On 6/25/07, *Andrew Dupont* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Perhaps someone could volunteer to convert a piece of Scriptaculous or
Rico just for illustration purposes?
Stuff in Prototype that benefits from inheritance:
TimedObserver, PeriodicalExecuter, Form.Observer,
Form.Element.Observer, Form.EventObserver
Observer class from event.js in the event branch
Ajax.Request, Ajax.Updater, Ajax.PeriodicalUpdater and maybe other
(new) Ajax stuff
Yah, those use _inheritance_, but how much would they benefit from this
new advanced inheritance? How many of those methods would be
shorter/more maintainable/more extensible by accessing this.$super et al?
Browsing those functions, I don't see much if any opportunities for
improvement on those class methods. Looking closely at the Ajax
classes, for example, I see only one method (Ajax.Updater.initialize)
that is actually superseding a parent method. See below.
Aren't all the new OO patterns we are discussing dependent on child
methods that supersede parent methods? Maybe I'm mistaken.
I think that even just talking generally about how classes and functions
would be rewritten would be helpful to assessing real-world value.
--Ken
var Ajax = {
getTransport: function() {...},
activeRequestCount: 0
}
Ajax.Responders = {
responders: [],
_each: function(iterator) {...},
register: function(responder) {...},
unregister: function(responder) {...},
dispatch: function(callback, request, transport, json) {...}
};
Object.extend(Ajax.Responders, Enumerable);
...
Ajax.Base = function() {...};
Ajax.Base.prototype = {
setOptions: function(options) {...}
}
Ajax.Request = Class.create();
Ajax.Request.Events = [...];
Ajax.Request.prototype = Object.extend(new Ajax.Base(), {
_complete: false,
initialize: function(url, options) {...},
request: function(url) {...},
onStateChange: function() {...},
setRequestHeaders: function() {...},
success: function() {...},
respondToReadyState: function(readyState) {...},
getHeader: function(name) {...},
evalJSON: function() {...},
evalResponse: function() {...},
dispatchException: function(exception) {...}
});
Ajax.Updater = Class.create();
Object.extend(Object.extend(Ajax.Updater.prototype,
Ajax.Request.prototype), {
**initialize: function(container, url, options) {...},
updateContent: function() {...}
});
Ajax.PeriodicalUpdater = Class.create();
Ajax.PeriodicalUpdater.prototype = Object.extend(new Ajax.Base(), {
initialize: function(container, url, options) {...},
start: function() {...},
stop: function() {...},
updateComplete: function(request) {...},
onTimerEvent: function() {...}
});
--~--~-~--~~~---~--~~
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] Small Documentation Request - Enumerable.invoke
Hi Team,
I just wanted to make a small documentation request for
Enumerable.invoke. I discovered it useful that invoke returns the
processed array of items. The docs specify that invoke returns an
array, but it isn't clear that you can chain two invoke commands to call
two methods in succession. See examples below.
Thanks,
Ken Snyder
$$('div.thumbnail')
.invoke('observe','mouseover',thumbMouseOver)
.invoke('observe','mouseout',thumbMouseOut);
$$('#windows div.close')
.invoke('addClassName','active')
.invoke('show');
--~--~-~--~~~---~--~~
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: Small Documentation Request - Enumerable.invoke
Mislav Marohnić wrote: Thanks. It's not obvious to all, so I added one of your examples to the doc. Awesome! That was faster than approving a wiki edit :P --~--~-~--~~~---~--~~ 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: Hijack Browser Loading
[EMAIL PROTECTED] wrote: You are correct in your assumption of the functionality and unfortunately came to the same conclusion as me in that it can't be done. I do like your idea of setting a cookie maybe once the page is loaded saving wether the browser has JS enabled. Then my server side code could check that cookie on the next page request and serve up all the images if no JS or only the first tab's images if they have JS. The only other option I'm thinking of is wether I could use something like a noscript / block in an image src? Is that valid semantically? Ah yes! I believe you can have any content in a noscript block. Just keep the content to a minimum since ninety-someodd-percent people have javascript enabled. Regards, Ken --~--~-~--~~~---~--~~ 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: Hijack Browser Loading
[EMAIL PROTECTED] wrote: Hey guys, I'm building a web app and am hoping to minimize the images loaded per page. I like the way YouTube only loads the thumbnails of the images you can see and then waits till you scroll before loading any others. They do this by placing img / tags for the initial images and then use javascript to fill out the rest. The only problem with this is someone without javascript won't see any of those additional images. So my question, and thought, was to do something like this: This looks like a question for the Rails-Spinoffs group. A simple unobtrusive approach would be to have a drawer of thumbnails with a link to view more images. For JavaScript enabled browsers, simply override the functionality of that link to load a list of image locations from memory or by AJAX. An image will be downloaded by the browser anytime 1) it parses an img with a src attribute, 2) an img node with a src attribute is added to the DOM via JavaScript, or 3) any existing img has its src changed via JavaScript. This should be standard across all browsers. As a developer, you should be able to control when images are loaded by keeping these three in mind. Note that browser image caching rules apply according to the HTTP headers sent with the image. --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: Hijack Browser Loading
[EMAIL PROTECTED] wrote: A simple unobtrusive approach would be to have a drawer of thumbnails with a link to view more images. For JavaScript enabled browsers, simply override the functionality of that link to load a list of image locations from memory or by AJAX. The only problem with that is people without JavaScript don't see those additional images. Let me explain a little more: I have three tabs, and only one can be viewed at a time. Therefore, I'd really only like the images to only be loaded in the first viewed tab, there's no since loading images in a tab people can't see. Then when people click over to another tab those images are loaded. Make sense? No. I don't see how you can click over to another tab or load more images unless you use JavaScript and or provide a link that loads a new page with new images. You can only control the loading of images by changing the URL or JavaScripting. Maybe provide an example page? --Ken --~--~-~--~~~---~--~~ 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: Community Repository
Mislav Marohnic' wrote: On 5/17/07, *Ken Snyder* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Would the Prototype Core Team endorse an official repository Probably, but only with scripts and plugins actually *maintained* by the Core team. ... I'm sure that we could find community resources for design, hosting, and maintaining an official repository. What are the Core Team's thoughts? Dunno. We obviously can't tell what the community can or can't do. But we're always on the lookout for great Prototype-related stuff and probably would support such project by linking and writing about it. Awesome. Thanks again for all your hard work! I think I'll try out Ben's Wiki. --~--~-~--~~~---~--~~ 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] Object.extend() with Multiple Sources
Has it ever been proposed to change Object.extend() to accept multiple
sources?
For example, instead of:
Object.extend(Object.extend(Ajax.Updater.prototype,
Ajax.Request.prototype), {...}));
do the following:
Object.extend(Ajax.Updater.prototype, Ajax.Request.prototype, {...});
Here is a quick example rewrite:
Object.extend = function() {
var sources = $A(arguments), destination = sources.shift();
sources.each(function(source) {
for (var property in source) {
destination[property] = source[property];
}
});
return destination;
}
Would core be interested in such a patch, or is there some drawbacks I'm
missing? Too much overhead maybe?
-- 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: adding $parent to Object.extend
Ryan Gahl wrote: You may find my blog entry from last week to be interesting here: http://www.someelement.com/2007/03/multiple-inheritance-with-prototypejs.html http://www.someelement.com/2007/03/multiple-inheritance-with-prototypejs.html As I state in the entry, I borrow from Kevin Lindsey's inheritance model, but have made it work quite nicely with prototype, and honestly think it would fit nicely into the core (keep Object.extend as is but add Object.inherit) Very clever and exciting implementation! +1 for adding this to core. It is simple, powerful, and more syntactically appealing than Dean Edward's Base. It seems like a convention that Prototype could easily embrace. --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] CSS syntax for node creation?
That would certainly be unique and powerful. What would this
hypothetical class allow? Consider the following:
Create and Append at Position-- new Element('#content div#mynode.someClass')
Define Attributes-- new Element('[EMAIL PROTECTED]text]')
Create an Array of Nodes-- new Element('#address li.errors span')
The more I think about it, the more my brain hurts. Not sure if that
means it is a good idea or not :P
--Ken
Colin Mollenhour 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: Ajax.Request Breaks on Firefox 2.0.0.1
Andrew Dupont wrote: (I seem to recall there's an older version of Crockford's library that plays nice -- Mislav, do you know where to find it?)... I posted an older version several weeks ago on ROR-spinoffs. There are several versions of JSON that don't rely on Object.prototype; they create a JSON object with methods stringify and parse. Pick your favorite: http://www.google.com/search?q=json+stringify+parse Regards, 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] From rubyonrails-spinoffs: is Element.setStyle a resource hog?
Andrew Dupont wrote: ... I just submitted #7585: http://dev.rubyonrails.org/ticket/7585 This patch also serves as an example of how I'd like to overhaul Prototype's browser detection. This looks beautiful. Great work! --~--~-~--~~~---~--~~ 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] More Event Handling Propositions
Colin Mollenhour wrote:
But, I don't think the overhead of a bind call and the storage of an
object with a function for EACH event observed is justifiable, just to
have the convenience of:
handle.stopObserving();
rather than:
Event.stopObserving(handle);
Colin, your patch is superb. Thanks!
I completely agree. Memory usage and speed far outweigh the syntactic
sugar gained by returning an object.
I've been doing a lot of research on the subject of Event registration.
It made me question: do we really need to detach listeners in IE on
unload? Unless anyone knows for sure, I plan to test. It might make
sens to turn off caching by default _if_ detaching IE listeners on
unload is unnecessary. Also, I think we can remove the try-catch blocks
on lines 116 and 125 of your patch because exceptions should never be
generated (see
http://www.w3.org/TR/2002/WD-DOM-Level-3-Events-20020208/events.html#Events-EventTarget-addEventListener)--perhaps
more testing...
--Ken
P.S. Just to share my research, let me summarize the Event registry
issues: (via http://www.quirksmode.org/js/events_advanced.html and others)
1. In IE, this inside the attached function refers to window.
2. In IE, events always bubble.
3. The new W3C Event attribute eventListenerList is not yet
implemented in any browser.
4. Legacy browsers (NS4,IE4,IE5/Mac) do not support multiple event
registration.
5. Some browsers prefer keydown over keypress.
6. Safari will return text nodes as targets.
1. Prototype cleverly circumvents the first: Prototype provides
Function.bindAsEventListener() and Event.element(event) to reliably find
the target element. I say clever because other solutions (such as
attaching the function to the element:
http://www.quirksmode.org/blog/archives/2005/10/_and_the_winner_1.html)
end up causing more problems than they solve. Incidentally, I find that
passing arguments to Function.bind() and Function.bindAsEventListener()
often makes using Event.element() unnecessary.
2. Prototype solution: In both models Event.stop() stops bubbling if
requested
3. Prototype solution: To be addressed through caching (i.e. Colin's patch!)
4. Prototype solution: Do not support legacy browsers (hallelujah)
5. Prototype solution: Simple detection
6. Prototype solution: none. Should we patch Event.element() with an
additional line?
Event.element = function(event) {
var target = event.target || event.srcElement;
return target target.nodeType == 3 ? target.parentNode : target;
}
--~--~-~--~~~---~--~~
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] More Event Handling Propositions
Along with all this Event handling discussion, I'd like to throw in my
ideas for a rewrite of Event.observe et al before I test and submit as a
patch. My proposed changes allow the traditional Event.stopObserving()
and simplify some of the current messaging ideas. Please provide feedback.
Consider this API:
var myHandle = Event.observe(myElement, 'click', myFunction);
myHandle.stopObserving();
// with support for the traditional Event.stopObserving()
Event.stopObserving(myElement, 'click', myFunction);
Draft suggestion below. One thing I'm also considering is making the
handle's stopObserving function remove its own entry from the
Event.observers array, but that isn't technically necessary.
--Ken Snyder
Object.extend(Event, {
//...
// the cache of observers
observers: [],
//
// replacements for observe, stopObserving, unloadCache with
enhanced functionality
//
observe: function( element, event, observer, useCapture ) {
element = $(element);
useCapture = useCapture || false;
element[Event._addFnName](Event._eventName(event), observer,
useCapture);
var handle = {
event: event,
observer: observer,
useCapture: useCapture,
stopObserving = function() {
try {
element[Event._removeFnName](Event._eventName(event), observer,
useCapture); } catch(e) {}
}
}
Event.observers.push(handle);
return handle;
},
stopObserving: function( element, event, observer, useCapture ) {
element = $(element);
useCapture = useCapture || false;
Event._stopObservations(function(handle) {
return handle.element==element handle.event==event
handle.observer==observer handle.useCapture==useCapture;
});
},
unloadCache: function() {
Event.observers.invoke('stopObserving');
Event.observers = null;
},
//
// New methods
//
// New method: cancel all the observers associated with a particular
element for a particular event
stopObservingElementEvent: function( element, event ) {
element = $(element);
Event._stopObservations(function(handle) {
return handle.element==element handle.event==event;
});
},
// New method: cancel all the observers associated with a particular
element
stopObservingElement: function( element ) {
element = $(element);
Event._stopObservations(function(handle) {
return handle.element==element;
});
},
// internal function to cancel one or more observers
_stopObservations: function(partitioner) {
var handles = Event.observers.partition(partitioner);
if( handles[0].length ) {
handles.invoke('stopObserving');
Event.observers = handles[1];
}
}
};
// pre-define cross-browser function and event naming
if( window.addEventListener ) {
Event._addFnName = 'addEventListener';
Event._removeFnName = 'removeEventListener';
if( navigator.appVersion.match(/Konqueror|Safari|KHTML/) )
Event._eventName = function(name) { return name=='keypress' ?
'keydown' : name; };
} else {
Event._eventName = function(name) { return name; };
}
} else if( window.attachEvent ) {
Event._addFnName = 'attachEvent';
Event._removeFnName = 'detachEvent';
Event._eventName = function(name) { return 'on'+name; };
// garbage collect for IE
window.addEventListener('onunload', Event.unloadCache);
}
Improvements:
- Browser capability is detected only once
- Has a simpler API
- Gives a simple way to cancel all observers for a particular element or
element-event combination
- It is simple to cache all observers associated with a particular
widget and stop all with widgetHandles.invoke('stopObserving');
- It is easily extendable (i.e. new methods such as
Event.isObservedElement() and Event.isObservedElementEvent())
--~--~-~--~~~---~--~~
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: More Event Handling Propositions
Ken Snyder wrote:
Along with all this Event handling discussion, I'd like to throw in my
ideas for a rewrite of Event.observe et al before I test and submit as a
patch. My proposed changes allow the traditional Event.stopObserving()
and simplify some of the current messaging ideas. Please provide feedback.
Colin, thanks for pointing out that my observer array will slow things
down in many cases. I really like your implementation, especially the
way you keep a different EventCache object. One thing I wonder, though,
if like you said your function returns an index--an array index could be
problematic, but why not use an object as a cache? Consider the draft
below.
--Ken
Object.extend(Event, {
//...
// the cache of observers
observers: {},
// the current position in our cache
cacheIdx: 0,
// added return of cacheIdx to allow Event.stopObserving(idx)
observe: function( element, event, observer, useCapture ) {
element = $(element);
useCapture = useCapture || false;
element[this._addFnName](this._eventName(event), observer, useCapture);
this.cacheIdx++;
this.observers[this.cacheIdx] = [element, event, observer, useCapture];
return cacheIdx;
},
stopObserving: function( element, event, observer, useCapture ) {
if( typeof arguments[0]=='number' ) {
this._cancel(arguments[0]);
} else {
element = $(element);
useCapture = useCapture || false;
element[this._removeFnName](this._eventName(event), observer,
useCapture);
//
// The current implementation seems not to clear the cache like this
//
for( idx in this.observers ) {
if( this.observers[idx][0]==element
this.observers[idx][1]==event
this.observers[idx][2]==observer
this.observers[idx][3]==useCapture) {
delete this.observers[idx];
break;
}
}
//
//
//
}
},
unloadCache: function() {
for( idx in this.observers ) {
this._cancel(idx);
}
},
//
// New methods
//
// function that actually detaches the event and clears from cache
_cancel: function(idx) {
var handle = this.observers[idx];
try {
handle.element[this._removeFnName](this._eventName(handle.event),
handle.observer, handle.useCapture);
delete this.observers[idx];
} catch(e) {}
},
// New method: cancel all the observers associated with a particular
element for a particular event
stopObservingElementEvent: function( element, event ) {
element = $(element);
for( idx in this.observers ) {
if( this.observers[idx][0]==element this.observers[idx][1]==event )
this._cancel[idx];
}
},
// New method: cancel all the observers associated with a particular
element
stopObservingElement: function( element ) {
element = $(element);
for( idx in this.observers ) {
if( this.observers[idx][0]==element )
this._cancel[idx];
}
}
};
// cross-browser function and event naming
if( window.addEventListener ) {
Event._addFnName = 'addEventListener';
Event._removeFnName = 'removeEventListener';
if( navigator.appVersion.match(/Konqueror|Safari|KHTML/) )
Event._eventName = function(name) { return name=='keypress' ?
'keydown' : name; };
} else {
Event._eventName = function(name) { return name; };
}
} else if( window.attachEvent ) {
Event._addFnName = 'attachEvent';
Event._removeFnName = 'detachEvent';
Event._eventName = function(name) { return 'on'+name; };
// garbage collect for IE
window.attachEvent('onunload', Event.unloadCache);
}
Using an indexed object as a cache even opens up the possibility of
using my original API suggestion:
...
observe: function( element, event, observer, useCapture ) {
element = $(element);
useCapture = useCapture || false;
element[this._addFnName](this._eventName(event), observer, useCapture);
this.cacheIdx++;
this.observers[this.cacheIdx] = [element, event, observer, useCapture];
return { cancel: function() { Event._cancel(cacheIdx); } };
}
...
stopObserving: function( element, event, observer, useCapture ) {
if( typeof arguments[0]=='object' arguments[0].cancel ) {
arguments[0].cancel();
} else {
...
--~--~-~--~~~---~--~~
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 Fails in Prototype Release 1.5 When also loading json.js
NL wrote:
When loading both Prototype Release 1.5 and the The open source code
of a JSON parser and JSON stringifier library (http://www.json.org/
json.js).
I tried this on Firefox 1.5.0.9 (Mac)
I haven't looked at the reason but have a feeling this may impact
other libraries as well.
Yes, the www.json.org implementation has some funky stuff. For one, in
the current version (2007-01-10), Object.prototype.toJSONString will
cause problems with lots of other JS code (anything that iterates
objects with for-in). Here is an implementation based on a previous
json.org implementation. There are lots of other flavors out there too.
/*
Copyright (c) 2005 JSON.org
*/
/*
The global object JSON contains two methods.
JSON.encode(value) takes a JavaScript value and produces a JSON text.
The value must not be cyclical.
JSON.decode(text) takes a JSON text and produces a JavaScript value.
It will
return false if there is an error.
*/
var JSON = function () {
var m = {
'\b': '\\b',
'\t': '\\t',
'\n': '\\n',
'\f': '\\f',
'\r': '\\r',
'' : '\\',
'\\': ''
},
s = {
'boolean': function (x) {
return String(x);
},
number: function (x) {
return isFinite(x) ? String(x) : 'null';
},
string: function (x) {
if (/[\\\x00-\x1f]/.test(x)) {
x = x.replace(/([\x00-\x1f\\])/g, function(a, b) {
var c = m[b];
if (c) {
return c;
}
c = b.charCodeAt();
return '\\u00' +
Math.floor(c / 16).toString(16) +
(c % 16).toString(16);
});
}
return '' + x + '';
},
object: function (x) {
if (x) {
var a = [], b, f, i, l, v;
if (x instanceof Array) {
a[0] = '[';
l = x.length;
for (i = 0; i l; i += 1) {
v = x[i];
f = s[typeof v];
if (f) {
v = f(v);
if (typeof v == 'string') {
if (b) {
a[a.length] = ',';
}
a[a.length] = v;
b = true;
}
}
}
a[a.length] = ']';
//
// Addition by Ken Snyder
//
} else if (x instanceof HTMLElement || x==window || x==opener) {
return;
//
// End Addition
//
} else if (x instanceof Object) {
a[0] = '{';
for (i in x) {
v = x[i];
f = s[typeof v];
if (f) {
v = f(v);
if (typeof v == 'string') {
if (b) {
a[a.length] = ',';
}
a.push(s.string(i), ':', v);
b = true;
}
}
}
a[a.length] = '}';
} else {
return;
}
return a.join('');
}
return 'null';
}
};
return {
// copyright: '(c)2005 JSON.org',
// license: 'http://www.JSON.org/license.html',
/*
Stringify a JavaScript value, producing a JSON text.
*/
encode: function (v) {
var f = s[typeof v];
if (f) {
v = f(v);
if (typeof v == 'string') {
return v;
}
}
return null;
},
/*
Parse a JSON text, producing a JavaScript value.
It returns false if there is a syntax error.
*/
decode: function (text) {
try {
return !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
text.replace(/(\\.|[^\\])*/g, '')))
eval('(' + text + ')');
} catch (e) {
return false;
}
}
};
}();
// optional compatibility with stringify/parse:
JSON.stringify = JSON.encode;
JSON.parse = JSON.decode;
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
