[Prototype-core] Re: Prototype vs Ext
On Jun 17, 6: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 Not sure what everyone else thinks. But, a good starting point might be: Prototype is free to use. Sure, Ext can be free, but only for free software projects (GPL3). Corporate licensing runs $540 for developer, $2000 for team, $7130 for workgroup, or $18,700 for enterprise. ...well, my wallet's screaming in pain! - Jon L. --~--~-~--~~~---~--~~ 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: Select current field in form?
Since this doesn't involve Prototype development, I'm guessing wrong group. Either way, you'll probably get more help with this in http://groups.google.com/group/rubyonrails-spinoffs Now, can't say I know an exact answer for you. But, I'd assume a combination of Form.getElements and Element.observe/ Event.observe should handle it. References: http://prototypejs.org/api/form http://prototypejs.org/api/form/element http://prototypejs.org/api/event/observe http://prototypejs.org/api/element/observe - Jon L. On May 3, 7:39 pm, Mech7 [EMAIL PROTECTED] wrote: How can i select or have a reference to a field in a form where the focus is, without specifying it directly by the id? But rather by obeserving the form, to see which field has focus. --~--~-~--~~~---~--~~ 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.success() request abort bug? (FW: Ajax.Updater Question)
(ref:
http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thread/a1f7e479a7f5d1b7)
On Apr 4, 4:38 am, Ree [EMAIL PROTECTED] wrote:
Hello,
Here's a simple example:
div id=containerNo records found./div
new Ajax.Updater({success: 'container'}, 'http://...', {method:'get',
onComplete: myCallback});
When the request fails, #container content is left as is - that's
fine. When it succeeds, #container content is replaced with the
response text - that's fine as well. However, if the request is
cancelled (ESC key is pressed, for example), #container content is
cleared completely. What is the reason behind this? Any way to prevent
this behavior? I would certainly prefer #container left untouched in
this case.
Should a request status of 0 really be treated as a success?
AFAIK -- as in Ree's issue -- the only time status is 0 is when the
request is aborted.
In the case of an abort, the 'success' container is updated to
responseText; which is empty.
success: function() {
var status = this.getStatus();
return !status || (status = 200 status 300);
},
Should it be?
return !!status || (status = 200 status 300);
(not sure about Ree, but I'm looking at 1.6.0.2.)
- Jon L.
--~--~-~--~~~---~--~~
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)
[correction]
Should it just be?
return (status = 200 status 300);
- Jon L.
On Apr 4, 4:50 pm, Jon L. [EMAIL PROTECTED] wrote:
(ref:http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thr...)
On Apr 4, 4:38 am, Ree [EMAIL PROTECTED] wrote:
Hello,
Here's a simple example:
div id=containerNo records found./div
new Ajax.Updater({success: 'container'}, 'http://...', {method:'get',
onComplete: myCallback});
When the request fails, #container content is left as is - that's
fine. When it succeeds, #container content is replaced with the
response text - that's fine as well. However, if the request is
cancelled (ESC key is pressed, for example), #container content is
cleared completely. What is the reason behind this? Any way to prevent
this behavior? I would certainly prefer #container left untouched in
this case.
Should a request status of 0 really be treated as a success?
AFAIK -- as in Ree's issue -- the only time status is 0 is when the
request is aborted.
In the case of an abort, the 'success' container is updated to
responseText; which is empty.
success: function() {
var status = this.getStatus();
return !status || (status = 200 status 300);
},
Should it be?
return !!status || (status = 200 status 300);
(not sure about Ree, but I'm looking at 1.6.0.2.)
- Jon L.
--~--~-~--~~~---~--~~
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: Detecting CTRL keydown
Each event object should have altKey, ctrlKey, and shiftKey booleans.
Support is, at least, listed for both IE and FF.
script type=text/javascript
document.observe('keydown', function(k) {
if (k.ctrlKey) return;
alert('ctrl');
});
/script
- Jon L.
On Mar 5, 7:19 pm, louis w [EMAIL PROTECTED] wrote:
I am trying to detect if the control key has been pressed to change
and action. I am using the latest proto build.
Here is my code:
script type=text/javascript
document.observe('keydown', function(k) {
if (k.keyCode != 17) return;
alert('ctrl');
});
/script
I have noticed that not always on keydown does it register, it comes
to about every other time.
Can you offer any advice.
--~--~-~--~~~---~--~~
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 deletion methods
I use a similar function to removeAt.
Just with 2 key differences:
1) Takes start (i) and end (j) indexes. Both are actually optional,
defaulting to length and taking no effect.
2) Returns the altered array with a child array containing the last
group of deleted items.
(Note: simply using [].rem().clone() will remove the child array)
If removeAt is the Ruby port, then this probably won't keep with that
aspect of Prototype.
But, I prefer it since it doesn't break chaining.
Thoughts?
/* Array#del([start [, end]]) = Array (with: deleted = Array) */
Object.extend(Array.prototype, {
del : function (i, j) {
i = (Object.isNumber(i) i = 0) ? i.floor() : this.length;
j = (Object.isNumber(j) j = i) ? j.floor() : i;
this.deleted = this.splice(i, ((j - i) + 1));
return this;
}
});
[1, 3, 5, 7, 9].del(1).del(2) //= [1, 5, 9] (with: deleted = [7])
[1, 3, 5, 7, 9].del(3) //= [1, 3, 5, 9]
[1, 3, 5, 7, 9].del(5) //= [1, 3, 5, 7, 9]
[1, 3, 5, 7, 9].del(3, 3) //= [1, 3, 5, 9]
[1, 3, 5, 7, 9].del(3, 4) //= [1, 3, 5]
[1, 3, 5].del(0) //= [3, 5]
[1, 3, 5].del(0).deleted //= [1]
[1, 3, 5].del(0, 1).deleted//= [1, 3]
- Jon L.
On Mar 4, 12:46 pm, Samuel Lebeau [EMAIL PROTECTED] wrote:
I often wanted to be able to simply remove some objects from an array
without creating another array (using Array#without for instance).
Array#splice seems to be the only way to change an array in place, and
using it is not really easy nor readable.
I submitted a patch (http://dev.rubyonrails.org/ticket/11042) which
defines two methods I find useful:
- Array#removeAt(index), which removes an object given its index
- Array#removeIf(iterator[, context]), which removes objects for
which iterator returns a truthy value
These two methods are directly inspired from they Ruby equivalent
Array#delete_at and Array#delete_if, with delete renamed remove as
delete is a Javascript keyword, and in anticipation of a future
Array#remove(object).
Ruby's Array#delete_if returns instance (this) but this implementation
returns an array of removed objects, which I think is less suprising
(please give your opinionon this point).
There are also corresponding unit tests which passes on all supported
platforms (adapted from Ruby trunk ones), and inline documentation in
PDoc format.
I hope this will be helpful for everyone !
Regards,
Samuel Lebeau
--~--~-~--~~~---~--~~
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 Prototype.Revision
Wrote a stand-alone function for calculating the signature of a
version string.
Works from 0 to 99.99.99.99_S99, where _ is any/no filler and S is
'a', 'b', 'g', 'r', or 'rc' [case-insensitive].
Tested it in both IE7 and FF2 (I don't have any others installed,
atm).
I'm sure it could use some revamping; so, let me know what you think.
Current test results:
900 : 0
0 : 0a
900 : 0h
201 : 0.0.0.0_g1
900 : 99.99.99.99
899 : 99.99.99.99_RC99
105900 : 1.5.0
1050100801 : 1.5.1_rc1
1050100802 : 1.5.1_rc2
1050100803 : 1.5.1_rc3
1050100804 : 1.5.1_rc4
1050100900 : 1.5.1
1050101900 : 1.5.1.1
1050102900 : 1.5.1.2
106800 : 1.6.0_rc0
106801 : 1.6.0_rc1
106900 : 1.6.0
1060001900 : 1.6.0.1
1060002900 : 1.6.0.2
var Version = {
signature : function (vstr) {
// VVvvRRrrSss or VVvvRRBBSss
// or: version, sub-version, release, revision or build, stage,
stage number
var stages = {
's' : 9, // stable
'r' : 8, // release candidate
'g' : 2, // gamma
'b' : 1, // beta
'a' : 0 // alpha
};
var sig = 0;
var vers = vstr === String(vstr) ? vstr : this.version;
var vnum, rnum = /^\s*[0-9\.]+/; // version number
var vstg, rstg = /(r(c)?|g|b|a)[0-9]*\s*$/i; // version stage
var vsch, vsnm; // version stage
character and number
var vspl;// version number
split
if (!!vers.match(rnum)) {
vnum = vers.match(rnum)[0];
vstg = !!vers.match(rstg) ? vers.match(rstg)[0] : '';
vsch = !vstg.match(/^[a-z]+/i) ? 's' : vstg.match(/^[a-z]+/i)
[0].charAt(0).toLowerCase();
vsnm = !vstg.match(/[0-9]+$/) ? '0' : vstg.match(/[0-9]+$/);
vspl = vnum.split('.').slice(0, 4);
vspl = vspl.concat([0, 0, 0, 0].splice(0, (4 - vspl.length)));
sig += (parseInt(vspl[0], 10) % 100) * Math.pow(10, 9);
sig += (parseInt(vspl[1], 10) % 100) * Math.pow(10, 7);
sig += (parseInt(vspl[2], 10) % 100) * Math.pow(10, 5);
sig += (parseInt(vspl[3], 10) % 100) * Math.pow(10, 3);
sig += (!!stages[vsch] ? stages[vsch] : 0) * 100;
sig += parseInt(vsnm, 10) % 100;
}
return sig;
}
};
- Jon L.
On Feb 11, 7:41 pm, Jon L. [EMAIL PROTECTED] wrote:
An alternative could be to use the release date:
var Prototype = {
Version: '1.6.0.2',
Release: '01/25/2008'
...
};
if(Date(Prototype.Release) = Date('11/07/2007')) { // 1.6.0 (November
7, 2007)
...
}
On Feb 11, 6:55 pm, tancurrom [EMAIL PROTECTED] wrote:
Build: '5234724'
Be cautious with the use of strings.
e.g. Prototype.Build = '6102' returns false ('5' '6').
- Jon L.
On Feb 11, 6:55 pm, tancurrom [EMAIL PROTECTED] wrote:
I think using a build number is considerably easier to manipulate in
the code. Its considerably more specific that a version number.
But include both
var Prototype = {
Build: '5234724',
Version: '1.6.0.3',
...
or
var Prototype = {
Build: '5234724', // v1.6.0.3
...
I can actually think when I'm going to need to call the
Prototype.Version for my code. Let the librarys match it easier.
--~--~-~--~~~---~--~~
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 Prototype.Revision
[corrections]
1)
var stages = {
's' : 9, // stable
'r' : 8, // release candidate
'g' : 3, // gamma
'b' : 2, // beta
'a' : 1 // alpha
};
2)
var vers = vstr === String(vstr) ? vstr : '';
1) the function shouldn't return 0 unless the string passed to it
can't be parsed
2) originally wrote it as part of an object with a version key.
- Jon L.
On Feb 23, 10:11 pm, Jon L. [EMAIL PROTECTED] wrote:
Wrote a stand-alone function for calculating the signature of a
version string.
Works from 0 to 99.99.99.99_S99, where _ is any/no filler and S is
'a', 'b', 'g', 'r', or 'rc' [case-insensitive].
Tested it in both IE7 and FF2 (I don't have any others installed,
atm).
I'm sure it could use some revamping; so, let me know what you think.
Current test results:
900 : 0
0 : 0a
900 : 0h
201 : 0.0.0.0_g1
900 : 99.99.99.99
899 : 99.99.99.99_RC99
105900 : 1.5.0
1050100801 : 1.5.1_rc1
1050100802 : 1.5.1_rc2
1050100803 : 1.5.1_rc3
1050100804 : 1.5.1_rc4
1050100900 : 1.5.1
1050101900 : 1.5.1.1
1050102900 : 1.5.1.2
106800 : 1.6.0_rc0
106801 : 1.6.0_rc1
106900 : 1.6.0
1060001900 : 1.6.0.1
1060002900 : 1.6.0.2
var Version = {
signature : function (vstr) {
// VVvvRRrrSss or VVvvRRBBSss
// or: version, sub-version, release, revision or build, stage,
stage number
var stages = {
's' : 9, // stable
'r' : 8, // release candidate
'g' : 2, // gamma
'b' : 1, // beta
'a' : 0 // alpha
};
var sig = 0;
var vers = vstr === String(vstr) ? vstr : this.version;
var vnum, rnum = /^\s*[0-9\.]+/; // version number
var vstg, rstg = /(r(c)?|g|b|a)[0-9]*\s*$/i; // version stage
var vsch, vsnm; // version stage
character and number
var vspl;// version number
split
if (!!vers.match(rnum)) {
vnum = vers.match(rnum)[0];
vstg = !!vers.match(rstg) ? vers.match(rstg)[0] : '';
vsch = !vstg.match(/^[a-z]+/i) ? 's' : vstg.match(/^[a-z]+/i)
[0].charAt(0).toLowerCase();
vsnm = !vstg.match(/[0-9]+$/) ? '0' : vstg.match(/[0-9]+$/);
vspl = vnum.split('.').slice(0, 4);
vspl = vspl.concat([0, 0, 0, 0].splice(0, (4 - vspl.length)));
sig += (parseInt(vspl[0], 10) % 100) * Math.pow(10, 9);
sig += (parseInt(vspl[1], 10) % 100) * Math.pow(10, 7);
sig += (parseInt(vspl[2], 10) % 100) * Math.pow(10, 5);
sig += (parseInt(vspl[3], 10) % 100) * Math.pow(10, 3);
sig += (!!stages[vsch] ? stages[vsch] : 0) * 100;
sig += parseInt(vsnm, 10) % 100;
}
return sig;
}
};
- Jon L.
On Feb 11, 7:41 pm, Jon L. [EMAIL PROTECTED] wrote:
An alternative could be to use the release date:
var Prototype = {
Version: '1.6.0.2',
Release: '01/25/2008'
...
};
if(Date(Prototype.Release) = Date('11/07/2007')) { // 1.6.0 (November
7, 2007)
...
}
On Feb 11, 6:55 pm, tancurrom [EMAIL PROTECTED] wrote:
Build: '5234724'
Be cautious with the use of strings.
e.g. Prototype.Build = '6102' returns false ('5' '6').
- Jon L.
On Feb 11, 6:55 pm, tancurrom [EMAIL PROTECTED] wrote:
I think using a build number is considerably easier to manipulate in
the code. Its considerably more specific that a version number.
But include both
var Prototype = {
Build: '5234724',
Version: '1.6.0.3',
...
or
var Prototype = {
Build: '5234724', // v1.6.0.3
...
I can actually think when I'm going to need to call the
Prototype.Version for my code. Let the librarys match it easier.
--~--~-~--~~~---~--~~
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?
For further info: http://prototypejs.org/api/function/bind
- Jon L.
On Feb 12, 2:24 pm, Jon L. [EMAIL PROTECTED] wrote:
You can use the bind method.
this.formElements.each(function (el, index) { ... }.bind(this));
- Jon L.
On Feb 12, 2:05 pm, kojilab [EMAIL PROTECTED] 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;
}
}
--~--~-~--~~~---~--~~
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
You may be better treating id as a property (or, elem.id) vs.
attribute.
'id' isn't a member of the attributes object in FF; which, I'd assume,
has at least some influence on getAttribute (maybe not).
- Jon L.
On Feb 12, 1:16 pm, Ken Snyder [EMAIL PROTECTED] wrote:
Doctuh wrote:
...
form id=foo
input type=hidden name=id' value=bar /
/form
If you have a form with a hidden form element named 'id', and you try
to use readAttribute() on the form you will get two different
responses:
IE gives you an Object (the input object named 'id')
Firefox gives you 'foo'.
IE will give you 'foo' if there is not a overriding form element.
...
I can confirm that using element.id, element.readAttribute('id'), and
element.getAttribute('id') will always return the same thing as the most
explicit form-element access: document.forms[0].elements['id']; In
fact, foo doesn't seem to be a value for any attribute of the form
node--when I iterate through the properties of the foo form, for
example, the text foo does not show up anywhere. I don't know of any
function besides getAttribute that should return it. Somehow the 'id'
node (the hidden input) in the form's elements collection overwrites the
form node id.
I don't know if there is a good way to normalize this behavior for IE
without checking for a form tag and using something hackish like a regex
on outerHTML. For example, the code below uses outerHTML and works at
least for the case you provided.
- Ken Snyder
Element.addMethods('form', {
readAttribute: function(element, name) {
element = $(element);
if (Prototype.Browser.IE) {
// begin new section
if (typeof element[name] == 'object') {
var match = new RegExp(RegExp.escape(name) + '=([^
]+)').exec(element.outerHTML);
if (match) return match[1];
}
// end new section
var t = Element._attributeTranslations.read;
if (t.values[name]) return t.values[name](element, name);
if (t.names[name]) name = t.names[name];
if (name.include(':')) {
return (!element.attributes || !element.attributes[name]) ? null :
element.attributes[name].value;
}
}
return element.getAttribute(name);
}
});
--~--~-~--~~~---~--~~
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 Prototype.Revision
An alternative could be to use the release date:
var Prototype = {
Version: '1.6.0.2',
Release: '01/25/2008'
...
};
if(Date(Prototype.Release) = Date('11/07/2007')) { // 1.6.0 (November
7, 2007)
...
}
On Feb 11, 6:55 pm, tancurrom [EMAIL PROTECTED] wrote:
Build: '5234724'
Be cautious with the use of strings.
e.g. Prototype.Build = '6102' returns false ('5' '6').
- Jon L.
On Feb 11, 6:55 pm, tancurrom [EMAIL PROTECTED] wrote:
I think using a build number is considerably easier to manipulate in
the code. Its considerably more specific that a version number.
But include both
var Prototype = {
Build: '5234724',
Version: '1.6.0.3',
...
or
var Prototype = {
Build: '5234724', // v1.6.0.3
...
I can actually think when I'm going to need to call the
Prototype.Version for my code. Let the librarys match it easier.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Can the Enumarable iterators be changed to accept scope as the first param (optionally)
So, Object.Extend as a side effect would would track the list of classes that were extended in a hash or something like it. And then we could revisit that later. Interesting idea. But, afaik, currently impossible within Javascript -- let alone Prototype. Within Object.extend's scope -- function(destination, source) -- I don't think there's any way of retrieving the name of destination, as e.g. Object.prototype, to build the array. Maybe someone else knows a way; but, I'm oblivious to it, atm. Sure, but unless I am missing something .. I have to call Object.extend on Array.prototype, Hash.prototype, ObjectRange, Ajax.Responders, Element.ClassNames.prototype to get all of the places, I never said it'd be enjoyable; only simple. Tediousness should be a given. You've also got to be cautious altering things. From what I've seen of the inner-workings, only 2 or 3 each definitions actually do anything, themselves (I think all are actually named _each). And, of course, add to that the native functions that Andrew mentioned about. Anyways...do you really need to redefine all of them now? You could just write them as you need them; starting with Enumerable.eachOf (or, whatever name you pick for it). If nothing else, that'll help spread out the tediousness so, when it kicks you in the teeth, it's not quite as brutal. ;) - Jon L. On Feb 8, 1:39 am, sambo99 [EMAIL PROTECTED] wrote: Last I checked, Object.extend doesn't check if a child is defined before redefining. So, that shouldn't be too difficult. Sure, but unless I am missing something .. I have to call Object.extend on Array.prototype, Hash.prototype, ObjectRange, Ajax.Responders, Element.ClassNames.prototype to get all of the places, Instead imagine if there was a function: SuperExtend(Enumerable, functions) that knew about all of these relationships. and would do that for me in one call. So, Object.Extend as a side effect would would track the list of classes that were extended in a hash or something like it. And then we could revisit that later. It would make more sense to have a separate function: each ( function [, binding] ) eachOf ( binding, function ) // or something similar Sound reasonable? Plausible? Sure, it sounds plausible, but I am suggesting we do this with all of the functions that accept context as a second param, this could mean that there are just too many functions. Imagine, eachOf and rejectOf, partitionOf etc.. etc.. So I agree this is a bit of a pickle but IMHO I think its worth breaking the regularity rule for this one. Generally speaking, most suggestions are posed as questions: What do you think about [suggestion]? Versus, this is BS...they're idiots...they should do it this way cause I think it's better. At least, that's the tone/attitude I got out of your aforementioned blog post. I'm new to this, and I felt pretty insulted by the suggestion I have not worked in big teams. I would like to be perfectly clear here, I love using prototype, without it my last couple of weeks would have been hell. You guys have done a great job with this library. I really just wanted to make a suggestion. Binding is such a hard concept to grasp, and I think making the library more flexible in this area would make peoples life a bit easier. Perhaps I should have chosen a different tone ... I'm new to this whole open source thing. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Can the Enumarable iterators be changed to accept scope as the first param (optionally)
On this point I have to say, It is really hard to extend prototype,
there should be a central registry Object.Extend writes to and I
should not have to write 20 lines of code to change the behavior of
each in all enumerables, it should be possible to do this in one line
of code .
I guess, I'm missing how you're thinking of handling it.
Are you hoping to open the function and add just the intended lines to
it?
You'll either have to update your own copy of prototype.js or just
override it:
Object.extend(Enumerable, {
each : function (...) {...}
});
Last I checked, Object.extend doesn't check if a child is defined
before redefining.
So, that shouldn't be too difficult.
so all three
each (function, binding)
and
each (binding, function)
and
each (function)
work with my extension.
Nothing lost only the api is more flexible with a minimal performance
hit.
Actually, regularity can also take a hit with this.
IMO, this contradicts the general assumption of how javascript
functions are defined:
function (arg0orN [, arg1orN [, ... [, argNor1or0]]]) // confused,
yet? I am
vs.
function (arg0 [, arg1 [, ... [, argN]]])
This is just my opinion...
It would make more sense to have a separate function:
each ( function [, binding] )
eachOf ( binding, function ) // or something similar
Sound reasonable? Plausible?
... and IMHO
you'd be better served just getting used to it as you will see it in any
prototype user's work, should you ever be part of a bigger team.
Jesus, this is not a pissing contest, I'm just making a suggestion
here.
Generally speaking, most suggestions are posed as questions: What
do you think about [suggestion]?
Versus, this is BS...they're idiots...they should do it this way
cause I think it's better.
At least, that's the tone/attitude I got out of your aforementioned
blog post.
When you start by pissing on someone else, it's probably not a safe
assumption to expect a pleasant response.
Besides...
Ryan wasn't pissing. He was stating a recommendation -- one I have
to agree with.
You may convince a team to adopt your extensions. But, if they don't,
you'll be stuck using a format that's not aesthetic to your eyes.
- Jon L.
On Feb 7, 11:08 pm, sambo99 [EMAIL PROTECTED] wrote:
On Feb 8, 3:34 pm, Ryan Gahl [EMAIL PROTECTED] wrote:
Completely disagree. First of all, you don't need the parentheses in your
first example. You can simply do stuff like function() {...}.bind(this).
Actually if you run
window.hello = ninja;
var MyClass = Class.create ({
test: function()
{
this.items = $A([1]);
this.hello = hello;
this.items.each(function(i)
{
alert(this.hello);
}).bind(this);
}
});
you get a ninja!
Secondly, in your conclusion you are assuming that you will always _need_ to
correct scope, when in fact you only need to do this if you want to use the
keyword this within the iterator. There are many times when you would not
be correcting scope at all, so then are you suggesting that we pass in null
as the first param?
Wrong, perhaps I should re-word it. I conclude that the API should be
more flexible:
I basically change the each function so it can be called with the
object name as the first param while maintaining backwards
compatibility.
so all three
each (function, binding)
and
each (binding, function)
and
each (function)
work with my extension.
Nothing lost only the api is more flexible with a minimal performance
hit.
Thirdly, and most importantly... just create a wrapper if you want this
syntax... and get used to creating wrappers where you want/need a new API.
On this point I have to say, It is really hard to extend prototype,
there should be a central registry Object.Extend writes to and I
should not have to write 20 lines of code to change the behavior of
each in all enumerables, it should be possible to do this in one line
of code .
//cache old method for calling within the override
Array.prototype._oldEach = Array.prototype.each;
Array.prototype.each = function(scope, iterator) {
if (scope)
iterator = iterator.bind(scope);
return this._oldEach(iterator);
};
.bind(this) is not ugly by the way. It's a very elegant solution, and IMHO
you'd be better served just getting used to it as you will see it in any
prototype user's work, should you ever be part of a bigger team.
Jesus, this is not a pissing contest, I'm just making a suggestion
here.
On 2/7/08, sambo99 [EMAIL PROTECTED] wrote:
I blogged about this issue here:
http://www.samsaffron.com/archive/2008/02/09/A+cleaner+way+to+iterate...
I think iterators look nicer when you have the scope as the first
param.
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLChttp://www.nthpenguin.com
--
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-920-574-2218
Blog:http
[Prototype-core] Re: Element.update on images. Bug or Feature Request?
$('myImage').setSrc('images/blah.jpg');
sarcasm
Wow, Kangax! That method really takes the pain out of writing
$('myImage').src = 'images/blah.jpg';
/sarcasm
The point, as is seems to be with most methods in prototype, is to
allow for a continuous inline string of them.
As the suggestion was made by Gonzalo, you can use this function, and
others, to string all alterations into one relatively simple line:
$('myEmoticon').setSrc('images/sad.jpg').setAlt(I'm sad! :( );
Or, follow Tobie's suggestion:
$('myEmoticon').writeAttribute({ src: 'images/smiling.jpg', alt: I'm
smiling! });
Either way, you eliminate the pain of setting each attribute per
line...plus, the pain of wasting resources getting the object
multiple times:
$('myEmoticon').src = 'images/sad.jpg';
$('myEmoticon').alt = I'm sad! :( ;
But, congrats on making a public ass of yourself.
--~--~-~--~~~---~--~~
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: NPE in Element.remove
If the Element doesn't have a parent node, then it's not in a context
that it can be removed from.
So, either leave it for garbage collection...or, just delete it...
var div = new Element();
delete div;
If needed, surround it in a simple test to make sure:
var div = new Element();
[...] // may/may not be inserted into DOM
if (!!div.parentNode)
Element.remove(div);
else
delete div;
- Jon L.
On Jan 25, 9:38 am, Zmitro Lapcjonak [EMAIL PROTECTED] wrote:
Hi.
The remove function texts:
Element.Methods = {
...
remove: function(element) {
element = $(element);
element.parentNode.removeChild(element);
return element;},
...
This code fails when element.parentNode == null
I use prototype v 1.6
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
