There's a discussion in the Prototype users google group that it would be good
to get some response to from one (or more) of the core devs. [1]
Please.
Tom Gregory
t...@byu.net
1:
http://groups.google.com/group/prototype-scriptaculous/browse_thread/thread/7d434e109c23c306
--
You
I'm going to agree with others, and say a) this is not a bug, and b) isn't
worth making the change. The observer pattern (on which the event architecture
is based), by design, does not guarantee order; nor should it, as it would
imply the observers are not orthogonal.
If you have order
On Dec 2, 2009, at 8:36 AM, Richard Quadling wrote:
2009/12/2 David Kaufman da...@gigawatt.com:
Mailing Tobie and Andrew bags of cash, or giving them great-paying
no-show jobs at Google probably couldn't hurt either :-)
I wouldn't mind one of those great-paying jobs. I'll turn up! I'll
A few thoughts:
1) You will have better luck, I think, building the library first, distributing
it, and showing there is a need. Then you'll have momentum in your favor. One
way to help get it out there is scripteka.com.
2) It feels a little like you're asking someone else to do the
Good list.
I'd add function chaining and element selectors ($$, et al). ... But
that pushes the list to eleven.
#6 is vague ... it could mean many different things (even contain its
own list of 10!)
TAG
On Nov 17, 2008, at 10:56 PM, Andrew Dupont wrote:
I'm thinking about how we can
On Oct 26, 2008, at 2:37 AM, Richard Quadling wrote:
-1 for strikeout - simply looks ugly.
+1 for [deprecated]
Agreed. Would it be too much information in the left menu to also add
the version the item was deprecated in? There are several old
versions still live in the wild.
At the
On Oct 8, 2008, at 11:29 AM, Andrew Dupont wrote:
I shall end the shitstorm here and now.
... he probably can't think of a single case in which it's
_useful_ to use the wrapper objects instead of the primitives they
wrap.
Honestly, I can't either. I don't see any reason to use the
AM, Yanick wrote:
Hi Tom,
The Prototype version hosted by Google seems not to be compressed. I
haven't look deep, but if it loads this URL
http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js ,
then it is not compressed.
yanick
On Oct 3, 12:22 am, Tom Gregory [EMAIL
, 7:23 am, Tom Gregory [EMAIL PROTECTED] wrote:
Isn't that what I said? The advantage from Google is not
compression,
but caching (if multiple sites use it).
There was talk at one point of releasing an official compressed
version so Google could use it. I don't remember the outcome
There is no official compressed version.
I use jsmin. (jsmin.org) Other tools work too.
Some use proto-packed http://groups.google.com/group/prototype-core/files
but I don't know whether it's up to date. (You'll have to check.)
There is also the Google-hosted version. It's not compressed,
Err, that line of reasoning is flawed.
O (2n) [or, if you prefer, 2 * O (n)] is conceptually equal to O (n);
neither are the same as O (n^2). Iterating through a loop twice (e.g.
two loops in series) is still linear, not exponential.
TAG
On Sep 16, 2008, at 10:30 AM, Mark Holton wrote:
In Prototype parlance, trim is strip:
http://prototypejs.org/api/string#method-strip
And in response to Richard, instead of writing your own left, try
truncate. Many other needs (ltrim, rtrim, right, mid) are already
met with sub.
TAG
On Apr 22, 2008, at 8:13 AM, braudes wrote:
Hi,
in IE7/Firefox2/Safari3, and
note which browsers misbehave. (IIRC it was Firefox; I'll log bugs
against Firefox too, if need be.)
TAG
On Dec 22, 2007, at 6:46 PM, Tobie Langel wrote:
Hi Tom,
Thanks for your patch.
Would you mind opening a ticket with it against the latest trunk
It's a browser bug in setAttribute, IIRC. el.checked does not always
equal el.getAttribute('checked'), and under some circumstances,
el.setAttribute('checked', true) does not change el.checked. I think
el.disabled has the same problem.
Attached are unit tests and a patch (based off the
on the
native IE event passed.
Tom
On Oct 9, 1:54 pm, Matt Foster [EMAIL PROTECTED] wrote:
You sure that will fail? I am pretty sure the static event methods
should all work with a regular event object.
Isn't it just for convenience, like the Element methods that they put
Evethe method
On Sep 25, 2007, at 4:20 PM, Andrew Red wrote:
To explain the subject line, I believe, the concept of JSON strings
should be described by the following formula:
eval(obj.toJSON()) - obj,
i.e. toJSON methods should return such a string from an object that if
evaluated, the result to be
On Sep 14, 2007, at 1:08 AM, Roland wrote:
Hi there,
Events can be attached multiple times to the same element.. is there a
way to prevent this?
Something like ...
if(!$(el).hasEventAttached()) Event.observe($(el), 'click',
function());
If this is what you *really* need (and I'd
Is there a gotcha with this code? (I haven't tested, and defer to
brighter minds than mine.)
Because he's replacing the target node with a clone of itself (code
below), is there the potential to lose attached event observers?
That'd violate POLS.
/* This is much faster than using
On Aug 30, 2007, at 5:52 PM, Mislav Marohnić wrote:
On 8/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
also, for generating unique arrays:
function uniqueArray( array ){
var uniqueHash = {}, unique=[], i;
for( i=array.length; i--; ){
if( !uniqueHash[ a[i] ]){
I was thinking about this the other day as I was going through
Christophe's book ... I know I'm resurrecting an old thread, but stay
with me.
Instead of adding a maxFrequency option, (really, maxDelay),
perhaps it would be more extensible to allow decay to accept a
function as well as a
Confirmed.
I rewrote as unit tests (the alerts didn't show what was actually
failing):
http://pastebin.com/m6bc554f9
==Safari 3.0.3 (OS X):
failed testEachWriteAttribute
1 assertions, 1 failures, 0 errors
Failure: assertEnumEqual: expected [true], actual [false]
It's quite odd to me that
Done. ... quite a while ago, actually.
On Aug 21, 2007, at 3:46 PM, Thymus wrote:
A method to get a string from an element and reverse.
I explain :
input type=text id=input /
alert($('input').toHTMLString());
should display the string : 'input type=text id=input /'
On Aug 17, 2007, at 12:22 AM, Mislav Marohnić wrote:
It's nice to hear about how all of you solved the problem of
collection attribute assignment, but the variety of solutions shows
that this is very app-specific (IMO).
I won't argue against not including (invoke-ing writeAttribute
On Aug 15, 2007, at 9:58 AM, Ken Snyder wrote:
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
: would such an idea be useful when dealing with arrays
of hashes, or is using each() so trivial as to not bother with
another helper?
TAG
On Aug 14, 2007, at 5:20 PM, Tom Gregory wrote:
It might be something easy that I'm overlooking, but I don't see
what I'm looking for as part of either
FWIW, tests are failing for me in Safari (but worked in Firefox):
/SVN/prototype/trunk $ svn update
Updated to revision 7289.
/SVN/prototype/trunk$ rake
/SVN/prototype/trunk$ rake test
(in /SVN/prototype/trunk)
/test/unit/dom.html on Safari: FAILURE
/test/unit/form.html on Safari: FAILURE
Use Firebug. Make sure you're using the most recent version of
Prototype.
Your sample works for me in Safari and Firefox. The code could be a
bit cleaner--it might make debugging easier.
This strip-down version does the same thing (it works too), and is a
bit easier on the eyes (for me,
}
temp[temp.length]=this[i];
}
return temp;
},
Thank you,
Tom H Anderson
--~--~-~--~~~---~--~~
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
Might I suggest that if valid Javascript isn't accepted by the
packer, the problem is with the packer, not the source? Have you
looked into patching the packer?
TAG
On Jul 29, 2007, at 10:50 AM, FOX wrote:
Hi,
I patched latest prototype.js 1.5.1.1
My version can be compressed to 40kB
I think it's time to let it drop. You've had several of the core
developers--the guys with commit access to the repository--say no.
(Given that I'm not a core dev, I don't get much of a vote here, but
FWIW I agree: leave $() alone. IE's practice is both misguided and
easy to work around.)
Two comments--
I should know better than to try to do this quickly without double
checking, but here goes...
1) Does this solution continue to work when borders are assigned with
element/class selectors, rather than inline?
2) I seem to recall there is something screwy with how borders are
On Mar 26, 2007, at 3:06 PM, Tobie Langel wrote:
Honestly, I haven't followed the toQueryString debate myself to
closely... so I can't really voice an opinion.
FYI, the discussion he's referring to is here:
http://groups.google.com/group/prototype-core/browse_frm/thread/
0140fdf88eed057d
On Mar 26, 2007, at 3:43 PM, Tobie Langel wrote:
Regarding the JSON workaround - as you call it - the idea was not to
offer a workaround, but to trigger a discussion on whether (or not)
JSON wasn't a more appropriate solution in some cases, and if we
should add toJSON methods for form
On Mar 18, 2007, at 9:13 AM, Mislav Marohnić wrote:
On 3/16/07, Tom Gregory [EMAIL PROTECTED] wrote:
This problem didn't exist (at this volume level) until Prototype
started serializing Forms as Hashes instead of query strings
What problem? I thought we were merely discussing about
On Mar 18, 2007, at 9:13 AM, Mislav Marohnić wrote:
On 3/16/07, Colin Mollenhour [EMAIL PROTECTED] wrote:
why can't Ajax.Request leave the parameters option a string if it
is passed a string?
Then we would need to branch the logic around hacks into hacks for
strings and hacks for
trim already exists under the name strip (taken from Ruby).
You may wish to consider the international nature of prototype when
proposing functions like makePlural or addCommas.
TAG
On Mar 12, 2007, at 2:59 AM, Richard Quadling wrote:
Hi.
Great to see some new functionality in
You've led me to an interesting thought, though. Would you support
tweaking Form.serialize and/or $F to check for the presence of an
onSerailize callback attached to the element, whose result is
returned instead of element.value if the callback exists? It would
make it easier for you to
My opinion:
1. I support skipping nulls, as (depending on server implementation)
'foo=' may result in an empty string on the server rather than null.
Serialize empty strings.
2. Yes, although you could pursue numerical indexes (not my
preference), similar to how you handle hashes in #4,
Hey I'm excited about it. I think your patch is a great idea.
I'm not a core developer, so my opinion has no weight ... but I like
the concept. Really. =)
I think it would cleanup the widget destroy functions. For example,
complex Sortables.
TAG
On Feb 28, 2007, at 2:24 AM, Colin
Patch at http://dev.rubyonrails.org/ticket/7625
Patch replaces magic numbers with Node constants (four instances, all
in dom.js). Unit tests run on Firefox/Safari on OS X. Still needs
to be tested in IE.
TAG
On Feb 22, 2007, at 8:53 AM, Tom Gregory wrote:
I'll run a find/replace
That's only half of a proper question. Any answer has to be viewed in
the context of the full question:
Does anyone have states of the affected share __for some target
audience__. Google has a different audience than MSN, Yahoo, or AOL.
(I'll stereotype and suggest a higher proportion of
On Feb 21, 2007, at 2:56 PM, Mislav Marohnić wrote:
Also, what about that Safari text-node event target thing? Should
we have a fix for that also?
Isn't that as easy as updating Event.element(), or am I missing
something?
i.e.
element: function(event) {
+var e = event.target ||
While I love the simplicity of the function, there is one workaround
that I think needs to be considered. IE does not allow the 'name'
attribute to be changed after createElement() is called.
To quote MSDN: The NAME attribute cannot be set at run time on
elements dynamically created with
43 matches
Mail list logo
