[Prototype-core] Re: Return value of Event.stop()
+1 on the idea, seems like a winner to me.
-- T.J.
On May 25, 8:35 pm, Tobie Langel tobie.lan...@gmail.com wrote:
Great idea.
Would you mind submitting a patch with tests?
Thanks,
Tobie
On May 25, 12:01 pm, Johan Arensman johanm...@gmail.com wrote:
Hello everyone,
I was just checking out some of my code to see if I could optimize it and I
noticed that in event handlers the event.stop() method has to be
called separately from all other code. Something I like about prototype is
that a lot of methods can be chained like the Element methods
(e.addClassName('bla').insert(foo).toggle().observe('click', bar)...).
But instead of returning the event, event.stop() returns 'undefined' making
it impossible to do something like this:
var e = event.stop().findElement('a');
and forcing me to use 2 lines:
event.stop();
var e = event.findElement('a');
I've added 'return event;' at the bottom of the stop method in Event.Methods
and it works perfectly (in FireFox, haven't tested in other browsers). Is it
possible to make this small change? Or is there a reason why the event isn't
returned?
Greetings,
Johan Arensman
--
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group
athttp://groups.google.com/group/prototype-core?hl=en
--
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
[Prototype-core] Re: proposal: function to validate HTML
Hi,
Validating HTML against a DOCTYPE is a non-trivial task, and it should
be (IMHO) an authoring-time task (using tools like the W3C
Validator[1]) rather than a runtime task, where Prototype is mostly
focussed on the latter. So I don't see adding this to Prototype. (This
is just my opinion; I'm not a core dev, I don't make decisions for the
project).
If you're receiving HTML from an external source at runtime, I can see
the desire to validate it. For that kind of thing, you may want to
integrate with one of the validation services out there (there's a
short list here[2]) and/or look into mod_validator[3] for Apache.
[1] http://validator.w3.org/
[2] http://validator.w3.org/docs/help.html#others
[3] http://apache.webthing.com/mod_validator/
HTH,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / com
www.crowdersoftware.com
On May 6, 12:33 pm, walther diechmann waltherdiechm...@gmail.com
wrote:
on the rebound from a 'tour de force' of W3C specs pertaining to the
DOCTYPE and it's cripling effects on IE's (not) handling improperly
written input tags I was wondering:
Given I have a HTML string
When I call Object.validate( html_string [, doc_type])
Then I can see whether the HTML string is valid
{ errors_count: 2, warnings_count: 1, errors: { 1: { line: 5, short:
'short description', help: URL }, 2: {}}, warnings: { 1: { } } } =
Object.validate( string [, string] )
with URL being a link to the non conformancy related W3C document/
chapter/paragraph
Just a thought :)
BTW: You could - using the validate method - build validation into
methods like Element#replace and #update, when supplying an option or
argument...
Cheers,
Walther
ps. I'm in way pointing my fingers at IE which (in this case) turns
out to be the exemplary scholar in class, sticking to the standards
entirely!
--
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group
athttp://groups.google.com/group/prototype-core?hl=en
--
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
[Prototype-core] Re: Event.observe(window, 'load'.. issue not fixed!
Hi,
Why isn't this issue still
fixed?!
You say still. Is there an _open_ bug report for it in
Lighthouse[1]? Because if there isn't, it's not going to be fixed.
In any case, I don't think it would be a fix, it would be an
enhancement. As far as I know, Prototype does not make any guarantee
as to the order in which multiple event handlers on an element will be
called (because there is no guarantee provided by the underlying
APIs). To do so, Prototype would have to replace the browser's list of
event observers with its own, which would be overkill (IMHO).
[1] http://prototype.lighthouseapp.com/projects/8886-prototype/overview
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / com
www.crowdersoftware.com
On Apr 15, 2:03 pm, Dziamid dzia...@gmail.com wrote:
Event.observe(window, 'load', function () {
alert('1');});
Event.observe(window, 'load', function () {
alert('2');});
Firefox, opera alerts 1 then 2, IE alerts 2 THEN 1!! Order is
reversed and developeres are puzzled! Why isn't this issue still
fixed?!
--
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
To unsubscribe, reply using remove me as the subject.
[Prototype-core] Re: Helping with the web site once it's on github
Tobie, I'd like the perfect solution as much as anybody, I just haven't bumped into it yet. If you have, please speak up. If not, please spare me that kind of remarks. They're just completely counter-productive Oh for cryin' out loud, Tobie. There are roughly 50 wiki engines out there that make contributing a darn sight easier than using flippin' git. But: P.S.: For the record. Mislav's right, you can fork the project and edit it in the browser. Excellent! So minimum requirement is a browser. -- T.J. On Apr 9, 10:55 am, Tobie Langel tobie.lan...@gmail.com wrote: I think I can live with that. We'll have to disagree on that, then, and it's your project. For a project I was running, I would consider it a completely unacceptable barrier to non-code contribution. I'd like the perfect solution as much as anybody, I just haven't bumped into it yet. If you have, please speak up. If not, please spare me that kind of remarks. They're just completely counter-productive Thanks. Tobie P.S.: For the record. Mislav's right, you can fork the project and edit it in the browser. -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en To unsubscribe, reply using remove me as the subject.
[Prototype-core] Re: Helping with the web site once it's on github
Mislav, Fair nuff. I'm not going to argue the point, though I think one could argue it from a ... no, wait, saying from a ___ perspective would be arguing the point, and I'm not going to, because: 1. It's not my project 2. It's not my project (I think it's worth saying twice) :-) 3. The people *actually running the project* have made their decision 4. GitHub makes life fairly easy for people who don't use git, so this whole discussion was pretty much unnecessary. You don't need git to help out. You just need a browser. Thank you again for pointing that out. -- T.J. On Apr 9, 12:29 pm, Mislav Marohnić mislav.maroh...@gmail.com wrote: On Fri, Apr 9, 2010 at 09:47, T.J. Crowder t...@crowdersoftware.com wrote: We'll have to disagree on that, then, and it's your project. For a project I was running, I would consider it a completely unacceptable barrier to non-code contribution. From my experience: I'm working on an open-source project right now for my employer. This project has had a number of contributions over the past 3 weeks (since I started), most of them coming from people that don't know git. These contributions were translations, design changes, copywriting. It was generally more difficult and time-consuming to merge in changes submitted by people who didn't use git than from people that did. Also, patches from people generated by git were generally more quality. I fully back Tobie's decision to set up some bar for contributors. -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en To unsubscribe, reply using remove me as the subject.
[Prototype-core] Re: Helping with the web site once it's on github
Tobie, I'm just not going to continue this, it's a pointless aggravation for both of us. Have a good one, -- T.J. On Apr 9, 1:10 pm, Tobie Langel tobie.lan...@gmail.com wrote: Oh for cryin' out loud, Tobie. There are roughly 50 wiki engines out there that make contributing a darn sight easier than using flippin' git. But: Hosted, fully style-able wikis with an integrated blog engine, which allow inclusion of static HTML pages (the generated API doc), and can live on their own domain name for less than $7/month ? Yes please!! -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en To unsubscribe, reply using remove me as the subject.
[Prototype-core] Re: Roadmap
+1 on more information outside the core team on where Prototype is headed, agnostic as to what form it takes. Since this is the core mailing list, it seems like it would be here, but I don't recall mention of the new layout stuff or on here. (Could be my memory, though.) -- T.J. On Apr 8, 12:06 am, Allen Madsen bla...@gmail.com wrote: I agree that a road map would be helpful. In addition to the reasons gf3 mentioned, I think it would make it easier to contribute. Allen Madsenhttp://www.allenmadsen.com On Wed, Apr 7, 2010 at 4:53 PM, gf3 giannichiappe...@gmail.com wrote: This is a continuation of the discussion started here: http://github.com/sstephenson/prototype/commit/2f9bde3ad5a2e3dd104c81... It would be very helpful to see some sort of Prototype roadmap or at least be able to see internal discussion about the development of the library. Not only from a personal interest standpoint but I also receive a lot of questions on IRC regarding what Prototype is doing, what's happening with development, c. Unfortunately, right now, I don't really have an information that I can pass on. Tobie mentioned a public read-only interface to internal discussions – this would satisfy my needs. Although a formal roadmap may be beneficial to core devs as well. -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/prototype-core?hl=en To unsubscribe, reply using remove me as the subject. -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en
[Prototype-core] Re: Kudos to the documentation team
Yes, but we're moving away from it. So a JavaScript solution would work now, and later (since I assume you're moving from Mephisto to something else that *also* supports JavaScript). If 301s work later, great, but if not there's a fallback position. A script included on each old API page that reads the current location and figures out the new URL and inserts a prominent This info is old, go look here instead box at the top (worded perhaps *slightly* more carefully) sounds like a half-day project to do right. (It sounds like an hour-long project, but you know it gets more complex and you get into ito.) I have a half-day I can give it at the end of the month, but not sooner, if that would be useful. -- T.J. On Apr 7, 3:04 pm, Tobie Langel tobie.lan...@gmail.com wrote: Can we use JavaScript on Mephisto pages? -- T.J. Yes, but we're moving away from it. -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en To unsubscribe, reply using remove me as the subject.
[Prototype-core] Re: Kudos to the documentation team
...I've written an HTML to Markdown parser:http://github.com/mislav/remark Oh, I just know that could be very handy indeed... -- T.J. :-) On Apr 8, 2:51 pm, Mislav Marohnić mislav.maroh...@gmail.com wrote: On Thu, Apr 8, 2010 at 15:11, Tobie Langel tobie.lan...@gmail.com wrote: We'll be using prototypejs.org directly. It's supported by Github. I see. In that case, you have to ensure that old URLs are preserved. Once you're on GitHub, there will never be a chance to do 301 redirects. If you need help porting content, contact me. I've written an HTML to Markdown parser:http://github.com/mislav/remark I've used it to port my own blog to Jekyll once I've lost the original markdown sources. -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en To unsubscribe, reply using remove me as the subject.
[Prototype-core] Re: Helping with the web site once it's on github
Thanks. Purely git? Not ruby (unless you also want to install Jekyll)? Mind you, it seems to me even git is a barrier to casual helpers, if they don't already use it. -- T.J. On Apr 8, 3:10 pm, Tobie Langel tobie.lan...@gmail.com wrote: Git. Jekyll is totally optional for regular content contribution. Installing Jekyll is rather straightforward, though. http://wiki.github.com/mojombo/jekyll/install Best, Tobie On Apr 8, 3:12 pm, T.J. Crowder t...@crowdersoftware.com wrote: Hi folks, I think most on the list know that Tobie's trying to move the website off Mephisto and onto GitHub, because GitHub has some lovely features in this regard. Once that has happened, what's the *minimum* that a user needs to have on their machine to contribute to the website? -- T.J. :-) -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en To unsubscribe, reply using remove me as the subject.
[Prototype-core] Re: Kudos to the documentation team
Tobie, Can we use JavaScript on Mephisto pages? -- T.J. On Apr 6, 6:49 pm, Tobie Langel tobie.lan...@gmail.com wrote: Urm... really? You can do 404's but not 301's? I was suggesting crating a good 404 page. Not modifying the http response code. Not saying I don't believe you, I'm just surprised that a project as mature as prototype is hosted in an environment that doesn't support basic .htaccess-style configuration. There's historical reasons to this. We're in the process of migrating, though (not that this will change much in terms of low-level access). Best, Tobie -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en To unsubscribe, reply using remove me as the subject.
[Prototype-core] Re: Kudos to the documentation team
My coworkers still find old docs (http://prototypejs.org/api) by googling. I had to point them to new doc site. I think it's crucial to set up 301 redirects. *ONLY* if all of the old information has now been ported over. Looking at the documentation Lighthouse project[1], it looks like all of the old merge/update tickets have been closed (yay!), which may mean exactly that, someone from the docs team can presumably confirm that. Once we're ready, 301s that live in those locations for a long, long time are indeed appropriate. Or if 301s are hard in Mephisto, replacing each of the API documentation articles with a link to the new one. [1] https://prototype.lighthouseapp.com/projects/42103-prototype-documentation/overview -- T.J. On Apr 5, 3:30 pm, Mislav Marohnić mislav.maroh...@gmail.com wrote: On Mon, Apr 5, 2010 at 11:48, Johan Arensman johanm...@gmail.com wrote: Wow! I didn't even realise they were updated until I read this message. Very nice work indeed! My coworkers still find old docs (http://prototypejs.org/api) by googling. I had to point them to new doc site. I think it's crucial to set up 301 redirects. -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en To unsubscribe, reply using remove me as the subject.
[Prototype-core] API Documentation Sections
Am I the only one who didn't realize the Sections in the list on the left were clickable? I only found out when I followed a link to the Ajax section from Ajax.Request, trying to find the options so I could point someone at them. In retrospect it's obvious that they would be, and certainly the cursor has the right shape, but something about the styling makes me think of them purely as headers, not something clickable in their own right. Anyway, if it's just me, it doesn't matter (I mean, I know they're clickable now). If others have had the same reaction, it may be worth looking at the styling of those. -- T.J. -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en To unsubscribe, reply using remove me as the subject.
[Prototype-core] Kudos to the documentation team
The new docs Andrew pushed yesterday are a HUGE leap forward! Well done to everyone who contributed to both the content and the improved linkability and such. Major kudos! -- T.J. :-) -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en
[Prototype-core] Re: Capturing BACK BUTTON event in IE
Your post to the Prototype Core mailing group has not been posted. Prototype Core is for discussion of the development of the framework. Questions about *using* the framework should be asked on the Prototype script.aculo.us mailing list: http://groups.google.com/group/prototype-scriptaculous (Separately: Do you *really* want to publish your phone number on the web?) Happy coding, -- T.J. Crowder (one of several moderators) On 2 March 2010 10:47, Medisetti Rajesh(Dora Babu) medisetti.raj...@gmail.com wrote: hi friends, Is there any way to capture the BACk BUTTON event in IE? You help is most appreciated. -- Thanks Regards Medisetti Rajesh Ph : 09930798770 Satyameva Jayathey--Truth Alone Triumphs -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en
[Prototype-core] Re: parameters Encoding differents in Ajax Request
@Peter: On Dec 29 2009, 10:18 pm, Peter holota.pe...@gmail.com wrote: Try to use url parameters with url and not in parameters: Far, far better to ensure that your page and processing of it are using the correct and consistent character encoding. @All: This group is for discussion of the development of the Prototype library, not discussion about using it. The user's discussion group is here: http://groups.google.com/group/prototype-scriptaculous ...although from the discussion so far, this doesn't seem to be related to Prototype so much as HTML and PHP. Good luck with it, -- T.J. Crowder Independent Software Consultant tj / crowder software / com www.crowdersoftware.com -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en
[Prototype-core] Re: Class inheritance by reference
Hi, I ran into problems when I tried to change a class that another class was extending. The changes did not inherit. Can you post a small, self-contained example? If you use Class.create and addMethods, changes should show up. That kind of dynamism is designed into Prototype's inheritance mechanism and covered by unit tests. -- T.J. Crowder Independent Software Consultant tj / crowder software / com www.crowdersoftware.com On Dec 22, 1:08 pm, Sakari Tuominen saka...@gmail.com wrote: Hello guys! I've been working with Javascript classes for a while now. I have been using Prototype's class inheritance. I ran into problems when I tried to change a class that another class was extending. The changes did not inherit. I found out that the extending is done when the extending class is defined. I think it's kinda bad, so I made my own version where the extending is done with a reference. I even made an article about it. Here it is: http://www.sakarituominen.com/blog/javascript-class-inheritance-madne... Please tell your thoughts! -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en
[Prototype-core] Re: For() loops, ++i, i++, i+=1
Thanks for that info and link, Robert! Obviously, we who develop web
apps for normal users should leave the setting alone most of the time,
but good to know we can change it for these sorts of tests. (And wow,
I thought it was a time limit; that explains why something I was doing
the other day was giving me this error way faster than I expected.)
Results for IE7 on Windows XP:
http://tinyurl.com/y8fb77y
http://tinyurl.com/yd3vuzz
http://tinyurl.com/ydqgvwr
http://tinyurl.com/ye8hwvb
(I find it's best to run these tests multiple times.) Basically, it's
a wash (++i or i++), but i += 1 is markedly slower. As you say,
Robert, unlikely to make any difference in the real world.
I'd post Chrome and Firefox results for Windows, but I kept getting
infinite numbers of operations per second! ;-) Chrome (of course!) did
an infinite number of ops/second on all of the tests. Firefox
alternated between infinite numbers of ++i and i++ operations -- so
probably a wash there too.
Now, since I apparently have the power to do infinite numbers of
calculations, I'm off to break some RSA keys...
-- T.J. ;-)
On Dec 16, 2:48 pm, Robert Kieffer bro...@gmail.com wrote:
Unfortunately IE limits scripts to 5M statements, rather than limiting by
time. That limit was set back in the days of IE4, when 5M statements would
take ~10 seconds to run. But newer hardware/script engines hit that in a
fraction of a second now... which is why you're seeing it.
The workaround is to edit your registry to increase the limit to 50M
statements (or more). This MS article explains how, and provides a bit more
background on of this ( ridiculous) behavior.
http://support.microsoft.com/default.aspx?scid=kb;en-us;175500
On Wed, Dec 16, 2009 at 4:44 AM, Allen Madsen bla...@gmail.com wrote:
I tried running your test on IE8 and it just kept prompting me with script
unresponsive.
Allen Madsen
http://www.allenmadsen.com
On Wed, Dec 16, 2009 at 7:01 AM, Robert Kieffer bro...@gmail.com wrote:
I whipped up a quick JSLitmus test to try out a handful of empty loops
(using i++, ++i, i+=1, and a while loop:
http://www.broofa.com/Tools/JSLitmus/tests/loop_operators.html
View the [very short] source of the page to see the actual test code.
When running the test for yourself, be sure to uncheck the normalize box.
Also, you'll probably want to run each test a few times to make sure you're
getting consistent results (CPU load elsewhere in the OS can skew resutls).
For more on JSLitmus, readhttp://www.broofa.com/Tools/JSLitmus)
Here are the results I got on my MacBook (sorry, don't have IE results
handy)
FF:http://tinyurl.com/ykdutyk
Safari:http://tinyurl.com/yzusg7e
Opera:http://tinyurl.com/yjamzwc
Chrome:http://tinyurl.com/ylylyw5
Executive summary: On the above browsers, performance does vary. i++ or
++i are the best all-round performers, while the while() loop is generally
not as good. However on all of these systems ('cept Opera), looping code
runs so fast that performance is negligable compared to whatever code you
put inside the loop. I.e. it's unlikely to matter in all but the most
trivial of loops.
- rwk
On Wed, Dec 16, 2009 at 2:28 AM, Yaffle vic99...@yandex.ru wrote:
++i; is a little more efficient in C language,
in javascript difference in performance of all these operators is tiny
On Dec 16, 3:21 pm, RQuadling rquadl...@googlemail.com wrote:
Hi.
Is there any consensus on which is more efficient in a for() loop?
I was taught that for ++i being the most efficient.
I've created 2 patches (++ and a +1) in case anyone is interested.
http://pastie.org/private/3rgonpsn90yjd17q9zwa
andhttp://pastie.org/private/qufy3rwmaevxc1sysvq
From what I've read, this could be a little pointless, but I'm not the
expert in this area.
Regards,
Richard.
--
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
--
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
--
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
--
You received this message
[Prototype-core] Re: For() loops, ++i, i++, i+=1
Forget the CPU cycles, it's the brain cycles I want back. But it was all worth it to learn about JSLitmus. :-) On Dec 17, 3:33 pm, Bob Kerns r...@acm.org wrote: Not to be a curmudgeon about it -- I'll just point out that the CPU cycles consumed in processing the email for this discussion far exceeds the CPU cycles saved by all the code the lot of you will ever write with such tweaks. Purely entertainment / mental game play. If you want to improve performance, the mental effort would be better spent looking at your algorithm, or even better, measuring the performance to find where you need to focus your attention. I can tell you now it won't be your choice of iteration statements! Play on -- I just wanted to put it into context... -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en
[Prototype-core] Re: Support full HTML set in (un)escapeHTML
Tobie, A correct character encoding should be all you really need to handle such entities. That's rather flip, don't you think? How does character encoding choice solve quot; or nbsp;? These entities are valid HTML, regardless of character encoding. There are sometimes very good reasons for using them. It's fine to say String#unescapeHTML won't handle these because it's too big a problem and document that, but let's not just dismiss it like the person asking the question is being dumb, which is how the above comes across. -- T.J. On Nov 21, 1:10 am, Tobie Langel tobie.lan...@gmail.com wrote: Thanks for your input. A correct character encoding should be all you really need to handle such entities. Best, Tobie -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en
[Prototype-core] Re: Porting the old docs
Cheers Mike! I gave you a shout over on the user's list; didn't know you were on this one... -- T.J. :-) On Nov 17, 7:24 pm, Mike Rumble mike.rum...@gmail.com wrote: I can take some of these over the next week or so. Will make a start promptly. Mike. On Nov 16, 4:15 pm, T.J. Crowder t...@crowdersoftware.com wrote: Hey folks, I've just completely failed to find the time to port all of the old docs, which is (as a whole) a much bigger job than I thought it would be. So there are now a bunch of merge old docs tickets[1] in Lighthouse, each of which is just a bite-sized task (and has the mostly-formatted PDoc as a file attachment, courtesy of Tobie -- he wrote a script to extract and reformat the Mephisto stuff which does a lot of the work for you). That link will automatically search for them for you. I solicited help from the users in a post[2] over in the user's mailing list. [1]https://prototype.lighthouseapp.com/projects/8886-prototype/tickets?q... [2]http://groups.google.com/group/prototype-scriptaculous/browse_thread/... -- T.J. -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en
[Prototype-core] Porting the old docs
Hey folks, I've just completely failed to find the time to port all of the old docs, which is (as a whole) a much bigger job than I thought it would be. So there are now a bunch of merge old docs tickets[1] in Lighthouse, each of which is just a bite-sized task (and has the mostly-formatted PDoc as a file attachment, courtesy of Tobie -- he wrote a script to extract and reformat the Mephisto stuff which does a lot of the work for you). That link will automatically search for them for you. I solicited help from the users in a post[2] over in the user's mailing list. [1] https://prototype.lighthouseapp.com/projects/8886-prototype/tickets?q=merge+old+docs+state%3Aopen+state%3Anewfilter= [2] http://groups.google.com/group/prototype-scriptaculous/browse_thread/thread/5a03323af91f531b -- T.J. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: On Class#create
Hi,
I was wondering for the longest time why doesn't Class#create have
arguments?
Class.create does have arguments, details in the docs[1]. The
implementation doesn't use any _named_ arguments, it accesses its
arguments via the `arguments` array (on the first line of the
function, in fact).
[1] http://api.prototypejs.org/language/class.html#create-class_method
HTH,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / com
www.crowdersoftware.com
On Nov 11, 12:26 am, joneff jon...@gmail.com wrote:
I was wondering for the longest time why doesn't Class#create have
arguments?
I mean it's obviously to allow inheritance from multiple objects, but
honestly, how often does this happen?
S.. If arguments are provided, Class#create could look like
function create(parent, properties) {
if (typeof parent !== function) {
properties = parent;
parent = null;
}
... // more code
if (parent) {
subclass.prototype = parent.prototype;
klass.prototype = new subclass;
parent.subclasses.push(klass);
}
if (properties)
klass.addMethods(properties);
... // more code
}
which avoids few function calls. More over, if indeed multiple
inheritance is required it could be done in the addMethods method with
looking for special key (say implements or inheritsFrim or what ever).
However, typeof is kinda unfriendly looking to me. I don't know how
many of you are using MS Client JS, but they have an extra property
__typeName to indicate the type of object being worked with.
So if there was indeed such a mechanism in Prototype, the syntax would
become
if (!parent.__typeName || parent.__typeName != class)
It is indeed longer than the first one, but looks friendlier (to me)
and actually having an easy way to check whether or not an object is a
class seems handy (again to me).
Any thoughts?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: On Class#create
Hi, You can have as many mix-ins as you like, which is why the number of arguments is variable: ...any arguments passed are treated as objects, and their methods are copied over (mixed in) as instance methods of the new class. In cases of method name overlap, later arguments take precedence over earlier arguments.[1] Creating and instantiating a prototype class is notoriously slow. I hadn't realized that using `arguments` (as opposed to `arguments.callee`) was slow, but a quick experiment shows that you do indeed pay a performance penalty for it on some major browsers (not typically as bad as for `arguments.callee`, but pretty bad). Very interesting, thanks for that. That would indeed hit both Class.create and initialization, since initialization requires that the Prototype- generated constructor hands `arguments` to the initializer. I think the larger issue, though, with defining (creating) classes is because of Prototype's support for supercalls, which requires that it decompile every single function in the class (and all mixins) and perform regexes on each of the resulting strings -- which is not just a speed issue, but a standards issue as well. I've proposed a solution for it[2]. The same applies to instantiating: if you use a supercall in your initializer (which is quite common), you'll pay a big speed penalty for that -- each method call involving a supercall is very slow indeed, Prototype actually creates a new function on the fly for the call, every time(!). My proposal fixes that as well. [1] http://api.prototypejs.org/language/class.html#create-class_method [2] http://groups.google.com/group/prototype-core/browse_thread/thread/db9ccdaae4f7f705# Happy coding, -- T.J. On Nov 11, 12:29 pm, joneff jon...@gmail.com wrote: I have indeed noticed that. I quite often use function without named arguments and then populate what I need from the arguments collection. I was wondering why was that so. I mean creating a class does not need infinite number of arguments, now would it? In the longest case scenario it needs class name (prototype creates differently but still), parent class, own fields / method, an array of mixins to borrow methods from. So in Prototype's case, that would be three arguments. Creating and instantiating a prototype class is notoriously slow. I was looking for ways (from my point of view) how the process could be a bit faster. And I say a bit, since notoriously slow means some ticks slower. On Nov 11, 12:44 pm, T.J. Crowder t...@crowdersoftware.com wrote: Class.create does have arguments, details in the docs[1]. The implementation doesn't use any _named_ arguments, it accesses its arguments via the `arguments` array (on the first line of the function, in fact). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Class#create and throw new Error()
Hi,
The initializer is called initialize, not initialization (see the
docs[1]). Your code throwing the exception isn't being called, hence
the exception not being thrown. If you use the correct name, the
exception is thrown and correctly propagates out to the code creating
the object.
[1] http://api.prototypejs.org/language/class.html
HTH,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / com
www.crowdersoftware.com
On Nov 6, 4:23 pm, Ilya Furman smashl...@gmail.com wrote:
Hello!
I'm wondering, why class instance is being created while
initialization method throws an error?
var C = Class.create({
initialization : function() {
throw new Error('Hey, you can\'t have any instances of this
class!')
},
foo : 'foofoo' ,
bar : function() {
alert(this.foo)
}
});
var c = new C();
c.bar();
Demo linkhttp://jsbin.com/inoqi
Variable c should be 'undefined' I suppose, without any methods and
properties.
Seems like there is actually no way to stop instance from being
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
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Function.EMPTY and Function.K
Hey Andrew, Aren't all functions constants, in that sense? Function.EMPTY isn't more or less constant than Element.extend. -- T.J. ;-) On Oct 15, 1:08 am, Andrew Dupont goo...@andrewdupont.net wrote: Weighing in again, decades after starting the thread. First, I'm fine with calling it Function.IDENTITY instead of Function.K. On Sep 25, 2009, at 1:26 AM, T.J. Crowder wrote: Make sense. Shouldn't that be Function.empty and Function.k, though, to follow our naming rules? And perhaps Function.k should have a more meaningful name. I'm very much in favor of all-caps, or at least initial caps, to indicate that these are constants. We don't do this consistently in the framework so far, but I'd like it to match stuff like Event.KEY_ESC. I think the capitalization will also help distinguish it from String#empty and Array#empty, as was mentioned elsewhere. (Aside: I'm also in favor of renaming those methods to `isEmpty` for 2.0.) What do people think about the capitalization? Cheers, Andrew --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: documentation correction
Hi, On Oct 13, 7:30 pm, drewB dbats...@gmail.com wrote: On pagehttp://www.prototypejs.org/api/ajax/requestat the bottom when describing how JSON is handled it says that the JSON is evaluated and returned in the headerJSON property. It should say responseJSON. The same is true of the sample code. Thanks for that, but actually, it's correct. That section is talking about the X-JSON header (Some backends will return JSON not as response text, but in the X-JSON header...). The X-JSON header is deserialized and made available as headerJSON. So you can return HTML (for instance) along with a bit of JSON in a header. You're thinking of when the main content comes back as application/json, in which case it is indeed available as responseJSON. HTH, -- T.J. Crowder Independent Software Consultant tj / crowder software / com www.crowdersoftware.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: Prototype.Compatibility (was Units of Measurement...)
Hi Robert, It's a cool idea, but the complexity starts getting explosive (particularly for unit testing). If 2.0 is going to have substantial API changes (and I think it is -- Element wrappers, for one), I'd say we should save up the list of things that -- like Joran's units thing, Enumerable.includes vs. Enumerable.include -- probably should change, and then do them wholescale at that point. My two pence... -- T.J. :-) On Oct 10, 4:36 pm, Robert Kieffer bro...@gmail.com wrote: I'd like to get everyone's opinion on an idea for simplifying the backward compatibility issues in Prototype. This comes in reaction to Joran Greef's suggestion that the Prototype API should standardize on milliseconds as the unit of time passed to methods like Function#delay () (which currently take seconds): http://groups.google.com/group/prototype-core/browse_thread/thread/54... Joran's arguments have merit, but as T.J., says I don't see changing ... barring a wholescale Prototype API rewrite. This position is understandable, given how much upheaval API changes cause in the Prototype community nowadays. But, boy, it sure would be nice if there were a good compromise! To address this issue, I propose adding a Prototype.Compatibility property. It is similar to Prototype.Version, but has a semantic of, the desired version of compatibility. By default, this would be set to the current version: Prototype.Compatibility = Prototype.Version; Users could set this after importing Prototype to control the behavior of any API that honored this setting. E.g. To indicate you would like compatibility with version 1.6 (to the extent possible), you would do this: Prototype.Compatibility = 1.6; Internally, methods like delay() could be tweaked to honor this as follows: // Old code: // timeout = timeout * 1000 // New code: timeout *= (Prototype.Compatibility 2.0 ? 1000 : 1;) Please note that I'm being very careful not to imply that Prototype 2.0 should have a way to achieve across-the-board compatibility with 1.6. Rather, I'm saying only that there are certain cases where supporting this property is trivial, and this has the dual benefit of making it easier to clean up and evolve the Prototype API, while minimizing compatibility issues for users that upgrade. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Units Of Measurement Options Stated Using Lowest Common Denominator Unit Practical
I, for one, found the units used by Function#delay (for example) to be very surprising when I first saw them, and I have to stop and think every time I use Function#delay. The usual unit for that sort of thing in every language I've worked in other than BASIC is milliseconds. That said, I don't see changing them barring a wholescale Prototype API rewrite. -- T.J. On Oct 9, 2:39 pm, Allen Madsen bla...@gmail.com wrote: Joran, The type of number extensions you described aren't part of prototype. Therefore, it is simpler for developers who aren't using such an extension to use seconds. I'm not opposed to the switch, but I wanted to throw out a possible explanation for the way it is today. Allen Madsenhttp://www.allenmadsen.com On Fri, Oct 9, 2009 at 9:18 AM, Joran Greef jorangr...@gmail.com wrote: I've been using some Number extensions of my own for some time: Number.seconds, Number.minutes, Number.hours etc. where (2).minutes() would return the 2 minutes expressed as milliseconds e.g. 12, (2).seconds() would return 2000 etc. It's been great for defining config files e.g.: Config.Database.recentThreshold = (2).minutes(); Config.Http.timeout = (60).seconds(); I think Rails does the same and that may be where I got the idea from. I've also added Number.kilobytes, Number.megabytes, etc. It would be great if interfaces which receive a time or quantity value as an option, such as PeriodicalExecuter, could expect the value to be expressed in the lowest common denominator unit practical, i.e. milliseconds rather than seconds. Java does it, and so does Javascript's own setInterval, setTimeout etc. It would follow the principle of least surprise and make units of measurement easier to compare. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Event#element deprecated?
Hi Tobie, Event#element has been deprecated for the longest time. Where? Certainly not in the old API docs: http://prototypejs.org/api/event/element My point isn't to disagree about doing it, but that as far as the typical user knows, this is a brand-new decision. -- T.J. On Oct 7, 8:08 pm, Tobie Langel tobie.lan...@gmail.com wrote: Event#element has been deprecated for the longest time. It's by no means a new decision. Best, Tobie On Oct 7, 8:05 pm, kangax kan...@gmail.com wrote: On Oct 7, 12:34 pm, Tobie Langel tobie.lan...@gmail.com wrote: Sorry, but I don't follow the logic. What stops us from using `getElement` with optional selector? That meant adding another method. We had chosen to avoid that. (Remember Event#findElement already existed). We can add it in 2.0 which doesn't confine us much to existing API. [...] Even better would be to replace both - `element()` and `findElement()` with `getTarget()` which would accept optional selector. It's shorter and conveys intention better; it actually describes that it is event's *target* that we are retrieving here, not just some vague *element*. I think Event#getTarget is ambiguous too, as we don't return the target node but the first node above it that's an Element. Ok, that makes sense. I would then still go with `getElement`, rather than `findElement` (if we are introducing it in backwards-incompatible 2.0). What do you think? As I said in my previous comment, worth discussing in the context of Sam's upcoming work on Element#on. Could you expand on this? What's the idea behind Element#on? FWIW, I'm not particularly sold on the name of Event#findElement myself, but it happened to be already part of the API. Does `getElement()` sound like a good replacement for `element()` and `findElement()`? Still, if we have a chance to change name to something more descriptive in upcoming 2.0, what's the point of deprecating `element` at this point? First, people will start using `findElement` instead of `element()`, and then they'll be forced to switch to other name again (I'm assuming there will be another name, since `findElement` doesn't seem like the best we can come up with). Or am I missing something? It made sense to extend it for the reasons I explained above. And it's unquestionably much better than Event#element. Agreed. `element()` didn't quite follow convention. -- kangax --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Event#element deprecated?
I had no idea it's deprecated. Isn't it a bit weird to use `findElement` without arguments to get target element? Especially as all it does is call Event#element (in that case). Yes, I find that a bit weird. -- T.J. On Oct 5, 6:45 pm, kangax kan...@gmail.com wrote: On Oct 5, 11:55 am, Ngan nganp...@gmail.com wrote: Hi everyone, In the new docs, it says that Event#element is deprecated. Is there a reason for this? The doc says to use Event#findElement instead. I had no idea it's deprecated. Isn't it a bit weird to use `findElement` without arguments to get target element? [...] -- kangax --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
I'm with Robert, is there a good use case for these or should we just deprecate them? But if we're going to get into renaming things, Enumerable#include is crying out for an s on the end (if this thing include*s* this other thing then...); without one it seems to say include this argument in the enumerable -- e.g., add. -- T.J. :-) On Oct 3, 3:24 pm, Robert Kieffer bro...@gmail.com wrote: Quick reality check: Where is the value in String/Array functions that test for emptiness? 'These methods are nothing more than wrappers around code like, if (!aString) ..., or if (!anArray.length) ... - i.e. JS already has perfectly good constructs for this. It's great that Prototype is inspired by Ruby, but much of it's charm is due to the fact it's done a good job of avoiding the pitfall of providing lots of syntactic sugar for people that don't know JS. (Nevermind that Array#empty() would seem to be synonomous with ! Array#any(), btw) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Function.EMPTY and Function.K
Being serious for a moment, it sounds like we're all happy (enough)
with Function.empty.
Can't say I *like* Function.identity (I'd prefer Function.passBack)
but it at least is readily defensible as being derived from
mathematics (like curry) and there are several yea vote for it in
this thread.
-- T.J. :-)
On Sep 29, 8:58 am, Jim Higson j...@wikizzle.org wrote:
On Tuesday 29 September 2009 06:49:15 Joran Greef wrote:
Prototype's existing String.empty and Array.empty interfaces would
imply that Function.empty return a boolean indicating perhaps that the
function is empty.
Well, it *could* do:
Function.empty = function(){};
Function.empty.empty = function(){return true};
Of course this doesn't cover other empty functions and I may be not entirely
serious ;-)
Jim
--
Jim
my wiki ajaxification thing:http://wikizzle.org
my blog:http://jimhigson.blogspot.com/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Function.EMPTY and Function.K
Andrew, Make sense. Shouldn't that be Function.empty and Function.k, though, to follow our naming rules? And perhaps Function.k should have a more meaningful name. -- T.J. On Sep 25, 4:20 am, Andrew Dupont goo...@andrewdupont.net wrote: Unless anyone has serious objections, or has a better idea, I'm going to add these as aliases of `Prototype.emptyFunction` and `Prototype.K`, respectively. They belong better there, since in theory the `Prototype` namespace is for internal stuff, not for stuff that has value to end-user developers. Cheers, Andrew --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: bug report - sorry, I didn't find the other way to report bugs in prototype.js
Hi,
I didn't find the other way to report bugs in prototype.js
It's described here:
http://prototypejs.org/contribute
i am quite sure it was supposed to be:
if (!responders) return element;
Indeed. Well-spotted!
--
T.J. Crowder
tj / crowder software / com
www.crowdersoftware.com
On Sep 25, 1:36 pm, Rafał Michalski royalt...@gmail.com wrote:
prototype.js - 1.6.1
I think there is a bug in function stopObserving
on line: 4571 there is:
if (!responders) return;
i am quite sure it was supposed to be:
if (!responders) return element;
Because it destroys chaining, I'v had in my code:
document.stopObserving('mousemove', somefunction).stopObserving
('mouseup', someotherfunction)
because there were no 'mousemove' handler the stopObserving returned
undefined instead of element
That is not what stopObserving is supposed to return.
Kind regards,
Rafał Michalski
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Function.EMPTY and Function.K
We could _so_ overcomplicate this... ;-) On Sep 25, 1:29 pm, Jim Higson j...@wikizzle.org wrote: On Friday 25 September 2009 13:08:57 Rick Waldron wrote: On the subject of end developer confusion, I'd like to make a suggestion regarding the naming... Function.emptyFn Function.returnFn Because they say exactly what they are. This is how I've named (almost... $.function.emptyFn() and $.function.returnFn() ) the exact same functionality in the Pollen.JS library (for use within a new Worker() ) I'd say returnFn sounds like a function which returns a function. -- Jim my wiki ajaxification thing:http://wikizzle.org my blog:http://jimhigson.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Function.EMPTY and Function.K
Well, technically they aren't part of the API because the Prototype namespace isn't public (in theory), but: +1 to the new ones +1 to deprecating and ultimately removing the old ones -- T.J. On Sep 25, 3:11 pm, Robert Kieffer bro...@gmail.com wrote: Function.empty and Function.identity get my vote. However, does this mean Prototype.EMPTY and Prototype.K are being deprecated? I ask because I generally dislike aliases in APIs. Unless they are used as part of the deprecation process, they are usually more trouble than they're worth. They make code harder to read and share, developers get into silly quibbles as to which is better, etc. In short, they're annoying - it's better if the framework developers make it clear what the preferred name is, and eventually deprecate the non-preferred ones. My $.02. - rwk On Fri, Sep 25, 2009 at 6:19 AM, T.J. Crowder t...@crowdersoftware.comwrote: We could _so_ overcomplicate this... ;-) On Sep 25, 1:29 pm, Jim Higson j...@wikizzle.org wrote: On Friday 25 September 2009 13:08:57 Rick Waldron wrote: On the subject of end developer confusion, I'd like to make a suggestion regarding the naming... Function.emptyFn Function.returnFn Because they say exactly what they are. This is how I've named (almost... $.function.emptyFn() and $.function.returnFn() ) the exact same functionality in the Pollen.JS library (for use within a new Worker() ) I'd say returnFn sounds like a function which returns a function. -- Jim my wiki ajaxification thing:http://wikizzle.org my blog:http://jimhigson.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] FYI - Group Maintenance
Hi all, We've started moderating messages from new users in this group, the same way we do over in the user's group. (I volunteered and Tobie made me an admin.) Hopefully that means we'll largely stop seeing spam make it through. For my part, I'll also reply privately to people posting usage questions (rather than sending them through), directing them to the user's group instead. I've also given this group a minimal welcome message. -- T.J. Crowder tj / crowder software / com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: lastDescendant
Hi, These sorts of questions are best asked in the users mailing list.[1] This list is for core development. (And no, you don't need to extend the element, Element#descendants extends the elements before giving them to you.) [1] http://groups.google.com/group/prototype-scriptaculous -- T.J. Crowder tj / crowder software / com www.crowdersoftware.com On Sep 18, 3:32 pm, Max Felker felk...@gmail.com wrote: Way cleaner! Thank you for the precise code :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: True Hashes using objects as keys
@Samuel:
I've been working on this too and had quite reasonable performance
I like it, _should_ perform a *lot* better than a straight array given
a reasonable distribution of keys. This is similar to what Java's
HashMap does (not that I'm holding it up as a model of high
performance).
@Jim:
Yep, this is Java-esque but that doesn't *always* equal evil!
Hardly ever! I'd say hashCode has a place.
Let's step back and ask the question: What are the use cases for a
hash keyed by non-string objects? Are they compelling? (I'm not
saying they aren't, just saying that before running off on an idea, we
need to ask the question.)
-- T.J. :-)
On Sep 11, 11:07 am, Jim Higson j...@wikizzle.org wrote:
On Friday 11 September 2009 10:39:14 Samuel Lebeau wrote:
Hi,
I think it's indeed a good feature to discuss for 2.0.
I've been working on this too and had quite reasonable performance
when using a hash function that avoids collision.
The simplest implementation consists in storing array of [key, value]
tuples indexed by `key.toString()` in a vanilla object.
i.e. :
hash.set(true, value1);
hash.set(true, value2);
is stored as:
{ true: [ [true, value1], [true, value2] ] }
Custom classes should override their `toString` method to be
efficiently stored in such a structure, otherwise fetching a value
would be as slow as a `Array#find` call.
Having real hashes allows to implement sets too.
Would it be reasonable to to look for a hashcode() method which, if present,
is used in preference to toString()? In most cases I could write a hashcode
implementation that runs faster and is more evenly distributed than a human-
readable toString.
Yep, this is Java-esque but that doesn't *always* equal evil!
--
Jim
my wiki ajaxification thing:http://wikizzle.org
my blog:http://jimhigson.blogspot.com/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Private methods for prototype class
Hi Ngan,
This question is probably more appropriate for the user's group[1],
rather than the core development group. If you'll repost over there,
there are a couple of things to point out in that stuff...
[1] http://groups.google.com/group/prototype-scriptaculous
--
T.J. Crowder
tj / crowder software / com
www.crowdersoftware.com
On Sep 10, 5:39 pm, Ngan nganp...@gmail.com wrote:
opps, i had typo. return should be:
return {
initialize: initialize,
publicMethod: publicMethod
}
On Sep 10, 9:37 am, Ngan nganp...@gmail.com wrote:
Hi, I apologize if this question has been asked before. I've tried
googling for this, but did find a good answer.
What's the best way to have private methods using prototype's
Class.create?
I've tried...
var Worker = Class.create((function() {
function initialize() {
this.someVar = var;
privateMethod();
}
function publicMethod() {
privateMethod();
}
function privateMethod() {
console.info(this.someVar);
console.info(this)
}
return {
initialize: initialize
};
})());
Running this will give me:
console.info(this.someVar) #= undefined
console.info(this.someVar) #= DOMWindow
However:
aWorker = new Worker();
aWorker.publicMethod() #= WORKS!
Thank you for your time!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: True Hashes using objects as keys
Hi James, You're right, Hash does indeed rely on underlying JavaScript vanilla objects, which can only use strings as keys. Supporting using objects as keys would be a complete rewrite, and a fairly inefficient one in terms of runtime performance (I did it once, and abandoned it as not worthwhile). I'm not aware of any plans to do so. I suspect you'd be better off (from a performance standpoint) building toString / fromString support into your keys. FWIW, -- T.J. Crowder tj / crowder software / com www.crowdersoftware.com On Sep 10, 7:07 pm, James Aimonetti james.aimone...@gmail.com wrote: Core, Wanted to ask about why Hash doesn't support Objects as keys? I believe it relies on Javascript using the toString on the object to set the key's value, rather than a true hash. var key1 = new Object(); var key2 = new Object(); var h = $H(); h.set(key1, First); h.set(key2, Second); h.get(key1) // - Second Is there any plan to support true object-as-key ability? I couldn't find discussion on the topic searching the group. -- James Aimonetti mobile: 314.809.6307 work: 540.459.2220 email: james.aimone...@gmail.com website:http://jamesaimonetti.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Possible bug when adding additional element methods in IE8
Hi,
Prototype 1.6.1 is the first version to support IE8. Are you seeing
this in the current release, or...?
-- T.J.
On Sep 10, 7:25 pm, Viktor Kojouharov vkojouha...@gmail.com wrote:
actually, looking at this further, I needed to add this line to my
Element function:
if (element) global.Element.prototype = element.prototype;
it looks like it was added recently in prototype as well, maybe for
IE8 specifically.
On Sep 10, 9:09 pm, Viktor Kojouharov vkojouha...@gmail.com wrote:
actually, while creating the test, I started cutting unrelated parts
from my included scripts, and once I removed my overwrite of the
Element function (which was overwritten between the two method
additions), the second set of methods were defined.
My overwrite is this, in case anyone is interested in to why it was
causing problems with IE8 and addMethods alone:
if (Prototype.Browser.IE)
(function() {
var element = this.Element;
this.Element = function(tagName, attributes) {
attributes = attributes || { };
tagName = tagName.toLowerCase();
var cache = Element.cache;
if (Prototype.Browser.IE) {
var attributeString = '';
for (var key in attributes) {
if (typeof attributes[key] == 'string') {
var name = key == 'className' ? 'class' : key ==
'htmlFor' ? 'for' : key;
attributeString += name + '=' + attributes[key] + '';
delete attributes[key];
}
}
tagName = '' + tagName + ' ' + attributeString + '';
return Element.writeAttribute(document.createElement(tagName),
attributes);
}
if (!cache[tagName]) cache[tagName] = Element.extend
(document.createElement(tagName));
return Element.writeAttribute(cache[tagName].cloneNode(false),
attributes);
};
Object.extend(this.Element, element || { });
}).call(window);
^ the above is written to achieve this: new Element('div',
{onclick:alert(1)}), or adding string callbacks when creating an
element (which I need). I will just make this function exists in IE6
7, but not 8 for now, unless someone can tell me what exactly is
causing this.
If someone wants to, I can still attach a simple test for this.
On Sep 10, 4:07 pm, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Viktor,
Could you put together a small, self-contained test case that
demonstrates what you're seeing and open a ticket in Lighthouse with
it?[1]
[1]http://prototypejs.org/contribute
Thanks in advance,
--
T.J. Crowder
tj / crowder software / comwww.crowdersoftware.com
On Sep 10, 11:56 am, Viktor Kojouharov vkojouha...@gmail.com wrote:
Hello,
I'm getting a rather weird error in IE8 specifically (not in IE7 or
IE6). In two places I add additional element methods using
Element.addMethods. The first time this is done, the added methods
appear as Element.someMethod and $(element).someMethod. However, the
second time additional methods are added, these methods appear only as
Element.someMethod2. $(element).someMethod2 is undefined in that case.
Not sure what's going on here, but as my code appears valid in all
other browsers I tested it in (the other IEs, FF, Chrome), my guess is
that there's something wrong with proto 1.6.1. In addition, I did not
exhibit this behaviour with 1.6.0.3
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: A more efficient $super for Prototype 2
Hi all, I thought of a wrinkle today: Mixins. This new mechanism modifies function instances if they override base class functions (it leaves them alone if they don't). So if you mix in something that has a function with the same name as a parent class's function, we will set a $super property on the mixin function's instance. That seems wrong to me, mixins should be read-only as far as the mechanism is concerned, IMHO. Now, in _practical_ terms, unless the mixin function calls $super (which seems an odd thing for a mixin to do, but I can come up with an edge case use case for it), it doesn't matter much. But if A) the mixin function does (presumably optionally) call $super, and B) more than one class mixes the mixin in, AND C) the mixin overrides one of the functions in at least one of those classes, you get class crosstalk -- a very bad thing. My first thought for how to deal with this was stupid and I'll spare you. My *second* (hopefully not stupid) thought was to mark mixin functions with a property telling us to leave them alone. I see two ramifications to doing that: 1. An API change: To define a mixin, you'd ideally want to run it through something (something we'd presumably provide) that spins through and marks the functions so we leave them alone. var MyMixIn = Class.createMixin(...); 2. Mixins can't even optionally participate in supercalls, which they can with the current mechanism. Now, for me, #2 is not a problem. I'm not thrilled about introducing #1, although really you only have to do that to protect against an edge case you're probably not going to run into. It's someting a library of mixins would want to be sure to do, but within a non- library project, not sure it really matters. -- T.J. On Sep 9, 9:28 am, Jim Higson j...@wikizzle.org wrote: On Wednesday 09 September 2009 09:02:28 Jim Higson wrote: I see where you're coming from, but FWIW I'm with Allen on this one. Also, there's no standard way to get the name of a function until ECMAScript5 (which standardizes the truly outrageous idea that function instances should have -- gasp! -- a name property), and at the moment although Firefox 3.5, Chrome 2, and Safari 4 all already have that property, IE7 (at least, haven't tested IE8) and Opera10 do not. I have a hunch we could get function names in the same way that we implement Function#argumentNames. A regex on the toString. I should have looked first - this is function decompilation and considered a bad thing. -- Jim my wiki ajaxification thing:http://wikizzle.org my blog:http://jimhigson.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: A more efficient $super for Prototype 2
Hi Allen, Thanks. I agree, it's a very edgy edge case. :-) (wouldn't the current let you do this as well?) Actually, it works in the current implementation, because if a mixin function uses $super (which again is a bit odd), addMethods wraps it up in a closure and never modifies the actual function. The closure is specific to the subclass, and so it all Just Works. -- T.J. On Sep 9, 3:31 pm, Allen Madsen bla...@gmail.com wrote: TJ, I don't particularly think this is a problem or even a new problem (wouldn't the current let you do this as well?). This sounds like protecting the developer from themselves. I think as long as you sufficiently state what will happen in a particular instance then it is perfectly reasonable to allow each individual developer to handle it as they see fit. Allen Madsenhttp://www.allenmadsen.com On Wed, Sep 9, 2009 at 7:29 AM, T.J. Crowdert...@crowdersoftware.com wrote: Hi all, I thought of a wrinkle today: Mixins. This new mechanism modifies function instances if they override base class functions (it leaves them alone if they don't). So if you mix in something that has a function with the same name as a parent class's function, we will set a $super property on the mixin function's instance. That seems wrong to me, mixins should be read-only as far as the mechanism is concerned, IMHO. Now, in _practical_ terms, unless the mixin function calls $super (which seems an odd thing for a mixin to do, but I can come up with an edge case use case for it), it doesn't matter much. But if A) the mixin function does (presumably optionally) call $super, and B) more than one class mixes the mixin in, AND C) the mixin overrides one of the functions in at least one of those classes, you get class crosstalk -- a very bad thing. My first thought for how to deal with this was stupid and I'll spare you. My *second* (hopefully not stupid) thought was to mark mixin functions with a property telling us to leave them alone. I see two ramifications to doing that: 1. An API change: To define a mixin, you'd ideally want to run it through something (something we'd presumably provide) that spins through and marks the functions so we leave them alone. var MyMixIn = Class.createMixin(...); 2. Mixins can't even optionally participate in supercalls, which they can with the current mechanism. Now, for me, #2 is not a problem. I'm not thrilled about introducing #1, although really you only have to do that to protect against an edge case you're probably not going to run into. It's someting a library of mixins would want to be sure to do, but within a non- library project, not sure it really matters. -- T.J. On Sep 9, 9:28 am, Jim Higson j...@wikizzle.org wrote: On Wednesday 09 September 2009 09:02:28 Jim Higson wrote: I see where you're coming from, but FWIW I'm with Allen on this one. Also, there's no standard way to get the name of a function until ECMAScript5 (which standardizes the truly outrageous idea that function instances should have -- gasp! -- a name property), and at the moment although Firefox 3.5, Chrome 2, and Safari 4 all already have that property, IE7 (at least, haven't tested IE8) and Opera10 do not. I have a hunch we could get function names in the same way that we implement Function#argumentNames. A regex on the toString. I should have looked first - this is function decompilation and considered a bad thing. -- Jim my wiki ajaxification thing:http://wikizzle.org my blog:http://jimhigson.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: A more efficient $super for Prototype 2
Hi Robert,
That's a very interesting use case, thanks for that. I can certainly
see the utility of that, and in fact as I was writing all of this up
for my (pathetic little) blog I was getting increasingly uncomfortable
with the mixin issue.
If it's important for mixins to participate in hierarchy, it occurs to
me that my second point (saying they can't) is unduly pessimistic. Of
course they can. Unlike subclass methods, it's important that we
don't modify them directly, but that doesn't mean they can't play. In
this one special case where we basically have no choice, we can allow
ourselves the indirection and wrap them, modifying the wrapper rather
than the original. That costs a closure per mixin method (not on
every call, just at mixin-time), and then an extra #apply on each
mixin call. Still much more efficient than what we currently have,
and it keeps mixins fully able to participate in the hierarchy.
That's much more satisfying that shutting them out (and potentially
breaking the chain).
Thanks again,
-- T.J.
On Sep 9, 4:00 pm, Robert Kieffer bro...@gmail.com wrote:
I'm with Allen on this. I don't think it's uncommon for mixins to want to
hook into existing functionality. This is trivial if they can invoke $super
(the original object's method), and problematic otherwise.
To give a concrete example, a while ago I implemented a Selectable mixin
for some collection classes. Because this mixin maintained the selection
state in a private cache, it needed to hook into the remove() method to
allow it to properly update the cache. Thus, I could easily see doing
something like this:
var Selectable = Class.createMixin({
// Various methods we add to the collection class...
selectItem: function(item){...},
deselectItem:function(item){...},
getSelectedItems: function() {...},
// Make sure we deselect items before they're removed
remove: function($super, item) {
this.deselectItem(item);
$super(item);
}
})
On Wed, Sep 9, 2009 at 7:31 AM, Allen Madsen bla...@gmail.com wrote:
TJ,
I don't particularly think this is a problem or even a new problem
(wouldn't the current let you do this as well?). This sounds like
protecting the developer from themselves. I think as long as you
sufficiently state what will happen in a particular instance then it
is perfectly reasonable to allow each individual developer to handle
it as they see fit.
Allen Madsen
http://www.allenmadsen.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: A more efficient $super for Prototype 2
Hi Jim,
Perhaps I would do:
var B = Class.create(A, {
nifty: function(){
var $super = this.nifty.$super.bind( this );
// $super refers to A.nifty() bound to this
$super();
}
});
[1] Please correct if this is wrong!
You need to leave out the this. and use a named function instead;
see my note to Allen for the details. You can use #bind if you want
to, but in my experience you're typically only making a single call to
the superclass method, so it's not really worth the overhead. But
here's what it would look like:
var B = Class.create(A, (function(){
function nifty(){
var $super = nifty.$super.bind( this );
// $super refers to A.nifty() bound to this
$super();
}
return {nifty: nifty};
})());
-- T.J.
On Sep 8, 8:52 am, Jim Higson j...@wikizzle.org wrote:
On Tuesday 08 September 2009 03:57:13 Allen Madsen wrote:
TJ,
I guess I don't understand why it wouldn't work. I'll illustrate how I
understand it and you correct me where I'm wrong.
var A = Class.create({
nifty: function(){}
});
var B = Class.create(A, {
nifty: function(){
this.nifty.$super(); // refers to A.nifty()
//this.nifty(); //would cause recursion
}
});
Wouldn't you have to do this to preserve scope?
this.nifty.$super.call( this );
Myself, I've never liked the .call syntax much because I mistake it with
apply: the two words seem arbitrary. But, yeah, I can see that pre-binding
every overridden method of every object would be a big overhead.
Perhaps I would do:
var B = Class.create(A, {
nifty: function(){
var $super = this.nifty.$super.bind( this );
// $super refers to A.nifty() bound to this
$super();
}
});
[1] Please correct if this is wrong!
--
Jim
my wiki ajaxification thing:http://wikizzle.org
my blog:http://jimhigson.blogspot.com/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: A more efficient $super for Prototype 2
Hi, It really looks nicer :) Thanks! I haven't run it but I guest it is possible to do this.method.$super.call(this, ...) No, you need to drop the this. from the beginning of that. See my reply to Allen a couple up (or the PDoc comments here[1]) for why. arguments.callee.$supper.call(this, ...) Yup, that works (assuming $super rather than $supper), although it's a lot slower than using the function name. It's still markedly faster than the current mechanism. -- T.J. :-) On Sep 8, 11:20 am, Radoslav Stankov rstan...@gmail.com wrote: It really looks nicer :) I was generally using this.constructor ... and so on. But this is better. I haven't run it but I guest it is possible to do this.method.$super.call(this, ...) arguments.callee.$supper.call(this, ...) Witch is nice. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: A more efficient $super for Prototype 2
Hi Richard, You want to use the supercalls branch; I suspect you used master. This should do it: git clone git://github.com/tjcrowder/prototype.git git checkout supercalls rake dist In any case, I see you got there in the end. A bit short Half a million loops and it's a bit short Heh heh heh. Yeah, well, we wouldn't want to jump to conclusions based on insufficient test data. :-) I have it print that out if the total test time was less than 15 seconds. Only a 15X improvement on Chrome, eh? I've seen it even higher than that... -- T.J. :-) On Sep 8, 11:32 am, Richard Quadling rquadl...@googlemail.com wrote: 2009/9/8 T.J. Crowder t...@crowdersoftware.com: Hi, It really looks nicer :) Thanks! I haven't run it but I guest it is possible to do this.method.$super.call(this, ...) No, you need to drop the this. from the beginning of that. See my reply to Allen a couple up (or the PDoc comments here[1]) for why. arguments.callee.$supper.call(this, ...) Yup, that works (assuming $super rather than $supper), although it's a lot slower than using the function name. It's still markedly faster than the current mechanism. -- T.J. :-) On Sep 8, 11:20 am, Radoslav Stankov rstan...@gmail.com wrote: It really looks nicer :) I was generally using this.constructor ... and so on. But this is better. I haven't run it but I guest it is possible to do this.method.$super.call(this, ...) arguments.callee.$supper.call(this, ...) Witch is nice. In the end I downloaded the archive and used src to rebuild a new prototype. Chrome... test loops: 50 Old mechanism time: 9666ms New mechanism time: 639ms *** The test was a bit short, the timing data may be suspect; try more loops. Improvement: 93.39%, e.g., old takes 15.13 times as long as new. A bit short Half a million loops and it's a bit short -- - Richard Quadling Standing on the shoulders of some very clever giants! EE :http://www.experts-exchange.com/M_248814.html Zend Certified Engineer :http://zend.com/zce.php?c=ZEND002498r=213474731 ZOPA :http://uk.zopa.com/member/RQuadling --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: A more efficient $super for Prototype 2
Hi all,
Just validated Radoslav's steps, and they work (provided you add the
submodules stuff), although it takes a while because you have to
retrieve everything (including submodules). Instead, it's really easy
and very fast to just add my repo as a remote within your existing
local prototype repo, and the pull the supercalls stuff into a branch:
1. Get into your local prototype repo
2. Add mine as a remote source:
git remote add tjcrowder git://github.com/tjcrowder/prototype.git
3. Create and switch to a local supercalls branch
git branch supercalls
git checkout supercalls
4. Pull my stuff into it:
git pull tjcrowder supercalls
5. Build
rake dist
6. Profit!
Alternately, here's[1] a pre-baked copy for anyone who just wants to
grab it and play around, but of course it will go stale fairly
quickly.
[1] http://gist.github.com/182838
-- T.J.
On Sep 8, 1:15 pm, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Radoslav,
There must be a smarter way with this, but I'm still a git newbie.
Hey, you're better at it than I am. :-)
Bw, this worked fine, since $super is attached to function
It only worked because you only had a Parent Child hierarchy. As
soon as you throw a third level into it (the grandchild test), e.g.
Parent Child GrandChild, if any of the middle layers (Child, in
this case) tries to do a supercall, it will *endlessly recurse*.
Really. Again, please read my reply to Allen above[1] for details.
[1]http://groups.google.com/group/prototype-core/browse_thread/thread/db...
-- T.J.
On Sep 8, 1:03 pm, Radoslav Stankov rstan...@gmail.com wrote:
git pull origin supercalls is needed for getting not only the master
branch. So we have:
git clone git://github.com/tjcrowder/prototype.git
cd prototype
git branch supercalls
git checkout supercalls
git pull origin supercalls
rake dist
There must be a smarter way with this, but I'm still a git newbie.
Bw, this worked fine, since $super is attached to function
pre
var SuperKlass = Class.create({
update: function(){ console.log('super'); }
});
// written also as
var SuperKlass = Class.create((function(){
function update(){ console.log('super'); }
return {update: update};
})());
var SubKlass = Class.create(SuperKlass, {
update: function(){
this.update.$super.call(this);
console.log('sub');
}
});
(new SubKlass()).update()
/pre
p.s. on my MacOX Leopard, it behaves very good
Safari4:
test loops: 10
Old mechanism time: 686ms
New mechanism time: 123ms
Firefox 3.5
test loops: 10
Old mechanism time: 14868ms
New mechanism time: 442ms
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Why have the examples been stripped out of the documentation?
Thanks Joe, looks like it was just an oversight. We're in the process of fixing it. -- T.J. On Sep 8, 1:01 pm, joe t. thooke...@gmail.com wrote: +1 for restoring examples. Even as i've used the library for almost two years, i still occasionally need a refresher on some of the stuff i don't use frequently. Kudos, T.J. -joe t. On Sep 7, 6:54 am, T.J. Crowder t...@crowdersoftware.com wrote: Hi all, As some of you know, I'm running through all of our old docs and merging them into the PDoc comments in the source, and I've run into a really common theme: Where methods are already documented in the source, it's usually a copy of the original documentation with any examples left out. Why? (Brief) examples are a good thing in documentation! I'm restoring most of them, adjusting some to be a little more clear, but somebody tell me if there's some strong reason for stripping them out. -- T.J. Crowder tj / crowder software / com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: A more efficient $super for Prototype 2
@Allen,
For your two suggested additions. I don't think I have ever had a use for
either.
Thanks.
One thing I would like to suggest though is that Class.create
take an object or a function as an argument.
I _really_ like that idea, not least because it seems to me that by
reducing the *seeming* complexity it makes it much easier for relative
novices to adopt using named functions. But unfortunately it would a
further API change, because otherwise Class.create can't tell whether
the first argument is a base class constructor or a function you want
it to call to retrieve the members object:
var X = Class.create(BaseClass);
var Y = Class.create(function() {
function nifty() { ... }
return {nifty: nifty};
});
You see the problem. The API change wouldn't need to be large, it's
just suddenly we're impacting the API more than we otherwise have to,
and my gut reaction to that is usually caution (not least because
unless I caution myself, I get a bit change-happy).
None of which is meant to say A) That I'd be opposed to it if a bunch
of smart people said it was worth it (quite the opposite, in fact); or
B) That I'm not going to *immediately* steal your idea for my own
projects. :-)
FWIW, and there are 18 ways to skin this cat, but if we did anything
I'd prefer to leave Class.create alone, but I'd be really interested
in the idea of providing a new entry point (Class.define, perhaps)
that provides this new functionality and which solves the problem of
how to specify the base class in some clever way. Perhaps a new
thread for this sub-topic?
@Jim,
Ie, Class.create takes any number of objects of functions or functions. If
functions, the function name is used.
I see where you're coming from, but FWIW I'm with Allen on this one.
Also, there's no standard way to get the name of a function until
ECMAScript5 (which standardizes the truly outrageous idea that
function instances should have -- gasp! -- a name property), and at
the moment although Firefox 3.5, Chrome 2, and Safari 4 all already
have that property, IE7 (at least, haven't tested IE8) and Opera10 do
not.
-- T.J. :-)
On Sep 8, 3:27 pm, Allen Madsen bla...@gmail.com wrote:
Jim,
I like your suggestion, except that there would be no way to create private
variables and functions that could be used in more than one function. For
example, with my suggested method I could do:
Var A = Class.create(function(){
var privateVar = 0;
function privateFunction(){}
function nifty(){
privateFunction();
privateVar = 3;
}
return {nifty: nifty};
});
I'd much rather see it in this form.
Allen Madsenhttp://www.allenmadsen.com
On Tue, Sep 8, 2009 at 10:12 AM, Jim Higson j...@wikizzle.org wrote:
On Tuesday 08 September 2009 14:56:06 Allen Madsen wrote:
Hey TJ,
For your two suggested additions. I don't think I have ever had a use for
either. One thing I would like to suggest though is that Class.create
take
an object or a function as an argument. Since it is essentially a
requirement now to use a function to create named functions that can call
super (disregarding callee), it would be nice if defining that was
simplified. So something like:
var A = Class.create({
nifty: function(){}
});
var B = Class.create(A, function(){
function nifty(){
nifty.$super.call(this);
}
return {nifty: nifty};
});
How about simplifying further:
var B = Class.create( A,
function nifty(){
nifty.$super.call(this);
}
, function alsoNifty(){
this.nifty();
}
);
Ie, Class.create takes any number of objects of functions or functions. If
functions, the function name is used.
--
Jim
my wiki ajaxification thing:http://wikizzle.org
my blog:http://jimhigson.blogspot.com/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: A more efficient $super for Prototype 2
Hi Allen,
After the construction of klass, you
could set a property so that it is identifiable.
Doh! Of course, since we only allow deriving from classes created via
Class.create. I wouldn't go with name, though, since the
ECMAScript5 spec actually defines name for functions. But
_createdByPrototype would work (and echos the _extendedByPrototype
property on extended Elements)...
Gets my vote, as you say, makes the syntax much more like several
other things we do:
var Thingy = Class.create(function(){
// Define
function nifty() { ... }
function spiffy() { ... }
function keen() { ... }
// Export public methods
return {nifty: nifty, spiffy: spiffy, keen: keen};
});
...while still accepting the form where we've already been given an
object.
Nice one!
--
T.J. Crowder
tj / crowder software / com
www.crowdersoftware.com
On Sep 8, 5:00 pm, Allen Madsen bla...@gmail.com wrote:
@TJ
I don't think it would be hard to tell the difference between a base
class construct and a function. You would just need some extra work in
construction of the base class. After the construction of klass, you
could set a property so that it is identifiable. For example:
function klass() {
this.initialize.apply(this, arguments);}
if( !klass.name ) klass.name = 'klass';
Then you could do:
if(Object.isFunction(value)){
if(value.name === 'klass'){
//Do base class stuff
} else {
//Do function generator
}
}
I hope its clear where these snippets relate to the source.
Allen Madsenhttp://www.allenmadsen.com
On Tue, Sep 8, 2009 at 11:18 AM, T.J. Crowder t...@crowdersoftware.com
wrote:
@Allen,
For your two suggested additions. I don't think I have ever had a use for
either.
Thanks.
One thing I would like to suggest though is that Class.create
take an object or a function as an argument.
I _really_ like that idea, not least because it seems to me that by
reducing the *seeming* complexity it makes it much easier for relative
novices to adopt using named functions. But unfortunately it would a
further API change, because otherwise Class.create can't tell whether
the first argument is a base class constructor or a function you want
it to call to retrieve the members object:
var X = Class.create(BaseClass);
var Y = Class.create(function() {
function nifty() { ... }
return {nifty: nifty};
});
You see the problem. The API change wouldn't need to be large, it's
just suddenly we're impacting the API more than we otherwise have to,
and my gut reaction to that is usually caution (not least because
unless I caution myself, I get a bit change-happy).
None of which is meant to say A) That I'd be opposed to it if a bunch
of smart people said it was worth it (quite the opposite, in fact); or
B) That I'm not going to *immediately* steal your idea for my own
projects. :-)
FWIW, and there are 18 ways to skin this cat, but if we did anything
I'd prefer to leave Class.create alone, but I'd be really interested
in the idea of providing a new entry point (Class.define, perhaps)
that provides this new functionality and which solves the problem of
how to specify the base class in some clever way. Perhaps a new
thread for this sub-topic?
@Jim,
Ie, Class.create takes any number of objects of functions or functions. If
functions, the function name is used.
I see where you're coming from, but FWIW I'm with Allen on this one.
Also, there's no standard way to get the name of a function until
ECMAScript5 (which standardizes the truly outrageous idea that
function instances should have -- gasp! -- a name property), and at
the moment although Firefox 3.5, Chrome 2, and Safari 4 all already
have that property, IE7 (at least, haven't tested IE8) and Opera10 do
not.
-- T.J. :-)
On Sep 8, 3:27 pm, Allen Madsen bla...@gmail.com wrote:
Jim,
I like your suggestion, except that there would be no way to create
private
variables and functions that could be used in more than one function. For
example, with my suggested method I could do:
Var A = Class.create(function(){
var privateVar = 0;
function privateFunction(){}
function nifty(){
privateFunction();
privateVar = 3;
}
return {nifty: nifty};
});
I'd much rather see it in this form.
Allen Madsenhttp://www.allenmadsen.com
On Tue, Sep 8, 2009 at 10:12 AM, Jim Higson j...@wikizzle.org wrote:
On Tuesday 08 September 2009 14:56:06 Allen Madsen wrote:
Hey TJ,
For your two suggested additions. I don't think I have ever had a use
for
either. One thing I would like to suggest though is that Class.create
take
an object or a function as an argument. Since it is essentially a
requirement now to use a function to create named functions that can
call
super (disregarding callee
[Prototype-core] Re: A more efficient $super for Prototype 2
Hi Robert,
Thanks for your thoughts on this.
The requirement for named function expressions (NFEs) puts a serious
crimp in developers coding style.
This mechanism does _not_ require NFEs. You can use anonymous
functions and call the super via arguments.callee if you like, and
still get big performance improvement (and stop relying on function
decompilation, although you lose ECMA5 strict mode compliance). The
invocation syntax if you use anonymous functions is ugly enough:
var Thingy = Class.create({
nifty: function(arg) {
arguments.callee.$super.call(this, arg);
}
});
...that I would (in fact, did) suggest a helper:
var Thingy = Class.create({
nifty: function(arg) {
this.callSuper(arguments, arg);
}
});
Before I dive into details, though, can someone please tell me why
we're not looking at Dean Edwards old Base2 approach[1], or John
Resig's variation on that[2]?
We should definitely consider various options. This started because I
sort of accidentally went down a road, found what I thought was a
really nifty solution, and posted asking whether others were
interested in it.
My issue with Resig's approach would be the number of introduced
closures and the slippery _super method, which has too much magic in
it for my taste. These things are subjective. It also won't perform
as well, but we're talking a small increment, and as you say trade-
offs come into play.
I mean, come on, close your eyes, take a few deep
breaths, and then look at it...
nifty.$super.call(this, spiffy)
There are lots of constructs that look a bit alien at first. To me
this isn't one of them (and I'm no JavaScript master) but I totally
recognise that for some novices there's going to be a certain amount
of just do it like this, eventually you'll understand why. That's
true of lots of things. A novice who doesn't know about Function#call
needs to be taught about Function#call, in my view.
If we provide a helper, it could accept either 'arguments' (for
anonymous functions) or the function instance (for named fucntions),
so this:
nifty.$super.call(this, spiffy);
...could be:
this.callSuper(nifty, spiffy);
...if we think that's more helpful. The cost is an extra function
call, which compared with the various other savings we're making isn't
a big deal.
Thanks again for jumping into this,
--
T.J. Crowder
tj / crowder software / com
www.crowdersoftware.com
On Sep 8, 4:11 pm, Robert Kieffer bro...@gmail.com wrote:
I still have some serious reservations about this patch.
Before I dive into details, though, can someone please tell me why
we're not looking at Dean Edwards old Base2 approach[1], or John
Resig's variation on that[2]? That general approach would seem to
offer a good trade-off between performance and usability.
... and it's that trade-off I have reservations about. If Prototype
is going to replace the current $super technique, it's this tradeoff
that I would like to see a nice balance on. And with all respect to
you, T.J., I don't think your solution has that. There's no question
it is more performant (woot!), but I have serious doubts about it's
overall usability.
The requirement for named function expressions (NFEs) puts a serious
crimp in developers coding style. Having to declare the functions in
one section and then wrap them up in a returned data structure in
another... It's nice that this style works for Prototype, and I
appreciate the advantages, but it's not exactly commonplace (not that
anything is). It'll definitely give more than one developer pause.
Can I politely suggest that maybe you guys are a bit too close to the
code and are taking the learning curve here for granted?
And having to explicitly type the name of each function 3-4 times to
define it will very quickly get tiresome. It makes writing code
harder, and it makes refactoring it harder as well. Which means more
prone to error; there is still no IDE that is able to automatically
and accurately change the name of functions when declared like this.
With all the drum-beating around here about code maintainability, I'm
a little surprised to see this issue treated so lightly.
Most importantly, the syntax for invoking a supermethod, while not
quite as horrid as some others we've seen and discussed, is still not
that great. I mean, come on, close your eyes, take a few deep
breaths, and then look at it...
nifty.$super.call(this, spiffy)
... .vs. the current style:
$super(spiffy)
... or what the Dean Edwards/John Resig style:
this._super(spiffy)
I know, I know, the current style has performance issues. But for a
lot of developers a simpler, less confusing syntax will trump that. I
suspect most will continue to use the old $super scheme, which will
make it much harder to deprecate than you might expect. And if the
old $super scheme is gonna stick around for a while because
[Prototype-core] Re: A more efficient $super for Prototype 2
Hi Robert, arguments.callee.$super.call(this, arg); this.callSuper(arguments, arg); six of one, half-dozen of the other... Um, this.callSuper(arguments, arg) (or this.callSuper(nifty, arg)) is precisely *one* argument more than Resig's this._super(arg), but without the cost of the closures and unnecessary, misleading (IMV) magic. It's a lot clearer than the raw syntax needed with anonymous functions. Six of one, half-dozen of the other seems a bit harsh. Honestly, at this point I'm mostly worried that that we may get enamored with a solution that is different, but not necessarily all that much better. More performant, yes, but at the cost of usability... That's interesting. I started down this road precisely because I found the existing API flawed; the performance and compliance aspects came later. I'm not at all interested in replacing things without a compelling reason, we all have better things to do. I'm tempted, even, to argue for the removal of supermethod invocation altogether in Prototype. FWIW, I think that would be a mistake (but then, I use supercalls and had a concrete reason for going down this path). Not only because it's a useful feature, but also because it's one of the things people of a certain background look for in a JavaScript library. I didn't realize you'd done a crappy performance in supercalls thrread (I was away from this group for a while). I'd seen the excellent work you did with curried and bound functions, though, and I'm glad to hear that will be finding its way into 1.6.1. -- T.J. :-) On Sep 8, 7:43 pm, Robert Kieffer bro...@gmail.com wrote: On Sep 8, 8:44 am, T.J. Crowder t...@crowdersoftware.com wrote: arguments.callee.$super.call(this, arg); this.callSuper(arguments, arg); six of one, half-dozen of the other... but I suppose there is no perfect solution. Still, it's hard to swallow something this convoluted when you've gotten used to $super (or this._super() ) :-P My issue with Resig's approach would be the number of introduced closures and the slippery _super method, which has too much magic in it for my taste. These things are subjective. It also won't perform as well, but we're talking a small increment, and as you say trade- offs come into play. I have to confess it's been long enough since I looked at that code that I don't have an opinion about it. I do know that it performance tested well, and I definitely prefer the invocation syntax. Honestly, at this point I'm mostly worried that that we may get enamored with a solution that is different, but not necessarily all that much better. More performant, yes, but at the cost of usability. I'm tempted, even, to argue for the removal of supermethod invocation altogether in Prototype. It's not like it actually needs it - there are a couple places where $super is used, but it would be trivial to rewrite that to where it's not necessary. Developers would benefit from a smaller Prototype codebase, and they code pick and choose the supermethod technique that best met their needs, and import the appropriate script for that. That notion is both heretical and ironic I suppose, since I guess I started the whole look how shitty Prototype supermethod performance is! thread. But history has taught me that developers who write code without having a concrete use for it very rarely make the right choices. It's much better to let requirements drive the code choices, rather than the other way around. Okay, climbing down off my soapbox now to go get lunch. :-) - rwk --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Why have the examples been stripped out of the documentation?
Hi all, As some of you know, I'm running through all of our old docs and merging them into the PDoc comments in the source, and I've run into a really common theme: Where methods are already documented in the source, it's usually a copy of the original documentation with any examples left out. Why? (Brief) examples are a good thing in documentation! I'm restoring most of them, adjusting some to be a little more clear, but somebody tell me if there's some strong reason for stripping them out. -- T.J. Crowder tj / crowder software / com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: A more efficient $super for Prototype 2
I think you need this.nifty.$super.call(this, foo);
You don't, although that also works.
Ack! Sorry, too early in the morning, hadn't had enough coffee.
That does *not* work, because you always refer to the bottommost
subclass's nifty (this.nifty is always the bottommost function), so
you end up endlessly recursing. Wow that's an easy trap to fall into.
No, it's either use the function's name unadorned, or use
arguments.callee and pay the performance penalty. Personally, I
prefer using the function's name. :-)
-- T.J. :-)
On Sep 6, 8:48 am, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Allen,
I think you need this.nifty.$super.call(this, foo);
You don't, although that also works. A named function's name is in
scope within the function:
function foo(bar) {
alert(typeof foo); // Alerts function
}
However, I was thinking about anonymous functions this morning while
waking up (pathetic, isn't it?) and realized that even if you don't
use a named function, you can avoid arguments.callee with exactly the
form you describe: this.nifty.$super.call(this, foo); I don't like
the repetition of this, but if you don't have time to switch
everything over to named functions (I'm thinking of retrofitting
efforts), it's a reasonable first step, and I assume (haven't tested
it yet) still gets speed gains over arguments.callee.
Will be posting a sample implementation (it's wonderfully simple, but
there are a couple of edge cases around dynamic updates of classes)
and tests ASAP, but I want to get some of the Prototype documentation
issues sorted out first (transferring the old doc to the new format
and updating), since that's more urgent.
-- T.J. :-)
On Sep 5, 2:46 pm, Allen Madsen bla...@gmail.com wrote:
var Thingy = Class.create({
nifty: function nifty(foo, bar) {
nifty.$super.call(this, foo);
}
});
It just ignores the function name and complains that 'nifty' is not
defined. This works:
I think you need this.nifty.$super.call(this, foo);
Allen Madsenhttp://www.allenmadsen.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Copying arguments
Robert, You're right, this stuff is not clearly laid out anywhere, and I'm going to try to take on the task of fixing that (*after* documentation migration) if no one else is yet (I know the core guys are already aware of that issue and some work has already been done). It can be very frustrating when you're trying to contribute something to have stylistic stuff thrown up when the closest thing we have to a published style guide is four bullet points on the prototypejs.org/ contribute page. :-) And the medium (lighthouse) encouraging terseness doesn't help on the encouragement front. It _is_ important for newly contributed code to fit in (which has previously been a terrible mish-mash and which core are trying to standardize, with big gains in the 1.6.1 stuff), as I'm sure you already know. My read of the ticket and patch is that these are the outstanding requests: 1. Use argLength and origArgLength or similar descriptive argument names rather than len0, etc. 2. Include a // comment in the implementation describing the why and how of your cool idea. (// and PDoc comments are stripped by rake dist, /* ... */ are not, hence making it a // comment -- it's for other developers). Both of those are things that have not been done enough in the past and have held back progress, hence trying to move move toward them. As a Prototype user, thank you again for your efforts at improving efficiency, greatly appreciated, -- T.J. Crowder tj / crowder software / com www.crowdersoftware.com On Sep 5, 10:19 pm, Robert Kieffer bro...@gmail.com wrote: Whups, sorry about butchering your name. I'm seriously sleep deprived these days - a result of our new 5-month old kid. :-) Re: Documentation for how and why the patch works - Is that a new requirement for Prototype code? This is the first I've heard of something like this. My original post in the discussion (link above) goes into a fair bit of detail. Where does this documentation go? What is expected? Sorry, it's been a while since I looked at the prototype code base and, as of March, I thought my patch was pretty consistent with how things are done. I apologize for being so obtuse on this, but can you please elaborate on what you mean by a final, reviewed, and cleaned up patch?In re- reading the ticket, I simply don't see where the issues are. The only issue that I guess didn't get addressed was your request for more descriptive variable names... but that didn't seem to be a showstopper (nor consistently applied w/in the existing codebase). But if it makes a difference, I'm happy to do the renaming. Cheers, - rwk On Sep 5, 12:11 pm, Tobie Langel tobie.lan...@gmail.com wrote: Hi again, Robert. The patch linked by kangax certainly doesn't account for the various things we discussed back then. It notably doesn't document the reasons why and how your (very smart) implementation works. That patch also has various stylistic issues which I remember discussing and that we had all agreed to modify for a final patch. If I recall correctly, this patch just didn't make it in because a final, reviewed and cleaned up patch wasn't submitted. An unfortunate yet frequent issue with OSS. Given the amount of work that was put in this patch and the huge perf benefits it brings about, I think it makes sense to add it to an otherwise frozen 1.6.1 version provided a proper patch gets submitted. Best, Tobie Unrelated P.S.: Would appreciated not seeing my first name butchered. :-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Now that 1.6.1 is out and api.prototypejs.org is official...
Hi Joneff, It's not just you. In fact, you might notice that it was only roughly a day that the API Docs link on the main site took you to http://api.prototypejs.org; it's back to taking you to http://prototypejs.org/api again. There are several teething pains with the new docs that we're working out as we speak * The new drop-down menu is...unsuccessful * Page-per-method was popular and we're reinstating it * Context (where you are) used to be clearer and we're trying to go back to that. It'll be a work in progress, but hopefully we'll have a new and improved version of http://api.prototypejg.org up and running soon. -- T.J. Crowder tj / crowder software / com www.crowdersoftware.com On Sep 6, 9:35 pm, joneff jon...@gmail.com wrote: Is it just me, or the usability of the new API micro site isn't as good as the old one? I mean before, if I wanted to know more about Event#observe, I would just type /api/element/observe, where as the new url would be api.prototypejs.org/dom/event.html#observe-class_method which happens to be way harder. Also, the old API micro site had dedicated page for each method, where as the new one has all methods in one page. May be I am too used the way the old site was organized. What do you think? -- joneff On Sep 2, 12:25 am, T.J. Crowder t...@crowdersoftware.com wrote: ...is there a plan for putting redirects or what-have-you in place from the old API locations? E.g.,http://prototypejs.org/api/element- http://api.prototypejs.org/dom/element.html? If redirects are possible in Mephisto, I could have a crack at it, but perhaps in the short term (since not all of the content has been moved over yet) it would be better just to have links at the top... -- T.J. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] A more efficient $super for Prototype 2
Hi all,
I've come up with a new way of handling $super (which I can't imagine
is unique, it's just new to me) which is markedly more efficient than
our current $super on all of the browsers I've tried it on. I'm
wondering whether we should consider it for Prototype 2.
Executive summary:
Pros -
* Avoids calling toString on subclass methods when defining classes.
* Avoids creating closures for each $super-enabled subclass method.
* Avoids creating an on-the-fly function on every call to a $super-
enabled method.
* Avoids at least four extra calls when $super-enabled methods are
called.
* Consequently reduces the time to call methods that use $super, from
markedly (1.6X as fast) to dramatically (10X as fast) depending on
browser and choices the subclass author makes.
* Theoretically reduces memory footprint (no added functions/
closures).
* Minifiers (like packer3) that change arg names don't break things by
renaming $super.
* (Subjective) Simpler code in Class.create for contribs to
understand.
Cons -
* Breaks backward compatibility.
* Syntax for calling the $super method is slightly more complex.
Details:
A brief review of how $super currently works:
1. When a class is defined, Class.create calls Function#argumentNames
on each method defined by the subclass. (#argumentNames is
Function#toString followed by three regexes and a String#split.)
Class.create then checks the first argument to see if its name is
$super and, if so, creates a closure to hold the ancestor and wraps
the member function to set up the $super goodness.
2. When a $super-enabled method is called, it is in fact our wrapper
that is called. The wrapper creates a new function on the fly (on
every call) to bind our closure to this and passes the result to the
subclass's real method as the $super parameter.
This results in the wonderfully simple syntax supported by Prototype
classes, that you can call the super's version of a function simply by
calling $super:
nifty: function($super, foo, bar) {
$super(foo);
}
You don't even have to pass in this, it's all handled for you,
though at a substantial runtime cost. (Note that in this example,
only 'foo' and not 'bar' is passed to the super; presumably 'bar' has
meaning only to the subclass.)
The new approach is markedly simpler and more direct at both the class
definition stage and the method call stage. However, calling the
$super version of the function is not quite as straightforward.
Here's how the new approach works:
1. At class definition time, Class.create detects that the subclass
overrides the superclass's method (this is a trivial property check)
and, if so, stores a reference to the super's function as a property
called $super on the sub's function object.
2. When a method is called, there is no indirection, the call goes
direct to the subclass's defined method. The subclass can then call
the super's version via arguments.callee.$super.
The unaided syntax subclass methods would use to call the super's
version is complicated and error-prone (to the novice, anyway):
nifty: function(foo, bar) {
arguments.callee.$super.call(this, foo);
}
...and so this solution envisions a helper callSuper method (name
TBD) authors may choose to use instead (at the cost of an extra
function call):
nifty: function(foo, bar) {
this.callSuper(arguments, foo);
}
You can see why I think a helper may be useful; that's quite a lot
simpler. Note that the first argument is always 'arguments' and does
*not* mean #callSuper is passing all of the arguments to the super
function; you follow it with the arguments you want to pass. We can
muck about with the API on the helper, and of course class authors can
create their own for their own needs.
In my tests on Windows, IE shows the least improvement and Chrome the
most. Specifically, my simple tests so far (all of these numbers are
rounded, and they vary quite a lot from test to test, so these are
just indicative):
Using callSuper syntax:
* IE: 38% reduction in method call time, e.g., calls are 1.6 times as
fast
* Safari: 58% reduction; 2.4 times as fast
* Firefox: 65% reduction; 2.9 times as fast
* Opera: 66% reduction; 2.9 times as fast
* Chrome: 83% reduction, calls are 5.8 times as fast
Using direct (but complicated) syntax:
* IE: 40% reduction, 1.7 times as fast
* Safari: 77% reduction; 4.4 times as fast
* Opera: 77% reduction; 4.4 times as fast
* Firefox: 80% reduction; 4.9 times as fast
* Chrome: 91% reduction, calls are 10.1 times as fast
Using the complicated syntax, that's a full order of magnitude *or
better* on Chrome (but let's face it, Chrome is already so much faster
than everything else it's less important than it would otherwise be),
and Firefox sees ~5X improvement. With the syntax I would expect most
class authors to use, the benefit is less but still marked.
Call overhead isn't sexy, but does anyone else think this is worth
looking at more closely?
--
T.J. Crowder
tj
[Prototype-core] Re: A more efficient $super for Prototype 2
@Allen @Jim, Gets my vote. -- T.J. :-) On Sep 4, 3:05 pm, Jim Higson j...@wikizzle.org wrote: On Friday 04 September 2009 14:09:32 T.J. Crowder wrote: [...] I do _not_ mean that I think callSuper is a great name; I don't and I expect suggestions like yours to result in a better name. But something unlikely to clash makes it simpler for people to do a global search-and-replace to convert $super(...) to this.niftyNameHere(arguments, ...). How about this.$super()? -- Jim my wiki ajaxification thing:http://wikizzle.org my blog:http://jimhigson.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Copying arguments
Hi all,
In the 1.6.1 source, we're grabbing a reference to Array's `slice`
method and then using that in a variety of places to copy subsets (or
sometimes entire sets) of arguments, like so:
var slice = Array.prototype.slice;
//. ...
function bind(context) {
if (arguments.length 2 Object.isUndefined(arguments[0]))
return this;
var __method = this, args = slice.call(arguments, 1);
return function() {
var a = merge(args, arguments);
return __method.apply(context, a);
}
}
This is presumably on the assumption that using the built-in slice
method will perform better than our own loop would. It's a perfectly
reasonable assumption. I *like* the assumption. The assumption makes
*sense* to me.
It just happens to be wrong:
http://pastie.org/605898
(Well, except on Firefox.)
On Chrome, using Array.prototype.slice via Function#call is 8-10 TIMES
slower than our own function would be; on IE, it's about 25% slower,
on Safari and Opera it's about 50% slower. On Firefox, the odd one
out, the own loop is 50% slower than `slice`.
I mention this for three reasons.
1. We might consider providing a copy function like the one in that
pastie and using it in the various places we copy args skipping the
first few. It adds code, but improves performance -- except in
Firefox -- in some key areas (binding, currying, etc.), and
performance is an issue.
2. It's a reminder to check our assumptions.
3. It raises a question I've had for a while: How do you feature
test performance stuff? This isn't the only thing like this.
There's this question/answer[1] over on stackoverflow, for instance.
Writing my originally-brief answer I made a reasonable assumption
about performance, someone checked it and found that I was Quite Wrong
Thank You, and that lead to my finding wild differences in a very
simple operation (zero-filling an array) across implementations.
FWIW,
[1]
http://stackoverflow.com/questions/1295584/most-efficient-way-to-create-a-zero-filled-javascript-array/1295671
--
T.J. Crowder
tj / crowder software / com
www.crowdersoftware.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: A more efficient $super for Prototype 2
Hi again folks, This thread[1] about using Array.prototype.slice to copy arguments made me wonder whether the speed improvements I found had more to do with the fact my implementation of the new mechanism had its own copy- the-args function (which is faster than using `slice` on most browsers; see the thread for details) than with eliminating calls and function creation. And the answer is: No, but with the important caveat: On Chrome when using the callSuper helper, a big part of the gains were indeed down to the copy-the-args function instead of `slice`. If I modify my new mechanism to use `slice` instead (which obviously is the wrong way 'round, but never mind), when using the helper the new mechanism is only about 2X faster on Chrome than the old mechanism. Of course, Firefox got faster in that scenario (since Firefox is the one browser in my set of tests where using `slice` is faster than one's own copy function). So summing up, the new mechanism remains faster across-the-board even using the helper, but the gains on Chrome will not be as marked (when using a helper) as they seem at present because of the difference in how args are copied. And of course, one of the great things about the new mechanism is that you don't have to copy args at all if you are willing to use the more verbose syntax. [1] http://groups.google.com/group/prototype-core/browse_thread/thread/cf8c287e231a0192# -- T.J. Crowder tj / crowder software / com www.crowdersoftware.com On Sep 4, 3:09 pm, T.J. Crowder t...@crowdersoftware.com wrote: @Allen @Jim, Gets my vote. -- T.J. :-) On Sep 4, 3:05 pm, Jim Higson j...@wikizzle.org wrote: On Friday 04 September 2009 14:09:32 T.J. Crowder wrote: [...] I do _not_ mean that I think callSuper is a great name; I don't and I expect suggestions like yours to result in a better name. But something unlikely to clash makes it simpler for people to do a global search-and-replace to convert $super(...) to this.niftyNameHere(arguments, ...). How about this.$super()? -- Jim my wiki ajaxification thing:http://wikizzle.org my blog:http://jimhigson.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Odd Maruku errors whilst raking the docs.
Hi Richard, Yeah, see the PDoc mailing list[1]. Maruku is a no-go, too. :- ( Tobie's getting very frustrated (as am I). [1] http://groups.google.com/group/pdoc?lnk= -- T.J. Crowder tj / crowder software / com www.crowdersoftware.com On Sep 4, 4:59 pm, Richard Quadling rquadl...@googlemail.com wrote: Hi. ___ | Maruku tells you: +-- - | Could you please format this better? | I see that compatibility, through codea title=\Number#succ (instance method)\ href=\../language/number.html#succ-instance_method\Number#succ/a/code . is left after the raw HTML. | At line 6 | raw_html |codea title=ObjectRange (class) href=../language/objectrange.htmlObjectRange/a/code compatibility, through codea title=Number#succ (instance method) href=../language/number.html#succ-instance_methodNumber#succ/a/code. | +-- - !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/errors_management.r b:49:in `maruku_error' !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/input/parse_block.r b:251:in `read_raw_html' !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/input/parse_block.r b:88:in `parse_blocks' !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/input/parse_block.r b:301:in `read_list_item' !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/input/parse_block.r b:78:in `parse_blocks' \__ _ ___ | Maruku tells you: +-- - | Could not find ref_id = 0255 for md_link([0..255],0255) | Available refs are [] +-- - !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/errors_management.r b:49:in `maruku_error' !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/output/to_html.rb:7 16:in `to_html_link' !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/output/to_html.rb:9 70:in `send' !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/output/to_html.rb:9 70:in `array_to_html' !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/output/to_html.rb:9 61:in `each' Rendering: dom/element.html creating a link for ref_id = 0255. ___ | Maruku tells you: +-- - | Could you please format this better? | I see that : A string of HTML to be parsed and rendered is left after the raw HTML. | At line 6 | raw_html |codea title=String (class) href=../language/string.htmlString/a/code: A string of HTML to be parsed and rendered| +-- - !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/errors_management.r b:49:in `maruku_error' !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/input/parse_block.r b:251:in `read_raw_html' !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/input/parse_block.r b:88:in `parse_blocks' !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/input/parse_block.r b:301:in `read_list_item' !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/input/parse_block.r b:78:in `parse_blocks' \__ _ ___ | Maruku tells you: +-- - | Could you please format this better? | I see that : An Element instance to insert is left after the raw HTML. | At line 7 | raw_html |codea title=Element (class) href=../dom/element.htmlElement/a/code: An Element instance to insert| +-- - !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/errors_management.r b:49:in `maruku_error' !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/input/parse_block.r b:251:in `read_raw_html' !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/input/parse_block.r b:88:in `parse_blocks' !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/input/parse_block.r b:301:in `read_list_item' !C:/Ruby/lib/ruby/gems/1.8/gems/maruku-0.6.0/lib/maruku/input/parse_block.r b:78:in `parse_blocks' \__ _ ___ | Maruku tells you: +-- - | Could you please
[Prototype-core] Re: A more efficient $super for Prototype 2
Hi Juriy,
Thanks for that. Yes, it was the function decompilation (and the on-
the-fly bind) that made me look for another solution.
I was unaware of the performance implication of arguments.callee, and
*WOW* does it make a speed difference (see below). The good thing is
that this solution doesn't require arguments.callee (we'll have to
adjust the helper, or do away with it). Just name your functions and
use the name. You _can_ use arguments.callee if you like, but for
best results, use function names.
Because **HOLY COW** what a difference that makes. Using the
function's name instead makes the new mechanisn 16-50X faster (I kid
you not) than the old on Chrome. Firefox also goes through the roof
speed-wise, we're talking 35X+. Even IE is more impressed, going from
1.6X to 2.4X as fast. Opera says yes, please with a 11X
improvement, as does Safari with 10X.
The fly in the ointment is that IE will not acknowledge the function
name if defined as part of an assignment/initialization statement like
so:
var Thingy = Class.create({
nifty: function nifty(foo, bar) {
nifty.$super.call(this, foo);
}
});
It just ignores the function name and complains that 'nifty' is not
defined. This works:
var Thingy = Class.create((function() {
function nifty(foo, bar) {
nifty.$super.call(this, foo);
}
return {nifty: nifty};
})());
(Which is what a lot of the Prototype source now does.) So that's a
larger impact on how you define classes, but also suggests a useful
pattern to authors for sharing common private class methods/data
within the closure, and WOW what a performance difference.
There seems to be enough interest in this that it's worth my doing a
sample changeset with test cases and sharing it 'round; I'll do that
over the weekend.
--
T.J. Crowder
tj / crowder software / com
www.crowdersoftware.com
On Sep 4, 6:25 pm, kangax kan...@gmail.com wrote:
On Sep 4, 8:15 am, T.J. Crowder t...@crowdersoftware.com wrote:
Hi all,
I've come up with a new way of handling $super (which I can't imagine
is unique, it's just new to me) which is markedly more efficient than
our current $super on all of the browsers I've tried it on. I'm
wondering whether we should consider it for Prototype 2.
Our current solution is clearly one of the slowest inheritance
implementations out there. You get very nice sugar for a very high
price :) No surprises there. I think P2 should definitely employ a
simpler approach (either fully replacing old one or just as a separate
option).
It's worth mentioning that one of the warts of current solution is
that it relies on function decompilation - something that's known to
cause problems [1][2] and is better avoided (fwiw, ES committee didn't
have enough time to handle this issue so ES5 specifies
`Function.prototype.toString` to return the very same *implementation-
dependent* function representation)
Executive summary:
Pros -
* Avoids calling toString on subclass methods when defining classes.
* Avoids creating closures for each $super-enabled subclass method.
* Avoids creating an on-the-fly function on every call to a $super-
enabled method.
* Avoids at least four extra calls when $super-enabled methods are
called.
* Consequently reduces the time to call methods that use $super, from
markedly (1.6X as fast) to dramatically (10X as fast) depending on
browser and choices the subclass author makes.
* Theoretically reduces memory footprint (no added functions/
closures).
* Minifiers (like packer3) that change arg names don't break things by
renaming $super.
* (Subjective) Simpler code in Class.create for contribs to
understand.
Cons -
* Breaks backward compatibility.
* Syntax for calling the $super method is slightly more complex.
* Relies on `arguments.callee` with all the consequences.
To explain consequences:
`arguments.callee` is considered one of the warts of ES3. Besides
certain security concerns, the bad part of it is that it requires
creation of `arguments` object (when entering execution context). This
creation is rather expensive and results in both - memory and perf.
hits. Some of the modern implementations optimize in such way that
they only create `arguments` object when it statically occurs in a
function body (or when there's a chance of dynamic evaluation, such as
`eval`, `setTimeout` occurrence, etc.). Others create `arguments`
object on first resolution of `arguments` identifier, etc.
You can easily see it by yourself. Create 2 identical functions, one
of which would use `arguments.callee` and another - plain identifier;
then look at a difference.
ES5 also introduces strict mode. When in strict mode,
`argument.callee` throws TypeError on access. IIRC, Caja (secure
subset of ES) and some of its variations (Cajita, Valija), emulate ES5-
strict behavior and also throw error. If something in Prototype
[Prototype-core] Re: More useful Element.clone method
Hi,
FWIW, I don't think this is should be core. It may be useful in the
scenario in which you're using it, which is great, but I see too many
dangers involved in copying event handlers from one element to
another. I mentioned one of them here.[1]
[1]
http://groups.google.com/group/prototype-scriptaculous/browse_thread/thread/e5286fee9ac18a40
Happy coding,
--
T.J. Crowder
tj / crowder software / com
www.crowdersoftware.com
On Aug 27, 5:36 pm, watermark86 watermar...@gmail.com wrote:
I posted this code on the support list, but now that it's working, it
seems more appropriate to put it here. Using 1.6.1rc3, the following
bit of code will deep clone an element along with the events that are
attached to it and the data stored with Element.store. I've tested it
in Firefox 3.5 with every scenario I can think of and it seems to work
fine. I propose similar functionality be added to the Element.clone
method.
deepClone: function(element) {
var newElement = element.clone(true); //clone the node
//stop observing all events on the newElement (IE (and some
others?) copies them)
newElement.stopObserving();
//copy storage
Element.getStorage(newElement);
(Element.Storage[newElement._prototypeUID[0]]=new Hash
(Element.getStorage(element))).unset('prototype_event_registry');
//copy the events on the parent
if (!Object.isUndefined(registry = Element.retrieve(element,
'prototype_event_registry'))) {
registry.each( function(pair) {
var eventName = pair.key, responders = pair.value;
responders.each( function(r) {
Element.observe(newElement, eventName,
r.handler);
});
});
}
//get all of the descendants
var srcdecend = element.descendants();
var dstdecend = newElement.descendants();
var numdecend = srcdecend.length;
//foreach of the descendants
for(var i = 0; i numdecend; ++i) {
//stop observing all events on the newElement (IE (and some
others?) copies them)
dstdecend[i].stopObserving();
//copy storage
Element.getStorage(dstdecend[i]);
(Element.Storage[dstdecend[i]._prototypeUID[0]]=Element.getStorage
(srcdecend[i]).clone()).unset('prototype_event_registry');
//copy the events on each child to it's new corrisponding child
var registry = Element.retrieve(srcdecend[i],
'prototype_event_registry');
if (!Object.isUndefined(registry)) {
registry.each( function(pair) {
var eventName = pair.key, responders =
pair.value;
responders.each( function(r) {
Element.observe(dstdecend[i],
eventName, r.handler);
});
});
}
}
return newElement;
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Template Class
Hi Simon,
Funny you should be doing that, I was just looking at Template the
other day and thinking I might suggest a rewrite for 1.7 or 2.0.
When I did a similar thing in Java a few years back, I made it heavy
on the initialization and light on evaluation -- since the point of a
template is to be reused. The idea was to turn the template string
into an array of literal segments and replacement segments on init,
e.g.
Hello #{username}, welcome to #{sitename}!
becomes:
Literal: Hello
Replace: 'username'
Literal: , welcome to
Replace: 'sitename'
Literal: !
Then evaluating the template is just running through the array;
roughly (http://pastie.org/596449):
var result, n, l, sub;
l = segments.length;
result = new Array(l);
for (n = 0; n l; ++n) {
segment = segments[n];
if (typeof segment == 'string') {
result[n] = segment;
}
else {
sub = /* ...get substitution ... */
result[n] = sub;
}
}
return result.join('');
Your current code for #evaluate could readily be recast as the
#initialize piece.
Granted this may be slightly larger (because we need to add the loop
above), but it should (subject to testing) be faster. It also lends
itself to future enhancement, such as having formatting syntax, since
that cost is front-loaded. I've already proposed the first, trivial,
formatter for a common use case -- a flag indicating we should escape
HTML tags when subbing:
http://github.com/tjcrowder/prototype/commit/29b76e7a9e9c6168d62f1d1c6da9aafb1bf5086f
FWIW,
--
T.J. Crowder
tj / crowder software / com
On Aug 26, 12:28 am, Samuel Lebeau samuel.leb...@gmail.com wrote:
Hi,
I've been working on a Template rewrite trying to reduce code size and
complexity.
It uses `String#replace` instead of `String#gsub` and thus performs
better.
Do you guys see any enhancements (in terms of performance or code
size) that could be made ?
Diff:http://github.com/samleb/prototype/commit/8ba0a0b80c5ad230cec32e76636...
File:http://github.com/samleb/prototype/blob/8ba0a0b80c5ad230cec32e766360e...
Best,
Samuel.
On 12 août 09, at 20:37, Allen wrote:
Sorry, misunderstood what you were asking. I thought you meant why
can't the values be populated into the string at initialization.
On Aug 12, 2:32 pm, Yaffle vic99...@yandex.ru wrote:
String#interpolate uses Template#evaluate.
This Template realization makes some actions in constructor of
Template class instead of Template#evaluate.
So if you will use Template#evaluate many times for one Template
object, you will save a little time.
On Aug 12, 6:41 pm, Allen bla...@gmail.com wrote:
You should use Strings interpolate function for this. A template is
meant to be reused many times with many different filler values.
On Jun 14, 10:41 am, Yaffle vic99...@yandex.ru wrote:
var Template = Class.create({
initialize: function(template, pattern){
var parts = template.toString().split(pattern ||
Template.Pattern),
pl = parts.length,
pattern2 = /^([^.\[]+|\[((?:.*?[^\\])?)\])(\.|\[|$)/;
for(var i=1,k=1;ipl;i+=4){
var before = parts[i] || '',
escaped = parts[i+1];
if(before=='\\'){
parts[k-1] += escaped;
}else{
parts[k-1] += before;
var propList = [],
expr = parts[i+2],
match = pattern2.exec(expr);
while(match){
propList.push( match[1].startsWith('[') ?
match[2].replace(/\
]/g, ']') : match[1] );
if(!match[3]){
break;
}
expr = expr.substring('[' == match[3] ? match[1].length :
match[0].length);
match = pattern2.exec(expr);
}
if(propList.length){
parts[k] = propList;
parts[k+1] = parts[i+3];
k+=2;
}else{
parts[k-1] += parts[i+3];
}
}
}
parts.length = k;
this.parts = parts;
},
evaluate: function(object){
if(Object.isFunction(object.toTemplateReplacements)){
object = object.toTemplateReplacements();
}
object = object || '';
var r = this.parts[0];
for(var i=1,pl=this.parts.length;ipl;i+=2){
var propList = this.parts[i],
ctx = object;
for(var j=0,l = propList.length;jl ctx;j++){
ctx = ctx[propList[j]];
}
r+= String.interpret(ctx)+this.parts[i+1];
}
return r;
}});
Template.Pattern = /(^|.|\r|\n)(#\{([^\}]*)\})/;
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group
[Prototype-core] Re: Suggested addition to Function Methods: .repeat(seconds[, arg...])
Hi all,
Weighing in... First off, love the idea of Function#repeat.
Wonderfully simple and expressive.
As Tobie says, the goals when doing it should be to handle all of the
issues PE already handles, to reuse existing code, and to be
consistent with other API functions.
Some notes:
1. I'd avoid requiring #curry or #bind on top of #repeat; #repeat
should be able to handle arguments and context itself. Every curry at
least doubles the call overhead.
2. Optional context would be helpful:
Function#delay(options[, args...]) - Number
...with `options` being either a number (frequency) or an object with
`context` and `frequency` parameters; the latter allows repeating
method calls.
3. #1 suggests that rather than #repeat using PE, the guts of PE
should become #repeat and the PE should use it:
var PeriodicalExecuter = Class.create({
initialize: function(callback, frequency) {
this.handle = callback.repeat(frequency, this);
},
stop: function() {
if (this.handle) {
clearInterval(this.handle);
this.handle = 0;
}
}
});
4. I'd like to be able to repeat functions not explicitly designed to
#repeat, which suggests not changing their signature. Perhaps the self-
stop mechanism could remain a feature that PE adds on top of #repeat
(at the cost that PE functions have to be explicitly intended to be
repeated [or must ignore their args], as is currently the case).
5. Like Robert, I prefer the self-repeat over setInterval (that's
always how I do it), but unless we've seen significant issues with
setInterval we should be wary of changing it, especially in light of
how doing so complicates the API (e.g., return value issues). Perhaps
this aspect is a separate question entirely.
6. If we do need to use something other than an interval handle as the
return value, I'd suggest providing a stop function that works with
both interval handles and whatever our new thing is, e.g.:
Function.stop = function(handle) {
if (typeof handle == 'number') {
clearInterval(handle);
}
else {
/* ...stop it the new way... */
}
};
@Rick: All of this discussion probably seems like nit-picking your
idea to death. In fact, I think it indicates that there's a lot of
support and appreciation for your idea, and we're all (well, nearly
all, there's a dissenter) just trying to make it fit in, and make it
as cool as the idea warrants.
--
T.J. Crowder
tj / crowder software / com
On Aug 26, 3:33 am, Samuel Lebeau samuel.leb...@gmail.com wrote:
Joe,
Callback function receives PE instance as first argument, so here
would be the self-stop mechanism :
function(executer) { executer.stop() }.repeat()
Best,
Samuel.
On 26 juin 09, at 15:46, joe t. wrote:
Tobie,
Function.prototype.repeat = function(interval) {
var fn = this;
if (arguments.length 1) {
// not testsed but you get the idea
fn = fn.curry.apply(fn, Array.prototype.slice.call(arguments, 1));
}
return new PeriodicalExecuter(fn, interval);
}
If sticking to the PE approach there's no internal self-stop mechanism
(is there?), which i see as a nice touch in the above proposal (for
what my opinion is worth).
What about (from 1.6.1_rc2):
onTimerEvent: function() {
if (!this.currentlyExecuting) {
try {
this.currentlyExecuting = true;
if (this.execute()===false) // MOD
this.stop(); // NEW
} catch(e) {
/* empty catch for clients that don't support try/finally */
}
finally {
this.currentlyExecuting = false;
}
}
}
Just tossing in my 2 cents because i'm intrigued by that feature.
-joe t.
On Jun 26, 6:02 am, Tobie Langel tobie.lan...@gmail.com wrote:
How to stop it? arguments?
Stopping it is as easy as:
pe = foo.repeat();
pe.stop();
Passing arguments would require some simple currying:
Function.prototype.repeat = function(interval) {
var fn = this;
if (arguments.length 1) {
// not testsed but you get the idea
fn = fn.curry.apply(fn, Array.prototype.slice.call(arguments, 1));
}
return new PeriodicalExecuter(fn, interval);
}
This may come to you twice, but this is slightly updated:
http://jsbin.com/opimu
This repeat() method def is 775Bytes, accepts arguments like delay/
defer,
uses setTimeout (returns initial setTimeout index) and has a
stopping
mechanism.
What's the point in returning setTimeout index? That will set
expectations which can't be met: developers will expect to be able to
stop the functions calls by clearing it.
Are you sure your proposal fixes all of the small issues PE fixes?
For
example, does it guarantee that the function will continue being
called if it happens to once throw an error. Does it avoid calling
the
function again if a previous function is still executing, etc.?
I understand your eagerness to move away from a model you
[Prototype-core] Re: Template Class
Samuel,
Sorry for the Simon error in my last post. Years ago I knew a guy
named Simon Lebeau, clearly it got ingrained my brain.
-- T.J. :-)
On Aug 27, 10:35 am, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Simon,
Funny you should be doing that, I was just looking at Template the
other day and thinking I might suggest a rewrite for 1.7 or 2.0.
When I did a similar thing in Java a few years back, I made it heavy
on the initialization and light on evaluation -- since the point of a
template is to be reused. The idea was to turn the template string
into an array of literal segments and replacement segments on init,
e.g.
Hello #{username}, welcome to #{sitename}!
becomes:
Literal: Hello
Replace: 'username'
Literal: , welcome to
Replace: 'sitename'
Literal: !
Then evaluating the template is just running through the array;
roughly (http://pastie.org/596449):
var result, n, l, sub;
l = segments.length;
result = new Array(l);
for (n = 0; n l; ++n) {
segment = segments[n];
if (typeof segment == 'string') {
result[n] = segment;
}
else {
sub = /* ...get substitution ... */
result[n] = sub;
}
}
return result.join('');
Your current code for #evaluate could readily be recast as the
#initialize piece.
Granted this may be slightly larger (because we need to add the loop
above), but it should (subject to testing) be faster. It also lends
itself to future enhancement, such as having formatting syntax, since
that cost is front-loaded. I've already proposed the first, trivial,
formatter for a common use case -- a flag indicating we should escape
HTML tags when
subbing:http://github.com/tjcrowder/prototype/commit/29b76e7a9e9c6168d62f1d1c...
FWIW,
--
T.J. Crowder
tj / crowder software / com
On Aug 26, 12:28 am, Samuel Lebeau samuel.leb...@gmail.com wrote:
Hi,
I've been working on a Template rewrite trying to reduce code size and
complexity.
It uses `String#replace` instead of `String#gsub` and thus performs
better.
Do you guys see any enhancements (in terms of performance or code
size) that could be made ?
Diff:http://github.com/samleb/prototype/commit/8ba0a0b80c5ad230cec32e76636...
File:http://github.com/samleb/prototype/blob/8ba0a0b80c5ad230cec32e766360e...
Best,
Samuel.
On 12 août 09, at 20:37, Allen wrote:
Sorry, misunderstood what you were asking. I thought you meant why
can't the values be populated into the string at initialization.
On Aug 12, 2:32 pm, Yaffle vic99...@yandex.ru wrote:
String#interpolate uses Template#evaluate.
This Template realization makes some actions in constructor of
Template class instead of Template#evaluate.
So if you will use Template#evaluate many times for one Template
object, you will save a little time.
On Aug 12, 6:41 pm, Allen bla...@gmail.com wrote:
You should use Strings interpolate function for this. A template is
meant to be reused many times with many different filler values.
On Jun 14, 10:41 am, Yaffle vic99...@yandex.ru wrote:
var Template = Class.create({
initialize: function(template, pattern){
var parts = template.toString().split(pattern ||
Template.Pattern),
pl = parts.length,
pattern2 = /^([^.\[]+|\[((?:.*?[^\\])?)\])(\.|\[|$)/;
for(var i=1,k=1;ipl;i+=4){
var before = parts[i] || '',
escaped = parts[i+1];
if(before=='\\'){
parts[k-1] += escaped;
}else{
parts[k-1] += before;
var propList = [],
expr = parts[i+2],
match = pattern2.exec(expr);
while(match){
propList.push( match[1].startsWith('[') ?
match[2].replace(/\
]/g, ']') : match[1] );
if(!match[3]){
break;
}
expr = expr.substring('[' == match[3] ? match[1].length :
match[0].length);
match = pattern2.exec(expr);
}
if(propList.length){
parts[k] = propList;
parts[k+1] = parts[i+3];
k+=2;
}else{
parts[k-1] += parts[i+3];
}
}
}
parts.length = k;
this.parts = parts;
},
evaluate: function(object){
if(Object.isFunction(object.toTemplateReplacements)){
object = object.toTemplateReplacements();
}
object = object || '';
var r = this.parts[0];
for(var i=1,pl=this.parts.length;ipl;i+=2){
var propList = this.parts[i],
ctx = object;
for(var j=0,l = propList.length;jl ctx;j++){
ctx = ctx[propList[j]];
}
r+= String.interpret(ctx)+this.parts[i+1];
}
return r;
}});
Template.Pattern = /(^|.|\r|\n)(#\{([^\}]*)\})/;
--~--~-~--~~~---~--~~
You received
[Prototype-core] Re: Strict mode?
Hi Richard, This may be a topic better discussed in the general discussion group [1]. This group is for Prototype core development discussion. [1] http://groups.google.com/group/prototype-scriptaculous -- T.J. Crowder tj / crowder software / com On Aug 27, 10:12 am, Richard Heyes richard.he...@gmail.com wrote: Hi, I'm trying to get my graphing library (RGraph) working in conjunction with Prototype and to start I'm wondering if Prototype uses a strictmode? Thanks. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: rake doc in prototype giving error.
Hi Richard, Yeah, Tobie updated PDoc to use rdiscount instead of BlueCloth. If you install the rdiscount gem (gem install rdiscount), it should work -- unless you're using Windows. But! Tobie's going to update PDoc to use something else, probably maruku, rather than rdiscount. Not sure of timeframe, but we're talking hours or days, not weeks. -- T.J. Crowder tj / crowder software / com On Aug 27, 11:43 am, Richard Quadling rquadl...@googlemail.com wrote: Hi. I've just updated my local copy of prototype from git. All looks OK. Rebuilt prototype.js all fine. Run rake doc and now getting an error ... (in D:/Personal Files/Downloads/Software/Programming/Javascript/prototype) You'll need PDoc to generate the documentation. Just run: $ git submodule init $ git submodule update vendor/pdoc and you should be all set. But vender/pdoc is present and I assume correct. Trying ... git submodule init git submodule update vender/pdoc results in the error ... error: pathspec 'vender/PDoc' did not match any file(s) known to git. Did you forget to 'git add'? Anyone know the issue? Regards, RichardQ. -- - Richard Quadling Standing on the shoulders of some very clever giants! EE :http://www.experts-exchange.com/M_248814.html Zend Certified Engineer :http://zend.com/zce.php?c=ZEND002498r=213474731 ZOPA :http://uk.zopa.com/member/RQuadling --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: change DOM on select option
Hi,
This group is for discussion of development of the Prototype library,
not usage of it. Please see this group[1].
[1] http://groups.google.com/group/prototype-scriptaculous
--
T.J. Crowder
tj / crowder software / com
On Aug 27, 1:01 pm, clicforw...@googlemail.com
clicforw...@googlemail.com wrote:
Hello,
I need to change content of a dom element on select a option.
I tried to handel it like this:
script type=text/javascript
document.observe(dom:loaded, function() {
$('#englisch').onfocus = function() {
$('div').replace('pThis is English/p');}
});
/script
select name=select
optgroup
optionSelect Language/option
option id=englischEnglisch/option
option id=germanGerman/option
/optgroup
But nothing happens.
Can anyone help me out?
Thanks!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: change DOM on select option
@Allen, Alexander, Rainer,
Again, can we please pick this up over on the appropriate group[1]?
[1] http://groups.google.com/group/prototype-scriptaculous
Cheers,
--
T.J. Crowder
tj / crowder software / com
On Aug 27, 2:50 pm, Rainer Weber clicforw...@googlemail.com wrote:
Hello,
thanks for this. But it dos nothing.
I tried:
document.observe(dom:loaded, function() {
$('german').observe('change', function() {
$('language1').replace('this is the german text');
});
});
I want to change the text of a headline from englisch to german when i
choose german in the select menue.
select name=select id=dog
optgroup
optionSelect Language/option
option id=englischEnglisch/option
option id=germanGerman/option
/optgroup
/select
h2 id=language1Shop Gmund Professional Site/h2
Geets
Rainer
On Thu, Aug 27, 2009 at 3:10 PM, Allen Madsen bla...@gmail.com wrote:
Hi,
You probably want something more like this:
script type=text/javascript
document.observe(dom:loaded, function() {
$('englisch').observe('change', function() {
$('div').replace('pThis is English/p');
}
});
/script
The first problem is that you used # which is unneeded because $ assumes
the value is an ID. The second is that you were observing the wrong event.
You probably only want to make the change once the select has changed and
the 'change' event will do that for you. The last thing I changed is
switching to using observe instead of directly setting the onWhatever
property. This is the preferred way of doing things in prototype.
For future reference, this isn't the place to post questions like this.
Instead, go tohttp://groups-beta.google.com/group/prototype-scriptaculous
Allen Madsen
http://www.allenmadsen.com
On Thu, Aug 27, 2009 at 8:01 AM, clicforw...@googlemail.com
clicforw...@googlemail.com wrote:
Hello,
I need to change content of a dom element on select a option.
I tried to handel it like this:
script type=text/javascript
document.observe(dom:loaded, function() {
$('#englisch').onfocus = function() {
$('div').replace('pThis is English/p');
}
});
/script
select name=select
optgroup
optionSelect Language/option
option id=englischEnglisch/option
option id=germanGerman/option
/optgroup
But nothing happens.
Can anyone help me out?
Thanks!
--
-
Rainer Weber
KOMMA-D
Agentur für Kommunikationsdesign
Manggasse 6
D-85049 Ingolstadt
Tel.: +49 (0)841-1 29 47 60
Fax: +49 (0)841-1 29 47 63
Mobil: +49 (0)179-1 30 55 12
rai...@komma-d.dewww.komma-d.de
-
Bitte beachten!
Unsere E-Mail Adressen haben sich geändert.
Bitte verwenden Sie zukünftig die hier genannte Adresse.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Future extensions to the Template class
Hi all,
See this fairly half-baked ticket in Lighthouse for context:
https://prototype.lighthouseapp.com/projects/8886/tickets/773
Responding to the proof-of-concept commit, Kangax asked whether * was
used for this sort of thing anywhere else, and in a private email
Tobie flagged up how this in some sense tightly couples the LANG stuff
to the DOM stuff, which of course we're trying _not_ to do.
Meanwhile, I was also having further thoughts, so probably best (as
Tobie suggested to me in email) to 'round things up for discussion on
the list.
My thinking is still being thought, but basically:
1. Escaping HTML is a very common use case for Template, hence my
original desire for a simple and easy built-in way to handle it.
2. The current property expander code could handle functions that
accept no arguments with a trivial change. So just as #{user.name}
currently gets handled correctly, #{user.name.escapeHTML} could as
well (whereas at present you naturally get the source code for the
decompiled escapeHTML function!). That one small change supports my
common use case, but also several others -- toUpperCase, toLowerCase,
trim, ... So that's handy, cheap (both effort and runtime) support
for common use cases without tight coupling. That's useful not just
for transforming strings, either, but also for traversing object
graphs that use accessor methods. So #{niftything.getParent.name}
gives us the name property of the parent of the nifty thing.
(Extending this to support passing parameters to those functions
would, to me, cross a line we don't want to cross in terms of
complexity.)
3. Formatting flags are more commonly specified after the item being
formatted, usually with a colon separator. So #{property:flags}.
None of this prefix-with-an-asterisk stuff.
4. We don't want to implement formatting inside Template, that's scope
creep. If we want anything at all, we want Template to be able to
defer to formatters, and that's it.
5. Formatters could register with Template (for reuse) or be passed in
on an options property in the template constructor.
So I'm seeing two levels here. The first level supports functions in
the property expander code, and is a trivial change. The second level
is to provide semantics around triggering formatters using flags
following the tokens.
In all of this, we will want to consider performance enhancements and
complexity reduction such as Samuel Lebeau's work he mentions here:
http://groups.google.com/group/prototype-core/browse_thread/thread/b9f0b5c82a1fe702/332c887b25c75791#332c887b25c75791
-- T.J. :-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Suggested addition to Function Methods: .repeat(seconds[, arg...])
Hey Robert, It's true, I was thinking in terms of deprecating PE at some stage... :-) Re #2: Using #bind at least doubles the call overhead, which I'm not a fan of generally. ...have it throw $break! Now that is a very smart idea. -- T.J. Crowder tj / crowder software / com On Aug 27, 4:13 pm, Robert Kieffer bro...@gmail.com wrote: @TJ... Your goals sound about right. Implicit in there, I think, is make it easy to deprecate PE at some later date. At least, that's how I read it. :) Re: #2 - Why not just use bind() to provide context? I've never been a fan of overloading arguments with multiple interpretations. 'Gets too confusing, and makes the implementation that much uglier. Re: #4 - I feel the ability to self-stop is more important than being able to repeat() functions that aren't designed for it. I _really_ feel that making the self-stop behavior an optional add-on feature of PE is a bad idea. self-stop is an elegant pattern (IMHO) so forcing users to go through the awkward PE API to get at it doesn't make sense. Also, it makes deprecating PE harder. ***Hmm...*** How about this as a solution: Instead of having a function return false to stop, have it throw $break! I think that addresses your concern, and is consistent with how Prototype does this sort of thing elsewhere (in Enumerable). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggested addition to Function Methods: .repeat(seconds[, arg...])
Exceptions aren't eaten. Good, so a $break-like mechanism is possible then, just moved out a level. -- T.J. On Aug 27, 10:49 pm, Tobie Langel tobie.lan...@gmail.com wrote: *blech* to ES5's enumerable stuff not having $break or similar functionality. I've just read the forEach section of the draft spec from a while back, and I'm not seeing a discussion of exception handling. I haven't delved deep, though -- do you know offhand how exceptions in the callback function are handled? E.g, can one implement one's own $break handling, or are exceptions eaten? Exceptions aren't eaten. Re setInterval and setTimeout, how do you see implementing #delay or similar without using them? You can't. Or do you not see it, e.g., a pure LANG version of Prototype wouldn't have Function#defer. Maybe Function#defer would be defined only if window.setTimeout was present. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Form#serializeElement's 'submit' option, doc could use another pair of eyes
Cheers Allen. -- T.J. :-) On Aug 21, 7:49 pm, Allen Madsen bla...@gmail.com wrote: I've looked it over and your description appears to be correct. Allen Madsen On Fri, Aug 21, 2009 at 11:47 AM, T.J. Crowder t...@crowdersoftware.comwrote: Hi folks, I fixed ticket #21 today with this commit (my branch, not core): http://github.com/tjcrowder/prototype/commit/47d82530fe3d8751e5c95d52... I'd appreciate it if someone would look hard at the relevant if statement in Form.serializeElements and check that their interpretation of what the 'submit' option is and how it works matches mine. I'm fairly sure I'm right, but the if statement in question is dense, complex, side-effect-y, and uncommented. Since this is the first time this option has been documented, we want to get it right. Whether this is what the option *should* be doing is a whole different question, and for another time. Thanks in advance, -- T.J. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Form#serializeElement's 'submit' option, doc could use another pair of eyes
Hi folks, I fixed ticket #21 today with this commit (my branch, not core): http://github.com/tjcrowder/prototype/commit/47d82530fe3d8751e5c95d528bf324d2fb450666 I'd appreciate it if someone would look hard at the relevant if statement in Form.serializeElements and check that their interpretation of what the 'submit' option is and how it works matches mine. I'm fairly sure I'm right, but the if statement in question is dense, complex, side-effect-y, and uncommented. Since this is the first time this option has been documented, we want to get it right. Whether this is what the option *should* be doing is a whole different question, and for another time. Thanks in advance, -- T.J. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Permission denied error from 'rake doc'
Hi Richard, For these really long listings and such, I wonder if it might be better to use Pastie[1] rather than inlining them in messages? (Pastie has a plain text choice.) It's just that with replies and quoting and such, these messages get REALLY long and in some cases they seem to freak out the GGroups display (not, I know, an enormously difficult task :-) ). [1] http://pastie.org -- T.J. :-) On Apr 8, 8:45 am, Richard Quadling rquadl...@googlemail.com wrote: 2009/4/8 Richard Quadling rquadl...@googlemail.com: [snip] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Permission denied error from 'rake doc'
Thanks. With the latest, on Windows if I also comment out the atime
line, building the docs goes through to completion. However, the
generated doc seems to have issues: For instance, if I go into
index.html, then choose Language Section from the menu, if I click
on $A on the Utilities line on the page, I get a 404 for language
\dollara.html.
Can anyone build the docs without having that problem? I just need to
know whether it's an issue with my setup.
Thanks,
-- T.J.
On Apr 3, 10:41 pm, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Andrew,
Thanks. With the latest, on Windows if I also comment out the atime
line, building the docs goes through to completion. However, the
generated doc seems to have issues: For instance, if I go into
index.html, then choose Language Section from the menu, if I click
on $A on the Utilities line on the page, I get a 404 for language
\dollara.html.
Haven't had a chance to try Ubuntu yet.
-- T.J.
On Apr 3, 6:56 pm, Andrew Dupont goo...@andrewdupont.net wrote:
OK, once I commented out that File.utime line, things went smoothly.
There was an error in the rendering stage that I had to correct
(something that was showing up with BlueCloth but not with RDiscount)
— so do a git pull once again. Then the docs will build.
The line that needs commenting out is a bug in Sprockets that I've
passed along to Sam, so expect a fix for that sometime soon.
T.J., let me know if you have any further problems.
Cheers,
Andrew
On Apr 3, 11:22 am, Andrew Dupont goo...@andrewdupont.net wrote:
*headdesk*
Had local changes to my PDoc checkout that I had not pushed back to
the repo. Fixed now.
git pull git submodule update
...should do the trick.
Cheers,
Andrew
On Apr 3, 9:28 am, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Richard,
I'm really stumped here. I wonder if the lack of a ...
I'd leave it until Andrew's had a chance to take a look.
-- T.J. :-)
On Apr 3, 3:21 pm, Richard Quadling rquadl...@googlemail.com wrote:
2009/4/3 T.J. Crowder t...@crowdersoftware.com:
[snip]
I think I've found the problem.
File.utime(timestamp, timestamp, filename)
is trying to amend the time on the open file.
I commented this line and it worked.
Yup, that lets me get past that point as well. Andrew said he'd be
working on this in his Windows VM soon, so hopefully that gives him
a
leg up.
rake aborted!
undefined method `signature' for #Documentation::InstanceProperty
Ajax.Response#headerJSON
Yup, here too. Probably a different problem.
-- T.J.
I'm really stumped here. I wonder if the lack of a ...
headerJSON: function() {
...
is causing it. I tried temporarily adding one to response.js, but it
didn't make a diff.
--
-
Richard Quadling
Zend Certified Engineer
:http://zend.com/zce.php?c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Permission denied error from 'rake doc'
Hi Andrew, T.J., are you sure you're running the latest code? Yup, for the Ubuntu system yesterday I grabbed everything fresh, including updating the submodules. The Windows stuff last week was also brand-spanking-new, but just to be sure nothing was fixed in the last week, I re-grabbed the entire thing this morning and I get the same permissions error. Maybe it's an issue with how I'm setting up my repos? Here's what I'm doing when building from scratch: (Starting in my projects directory) git clone git://github.com/sstephenson/prototype.git cd prototype git submodule init git submodule update rake dist (Check that prototype.js is in the dist subdirectory) rake doc Until the rake doc part, I'm not getting any errors. Thanks, -- T.J. On Apr 3, 8:35 am, Andrew Dupont goo...@andrewdupont.net wrote: T.J., are you sure you're running the latest code? Do a git submodule update from the root Prototype directory. Those sound like issues I had run into, and fixed, several weeks ago. Meanwhile, I'll fire up my Windows VM and see what happens when I try to generate docs from there. Cheers, Andrew On Apr 2, 6:17 am, T.J. Crowder t...@crowdersoftware.com wrote: Hi again, Thought I'd give this a try on the Ubuntu lab machine I'd just built, in hopes that the permissions problem is Windows-specific. I got further, it can read the temp file, but then it runs into a problem in the PDoc Runner where it can't find the file ajax/ajax: * * * * t...@lab06:~/projects/prototype$ rake doc (in /home/tjc/projects/prototype) Parsing source files: /tmp/pdoc20090402-6276-fmbqy1-0. Parsing completed in 81.040395 seconds. Generating documentation to: /home/tjc/projects/prototype/doc. Rendering: ajax_section.html rake aborted! No such file or directory - ajax/ajax /home/tjc/projects/prototype/Rakefile:74 (See full trace by running task with --trace) * * * * (Rakefile:74 is the PDoc Runner call.) I'm guessing it's meant to be in the doc subdirectory, but looking there, there is no subdirectory called ajax. There is, however, one called Ajax (with a capital A): * * * * t...@lab06:~/projects/prototype$ ls -lA doc total 44 drwxr-xr-x 2 tjc tjc 4096 2009-04-02 12:01 Ajax -rw-r--r-- 1 tjc tjc 21681 2009-04-02 12:01 ajax_section.html -rw-r--r-- 1 tjc tjc 12309 2009-04-02 12:01 index.html * * * * Some kind of case sensitivity problem? I wonder if this has only been used successfully on Windows (if even there?), Mac OS X, and the like that don't (by default) have case-sensitive file systems... -- T.J. On Apr 2, 10:08 am, T.J. Crowder t...@crowdersoftware.com wrote: Folks, Can anyone build the docs other than Tobie and Andrew? If so, do you have any idea what's going on? I really want to close the large number of doc tickets on my plate, but there's no point in doing the work if the patches are just going to sit there unused (like this one [1]), that's just a waste of time, and none of us have time to waste. I'm about to hit a phase of a project where I won't have time to do this, so I was trying to clean them up before that. [1]https://prototype.lighthouseapp.com/projects/8886-prototype/tickets/610 Thanks in advance, -- T.J. On Mar 31, 4:00 pm, T.J. Crowder t...@crowdersoftware.com wrote: Hi Andrew, Thanks for the help. Yeah, it is weird, isn't it? :-) And yet we have permission to delete it (apparently, as it does get deleted). Are you logged in as an administrator? I am indeed, and that file is being created in the temp directory associated with my account, which in theory I'd be able to read/write to regardless. Early on, as a test, I created a different directory with a short path with no spaces and that I have full control permissions to and pointed TEMP/TMP at it instead. The directory got used, but I got the same result. -- T.J. :-) On Mar 31, 6:23 am, Andrew Dupont goo...@andrewdupont.net wrote: Christ, that's weird. It's saying you don't have permission to read the temporary file we create to build a concatenated version of Prototype with documentation comments included. The whole point of the temporary-file approach is to avoid permissions issues. Are you logged in as an administrator? Cheers, Andrew On Mar 30, 5:51 am, T.J. Crowder t...@crowdersoftware.com wrote: Hi all, I have a bunch of doc tickets I'd like to resolve (not to mention this ticket[1] discussed here[2] that I've posted a patch for, but seems to be waiting for someone to check that the doc stuff doesn't get broken by blank lines), but 'rake doc' doesn't work on my system. 'rake dist' and 'rake test' both do. [1]http://prototype.lighthouseapp.com/projects/8886-prototype/tickets/610 [2]http://groups.google.com/group/prototype-core
[Prototype-core] Re: Permission denied error from 'rake doc'
Hi, I think the issue is the /'s in the filename. I know nada about Ruby, but does it auto translate / to \ for window? I don't think. If it didn't, it probably wouldn't get that far. Most cross-OS systems (Java, for instance) handle translating slashes to backslashes in file ops on Windows. I also know nothing about Ruby, but I suspect that it does as well. -- T.J. On Apr 3, 1:37 pm, Richard Quadling rquadl...@googlemail.com wrote: 2009/4/3 T.J. Crowder t...@crowdersoftware.com: Hi Andrew, T.J., are you sure you're running the latest code? Yup, for the Ubuntu system yesterday I grabbed everything fresh, including updating the submodules. The Windows stuff last week was also brand-spanking-new, but just to be sure nothing was fixed in the last week, I re-grabbed the entire thing this morning and I get the same permissions error. Maybe it's an issue with how I'm setting up my repos? Here's what I'm doing when building from scratch: (Starting in my projects directory) git clone git://github.com/sstephenson/prototype.git cd prototype git submodule init git submodule update rake dist (Check that prototype.js is in the dist subdirectory) rake doc Until the rake doc part, I'm not getting any errors. Thanks, -- T.J. On Apr 3, 8:35 am, Andrew Dupont goo...@andrewdupont.net wrote: T.J., are you sure you're running the latest code? Do a git submodule update from the root Prototype directory. Those sound like issues I had run into, and fixed, several weeks ago. Meanwhile, I'll fire up my Windows VM and see what happens when I try to generate docs from there. Cheers, Andrew On Apr 2, 6:17 am, T.J. Crowder t...@crowdersoftware.com wrote: Hi again, Thought I'd give this a try on the Ubuntu lab machine I'd just built, in hopes that the permissions problem is Windows-specific. I got further, it can read the temp file, but then it runs into a problem in the PDoc Runner where it can't find the file ajax/ajax: * * * * t...@lab06:~/projects/prototype$ rake doc (in /home/tjc/projects/prototype) Parsing source files: /tmp/pdoc20090402-6276-fmbqy1-0. Parsing completed in 81.040395 seconds. Generating documentation to: /home/tjc/projects/prototype/doc. Rendering: ajax_section.html rake aborted! No such file or directory - ajax/ajax /home/tjc/projects/prototype/Rakefile:74 (See full trace by running task with --trace) * * * * (Rakefile:74 is the PDoc Runner call.) I'm guessing it's meant to be in the doc subdirectory, but looking there, there is no subdirectory called ajax. There is, however, one called Ajax (with a capital A): * * * * t...@lab06:~/projects/prototype$ ls -lA doc total 44 drwxr-xr-x 2 tjc tjc 4096 2009-04-02 12:01 Ajax -rw-r--r-- 1 tjc tjc 21681 2009-04-02 12:01 ajax_section.html -rw-r--r-- 1 tjc tjc 12309 2009-04-02 12:01 index.html * * * * Some kind of case sensitivity problem? I wonder if this has only been used successfully on Windows (if even there?), Mac OS X, and the like that don't (by default) have case-sensitive file systems... -- T.J. On Apr 2, 10:08 am, T.J. Crowder t...@crowdersoftware.com wrote: Folks, Can anyone build the docs other than Tobie and Andrew? If so, do you have any idea what's going on? I really want to close the large number of doc tickets on my plate, but there's no point in doing the work if the patches are just going to sit there unused (like this one [1]), that's just a waste of time, and none of us have time to waste. I'm about to hit a phase of a project where I won't have time to do this, so I was trying to clean them up before that. [1]https://prototype.lighthouseapp.com/projects/8886-prototype/tickets/610 Thanks in advance, -- T.J. On Mar 31, 4:00 pm, T.J. Crowder t...@crowdersoftware.com wrote: Hi Andrew, Thanks for the help. Yeah, it is weird, isn't it? :-) And yet we have permission to delete it (apparently, as it does get deleted). Are you logged in as an administrator? I am indeed, and that file is being created in the temp directory associated with my account, which in theory I'd be able to read/write to regardless. Early on, as a test, I created a different directory with a short path with no spaces and that I have full control permissions to and pointed TEMP/TMP at it instead. The directory got used, but I got the same result. -- T.J. :-) On Mar 31, 6:23 am, Andrew Dupont goo...@andrewdupont.net wrote: Christ, that's weird. It's saying you don't have permission to read the temporary file we create to build a concatenated version of Prototype with documentation comments included. The whole point of the temporary-file approach is to avoid permissions issues. Are you logged in as an administrator
[Prototype-core] Re: Permission denied error from 'rake doc'
Folks, Can anyone build the docs other than Tobie and Andrew? If so, do you have any idea what's going on? I really want to close the large number of doc tickets on my plate, but there's no point in doing the work if the patches are just going to sit there unused (like this one [1]), that's just a waste of time, and none of us have time to waste. I'm about to hit a phase of a project where I won't have time to do this, so I was trying to clean them up before that. [1] https://prototype.lighthouseapp.com/projects/8886-prototype/tickets/610 Thanks in advance, -- T.J. On Mar 31, 4:00 pm, T.J. Crowder t...@crowdersoftware.com wrote: Hi Andrew, Thanks for the help. Yeah, it is weird, isn't it? :-) And yet we have permission to delete it (apparently, as it does get deleted). Are you logged in as an administrator? I am indeed, and that file is being created in the temp directory associated with my account, which in theory I'd be able to read/write to regardless. Early on, as a test, I created a different directory with a short path with no spaces and that I have full control permissions to and pointed TEMP/TMP at it instead. The directory got used, but I got the same result. -- T.J. :-) On Mar 31, 6:23 am, Andrew Dupont goo...@andrewdupont.net wrote: Christ, that's weird. It's saying you don't have permission to read the temporary file we create to build a concatenated version of Prototype with documentation comments included. The whole point of the temporary-file approach is to avoid permissions issues. Are you logged in as an administrator? Cheers, Andrew On Mar 30, 5:51 am, T.J. Crowder t...@crowdersoftware.com wrote: Hi all, I have a bunch of doc tickets I'd like to resolve (not to mention this ticket[1] discussed here[2] that I've posted a patch for, but seems to be waiting for someone to check that the doc stuff doesn't get broken by blank lines), but 'rake doc' doesn't work on my system. 'rake dist' and 'rake test' both do. [1]http://prototype.lighthouseapp.com/projects/8886-prototype/tickets/610 [2]http://groups.google.com/group/prototype-core/browse_thread/thread/c5... I've installed Ruby, git, rake, etc., cloned the repo, built the submodules, etc., and again dist and test work. But I haven't manually installed anything specific for PDoc -- it'd be a great answer if it were just that I was missing out something. I'd like to get the doc stuff working so I can test my doc changes locally before posting patches. I know nothing about Ruby or rake. Anyone have any idea what's going on here and how to resolve this? * * * * C:\Projects\prototyperake doc --trace (in C:/Projects/prototype) ** Invoke doc (first_time) ** Invoke doc:build (first_time) ** Invoke doc:require (first_time) ** Execute doc:require ** Execute doc:build rake aborted! Permission denied - C:/DOCUME~1/tjc/LOCALS~1/Temp/pdoc.3196.0 C:/Projects/prototype/vendor/sprockets/lib/sprockets/concatenation.rb: 27:in `utime' C:/Projects/prototype/vendor/sprockets/lib/sprockets/concatenation.rb: 27:in `save_to' C:/Projects/prototype/rakefile:72 c:/ruby/lib/ruby/1.8/tempfile.rb:172:in `open' C:/Projects/prototype/rakefile:64 c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `call' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `execute' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `each' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `execute' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:578:in `invoke_with_call_chain' c:/ruby/lib/ruby/1.8/monitor.rb:242:in `synchronize' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in `invoke_with_call_chain' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:588:in `invoke_prerequisites' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:585:in `each' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:585:in `invoke_prerequisites' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:577:in `invoke_with_call_chain' c:/ruby/lib/ruby/1.8/monitor.rb:242:in `synchronize' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:in `invoke_with_call_chain' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:564:in `invoke' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2027:in `invoke_task' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `top_level' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `each' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in `top_level' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:2044:in `standard_exception_handling' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1999:in `top_level' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:1977:in `run' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib
[Prototype-core] Re: Permission denied error from 'rake doc'
Hi again, Thought I'd give this a try on the Ubuntu lab machine I'd just built, in hopes that the permissions problem is Windows-specific. I got further, it can read the temp file, but then it runs into a problem in the PDoc Runner where it can't find the file ajax/ajax: * * * * t...@lab06:~/projects/prototype$ rake doc (in /home/tjc/projects/prototype) Parsing source files: /tmp/pdoc20090402-6276-fmbqy1-0. Parsing completed in 81.040395 seconds. Generating documentation to: /home/tjc/projects/prototype/doc. Rendering: ajax_section.html rake aborted! No such file or directory - ajax/ajax /home/tjc/projects/prototype/Rakefile:74 (See full trace by running task with --trace) * * * * (Rakefile:74 is the PDoc Runner call.) I'm guessing it's meant to be in the doc subdirectory, but looking there, there is no subdirectory called ajax. There is, however, one called Ajax (with a capital A): * * * * t...@lab06:~/projects/prototype$ ls -lA doc total 44 drwxr-xr-x 2 tjc tjc 4096 2009-04-02 12:01 Ajax -rw-r--r-- 1 tjc tjc 21681 2009-04-02 12:01 ajax_section.html -rw-r--r-- 1 tjc tjc 12309 2009-04-02 12:01 index.html * * * * Some kind of case sensitivity problem? I wonder if this has only been used successfully on Windows (if even there?), Mac OS X, and the like that don't (by default) have case-sensitive file systems... -- T.J. On Apr 2, 10:08 am, T.J. Crowder t...@crowdersoftware.com wrote: Folks, Can anyone build the docs other than Tobie and Andrew? If so, do you have any idea what's going on? I really want to close the large number of doc tickets on my plate, but there's no point in doing the work if the patches are just going to sit there unused (like this one [1]), that's just a waste of time, and none of us have time to waste. I'm about to hit a phase of a project where I won't have time to do this, so I was trying to clean them up before that. [1]https://prototype.lighthouseapp.com/projects/8886-prototype/tickets/610 Thanks in advance, -- T.J. On Mar 31, 4:00 pm, T.J. Crowder t...@crowdersoftware.com wrote: Hi Andrew, Thanks for the help. Yeah, it is weird, isn't it? :-) And yet we have permission to delete it (apparently, as it does get deleted). Are you logged in as an administrator? I am indeed, and that file is being created in the temp directory associated with my account, which in theory I'd be able to read/write to regardless. Early on, as a test, I created a different directory with a short path with no spaces and that I have full control permissions to and pointed TEMP/TMP at it instead. The directory got used, but I got the same result. -- T.J. :-) On Mar 31, 6:23 am, Andrew Dupont goo...@andrewdupont.net wrote: Christ, that's weird. It's saying you don't have permission to read the temporary file we create to build a concatenated version of Prototype with documentation comments included. The whole point of the temporary-file approach is to avoid permissions issues. Are you logged in as an administrator? Cheers, Andrew On Mar 30, 5:51 am, T.J. Crowder t...@crowdersoftware.com wrote: Hi all, I have a bunch of doc tickets I'd like to resolve (not to mention this ticket[1] discussed here[2] that I've posted a patch for, but seems to be waiting for someone to check that the doc stuff doesn't get broken by blank lines), but 'rake doc' doesn't work on my system. 'rake dist' and 'rake test' both do. [1]http://prototype.lighthouseapp.com/projects/8886-prototype/tickets/610 [2]http://groups.google.com/group/prototype-core/browse_thread/thread/c5... I've installed Ruby, git, rake, etc., cloned the repo, built the submodules, etc., and again dist and test work. But I haven't manually installed anything specific for PDoc -- it'd be a great answer if it were just that I was missing out something. I'd like to get the doc stuff working so I can test my doc changes locally before posting patches. I know nothing about Ruby or rake. Anyone have any idea what's going on here and how to resolve this? * * * * C:\Projects\prototyperake doc --trace (in C:/Projects/prototype) ** Invoke doc (first_time) ** Invoke doc:build (first_time) ** Invoke doc:require (first_time) ** Execute doc:require ** Execute doc:build rake aborted! Permission denied - C:/DOCUME~1/tjc/LOCALS~1/Temp/pdoc.3196.0 C:/Projects/prototype/vendor/sprockets/lib/sprockets/concatenation.rb: 27:in `utime' C:/Projects/prototype/vendor/sprockets/lib/sprockets/concatenation.rb: 27:in `save_to' C:/Projects/prototype/rakefile:72 c:/ruby/lib/ruby/1.8/tempfile.rb:172:in `open' C:/Projects/prototype/rakefile:64 c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `call' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in `execute' c:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.4/lib/rake.rb:612
[Prototype-core] Re: Function.prototype.defer
Hi, FWIW, I wouldn't use it and don't think it should be in core. In this sequence: foo(); nifty.defer(); bar(); bar() runs before nifty(), on every browser, reliably. Your proposed new function would do that on IE, but on (some) other browsers nifty() would run before bar(). I wouldn't want to explain the subtle effects of that to confused users. :-) Again, FWIW, -- T.J. Crowder tj / crowder software / com Independent Software Engineer, consulting services available On Mar 29, 9:05 am, Yaffle vic99...@yandex.ru wrote: Should I use defer method for browsers, which doesn't need a moment to update new markup? May be Function.prototype could contain method, that will use defer for IE and run function immediately for other browsers? The defer method may slow page loading and may be cause errors. Sorry, for my english. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Anyone with PDoc working who can test a trivial patch for me?
Hi folks, Just trying to do a bit of tidying on the source[1], and unfortunately I can't get PDoc working on my system and am a bit pressed for time right now. If you have PDoc working on your system, could you try running it against the patched files on the linked ticket and seeing if it works okay? Tobie's concerned about the parser's handling of blank lines. Shoot me a private email if you want me to just email you an archive of the files rather than mucking about with applying the patch to your local repo. [1] http://prototype.lighthouseapp.com/projects/8886-prototype/tickets/610 Thanks in advance, -- T.J. Crowder tj / crowder software / com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Thoughts on Namespacing Native APIs
Hi Robert, For background, you might (if you haven't already) want to check out these two threads from this group on this topic: This short one: http://groups.google.com/group/prototype-core/browse_thread/thread/d38f2123aa64eb0e/ac612b72cc060943 And this _rather_ more comprehensive one: http://groups.google.com/group/prototype-core/browse_thread/thread/16d0517ecc605a00/c9cfe041c1da19de FWIW, -- T.J. Crowder tj / crowder software / com On Mar 25, 12:32 pm, Robert Kieffer bro...@gmail.com wrote: On Mar 24, 3:32 pm, Tobie Langel tobie.lan...@gmail.com wrote: Unfortunately, a number of environments do not support eval and decompiling function isn't part of any specification to date (nor planned in the near future). Best, Tobie Hey Tobie, those objections are well and good, but they can be addressed (see below). I was hoping for feedback at a bit higher level, on the overall idea. For example, does spinning off the native APIs into a separate library make sense? Is there merit to the resulting APIs (e.g. Does qip.String.endsWith(aString, substring) work for you?) What happens to the code if the APIs are made optional? ... that sort of thing. As for your specific comments... By decompiling I assume you mean Function#toString()? It may not be spec'ed, but that horse has already left the barn. Prototype (both stable and trunk) breaks on any platform where it's not supported - see Function#argumentNames(). As for eval(), that was simply a convenience to keep the sample code compact, readable. Removing that dependency is trivial - we need only do a bit more parsing of the function source, and use new Function() instead. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Protopacked version bigger than original?
Wes, Please use the general Prototype script.aculo.us discussion group[1] for general discussion; this list is for core development discussion only. [1] http://groups.google.com/group/prototype-scriptaculous Thanks, -- T.J. Crowder tj / crowder software / com Independent Software Engineer, consulting services available On Mar 20, 9:12 pm, wes w...@70kilo.tv wrote: my bad. but still, effects.js is only 37kb leaving the packed version only 17kb smaller? I heard the other versions got 'em down to like 25k and 35k? On Mar 20, 1:57 pm, Simon Charette charett...@gmail.com wrote: You forgot scriptaculous effect.js On Fri, Mar 20, 2009 at 4:32 PM, wes w...@70kilo.tv wrote: Am I missing something here? protoaculous1.6.packed.js is 146Kb prototype.js (1.6.0.2) is 123Kb and scriptaculous is 3Kb totalling 126Kb. Isn't the packed version supposed to be smaller? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Cloned repo via git, not seeing the unit test html files
Hi all, FWIW, my results for trunk this morning on Windows XP: * Fully passes on FF3 * Tries to run against Chrome but fails to launch it (rake just sits there until you kill it); but then, Chrome isn't a supported browser [1], not sure why we're trying to test it * Failures on IE7: form_test.html - testFormMethodsOnExtendedElements: 4 assertions, 1 failures, 1 errors Failure: assert got undefined TypeError: Object doesn't support this property or method, error= ([object Error]) selector_test.html - testFormMethodsOnExtendedElements: 0 assertions, 2 failures, 0 errors Failure: #level1 *:empty expected: [span id=level3_1, span id=level3_2, div id=level2_3], actual: [span id=level3_1, span id=level3_2, em id=level_only_child, div id=level2_3] Failure: newlines count as content! expected: [], actual: [em id=level_only_child] * Failures in Opera 9.64, all in dom_test.html: testElementScrollTo 0 assertions, 2 failures, 0 errors Failure: assertEqual expected: 1946, actual: 0 Failure: assertEqual expected: 1946, actual: 0 testViewportDimensions 0 assertions, 2 failures, 0 errors Failure: NOTE: YOU MUST ALLOW JAVASCRIPT TO RESIZE YOUR WINDOW FOR THIS TEST TO PASS expected: 1041, actual: 991 Failure: NOTE: YOU MUST ALLOW JAVASCRIPT TO RESIZE YOUR WINDOW FOR THIS TEST TO PASS expected: 648, actual: 598 testViewportScrollOffsets 2 assertions, 1 failures, 0 errors Failure: NOTE: YOU MUST ALLOW JAVASCRIPT TO RESIZE YOUR WINDOW FOR THESE TESTS TO PASS expected: 25, actual: 0 (Yes, I do have JavaScript allowed to do anything it wants with the window.) * Refuses to test against Safari 3.2.2, says it's not supported on Windows [1] http://prototypejs.org/download FWIW, -- T.J. :-) On Mar 20, 8:59 pm, kangax kan...@gmail.com wrote: On Mar 20, 3:03 pm, T.J. Crowder t...@crowdersoftware.com wrote: Thanks, Tobie. That was the missing bit all right. The contribute page _does_ mention rake test, but much further down; I'll update the page to tie things together a bit. Out of curiousity, anyone successfully run the tests lately on Chrome, IE7, or Opera on Windows? I'm on mac. Trunk fully passes FF3 and Safari 4 here. There are a couple of failures in Opera 9.64. I'm taking care of IE8 at the moment - just pushed few fixes for DOM suite. [...] -- kangax --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Cloned repo via git, not seeing the unit test html files
Hi all, I don't seem to be seeing the unit test HTML files. Apologies if I've done something daft, but I'm running out the door so I thought I'd ping in hopes of being able to work on stuff (I have a bunch of doc tickets to deal with) later this afternoon. I've installed Ruby, Git, etc. and have cloned the repo and successfully built via rake dist. According to the contribute page: To see what unit tests look like, open up any of the HTML documents found in test/unit/ in your browser. They run automatically, so you should see a flurry of green-colored rows after a few moments. There aren't any HTML files in test/unit at all (there are several JavaScript files that look like they may well implement certain specific tests). There are some HTML files elsewhere in the tree, but so far nothing I've found looks like the bunch of green rows described. Could someone point me at it or give me an idea where I may have gone astray? Thanks in advance, -- T.J. Crowder tj / crowder software / com Independent Software Engineer, consulting services available --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Cloned repo via git, not seeing the unit test html files
Thanks, Tobie. That was the missing bit all right. The contribute page _does_ mention rake test, but much further down; I'll update the page to tie things together a bit. Out of curiousity, anyone successfully run the tests lately on Chrome, IE7, or Opera on Windows? For me, Firefox 3 runs and passes all tests, but Chrome (1.0.154.48) doesn't even launch and I have to kill rake; IE7 fails several tests; and Opera (9.64) runs many of the tests (and as per the warning I have to manually close it per test), but then dies in the middle -- Opera not running but rake seeming to be waiting for it. This is with rake version 0.7.3 (I just today installed Ruby and rake via the One Click Ruby Installer linked from the contribute page) and a fresh clone of the repo. I haven't had time to look into these in any detail at all, but thought I'd ask the question, in case someone already knows what's going on there. Thanks, -- T.J. :-) On Mar 20, 1:44 pm, Tobie Langel tobie.lan...@gmail.com wrote: Sure. And that would warrant some documentation too. The tests are generated from the js test files. You'll need to run rake test for that. Which in turn will prompt you to require unittest_js submodules. Let me know how things go. Best, Tobie On Mar 20, 10:39 am, T.J. Crowder t...@crowdersoftware.com wrote: Hi all, I don't seem to be seeing the unit test HTML files. Apologies if I've done something daft, but I'm running out the door so I thought I'd ping in hopes of being able to work on stuff (I have a bunch of doc tickets to deal with) later this afternoon. I've installed Ruby, Git, etc. and have cloned the repo and successfully built via rake dist. According to the contribute page: To see what unit tests look like, open up any of the HTML documents found in test/unit/ in your browser. They run automatically, so you should see a flurry of green-colored rows after a few moments. There aren't any HTML files in test/unit at all (there are several JavaScript files that look like they may well implement certain specific tests). There are some HTML files elsewhere in the tree, but so far nothing I've found looks like the bunch of green rows described. Could someone point me at it or give me an idea where I may have gone astray? Thanks in advance, -- T.J. Crowder tj / crowder software / com Independent Software Engineer, consulting services available --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Prototype in 10 steps... what are they?
That's a great list. It's difficult to know where to stop in terms of teaching JavaScript as opposed to teaching Prototype; to get the best out of the latter, you're well-served understanding the former in ways that many (most?) still don't. Frankly, only small comments -- the list looks good as-is. But FWIW, I'd fiddle with the order a bit, probably subsume #6 into the other topics, add closures, add binding, and tack $$ onto the $ discussion: 1. Master the $ and $$ Functions 2. Use instance methods to perform common tasks on elements 3. Master event observing (including delegation) 4. Push the envelope with Ajax 5. Use Enumerable to manage collections 6. Master binding 7. Treat functions like first-class objects 8. Really understand closures 9. Write class-based JavaScript 10. Have your mind blown by custom events That list falls neatly into two categories: Basic techniques not requiring *too* much in terms of conceptual understanding (the first five items), then more conceptual (and powerful) stuff (the last five items). I probably would have put Enumerable lower down except that it goes well with the basic techniques group. Nit-picking, Treat functions like first-class objects sounds as though they aren't, but we're treating them like they are. I'd say the focus should be on the student learning that in JavaScript, functions *are* first-class objects. It's one of the most powerful concepts in the language. But again, all that's pretty much small stuff. -- T.J. Crowder tj / crowder software / com On Nov 18, 5:56 am, Andrew Dupont [EMAIL PROTECTED] wrote: I'm thinking about how we can flatten the learning curve. If you were to teach someone how to use Prototype in 10 incremental steps, what would they be? I've got only nine so far, but here they are: 1. Master the $ Function 2. Use instance methods to perform common tasks on elements 3. Master event observing 4. Push the envelope with Ajax 5. Use Enumerable to manage collections 6. Use Prototype's helper methods on built-in objects 7. Treat functions like first-class objects 8. Have your mind blown by custom events 9. Write class-based JavaScript Can you add a tenth to this list? Or do you have a completely different list? Let's hear it. Cheers, Andrew --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Style Guide for rewrite branch
Returning functions this way doesn't imply they do not have names. I've
successfully used pattern return someNamed function(){ ... } for
debugging.
You mean return function someNamed() { ... }, right? That's fine by
the specs, because the FunctionExpression is allowed to have an
optional name. (ECMA spec[1], section 13.)
[1] http://www.ecma-international.org/publications/standards/Ecma-262.htm
--
T.J. Crowder
tj / crowder software / com
On Nov 15, 7:43 am, artemy tregubenko [EMAIL PROTECTED] wrote:
On Fri, 14 Nov 2008 01:59:07 +0300, kangax [EMAIL PROTECTED] wrote:
My only concern about this pattern is memory usage. There are many
functions created during branching process, yet only one is returned/
assigned (and is then used throughout the rest of the application
life). Those alternative functions are stored in a closure (e.g. in a
closure of final function) and so consume memory; every method has a
burden of its branching environment (memory-wise). This wouldn't
happen if we were to use function expressions (rather than function
declarations), but then our methods wouldn't have identifiers:
var someMethod = (function(){
if (doTest()) {
return function(){
// original function
}
}
else return function(){
// alternative version
}
})();
I've never found this to be a problem (i.e. lack of function names)
but Tobie says that having those is useful for debugging. I'm still
not sure if such clarity/convenience worth memory loss. Perhaps this
loss is a non-issue and I'm just being overly paranoid : ) I
definitely like how clean and maintainable such pattern looks, though.
Returning functions this way doesn't imply they do not have names. I've
successfully used pattern return someNamed function(){ ... } for
debugging.
--
arty (http://arty.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] Style Guide for rewrite branch
In LH ticket #433, Tobie says there are (new) style rules being used in the rewrite effort that new contributions should adhere to. I've said that it's hard to conform to a style guide that doesn't exist, and suggested that a (brief) document saying what the goals and rationales are, giving the specifics, references, etc., would make sense -- for new contributors and current ones alike. Tobie agreed and asked for volunteers. Thought I'd widen the audience: Is there anyone who knows the new rules and can write them up? Then we can link to them from the Contribute page so people know what's going on. -- T.J. Crowder tj / crowder software / com --~--~-~--~~~---~--~~ 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 Effect with onComplete
Hi,
You'll want to post to the user's group:
http://groups.google.com/group/prototype-scriptaculous
This groups is for core development discussion, not end user
questions.
HTH,
--
T.J. Crowder
tj / crowder software / com
On Nov 11, 10:26 am, cleriker [EMAIL PROTECTED] wrote:
Hi there,
i need an onComplete in my morph-effekt.
here´s the code:
new Effect.Morph($('mydiv'), {
style: 'height: 288px; width:400px',
duration: 0.8
});
and after finishing this morph i need:
$(otherdiv1').setStyle('display', 'block');
$('otherdiv2').setStyle('display', 'block');
load_content(str_url);
can smb help me?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Prototype.js mistakes
Global eval is actually one of the most popular addition requests
(after people realize that `evalScripts` does not evaluate within
global scope :))
Yeah, big time; I was just pointing out that the change suggested
won't provide it (except in Gecko browsers).
I'd done some previous work on this. I just went and dug it out and
cleaned it up. This version works on FF3, IE6, Safari3win, and
Opera9:
http://pastie.org/310725
It looks like Yaffle hasn't opened a ticket for this, so I did:
http://prototype.lighthouseapp.com/projects/8886-prototype/tickets/433
It's funny that after playing with comments stripping (as per author
suggestion) I realized that out `extractScripts` is not as robust as
it could be:
And Yaffle's suggested addition -- if it does what I think it does,
ignoring end tags if they're within a comment (I'm relatively
worthless at regex) -- looks like it helps some. Not in the situation
you're talking about, but isn't that unrealistic? This:
function(){ return /script }
...doesn't work in most browsers AFAIK. (Checked checked FF3, IE6,
Safari3win, Opera9.) I think one has to be careful to do things like
this:
function(){ return /scr + ipt }
...to avoid the HTML parser ending the script early.
--
T.J. Crowder
tj / crowder software / com
On Nov 9, 5:33 am, kangax [EMAIL PROTECTED] wrote:
On Nov 8, 6:14 am, T.J. Crowder [EMAIL PROTECTED] wrote:
Yaffle,
(Just FWIW, I sense you're not a native English speaker, so I'll just
mention that posting a message called Prototype.js mistakes will
tend to be unnecessarily offensive to the folks you're trying to talk
to.)
On the script thing, by all means open a ticket on Lighthouse (details
here[1]) and submit a patch; thank you in advance.
On the eval thing: eval is a global function, not a property of the
window object.[2] Some implementations (like Firefox and Opera) let
you use window.eval and interpret the script in the context of the
window object, which is great, but it's non-standard behavior not
implemented by other browsers (IE and Safari, for instance).
Global eval is actually one of the most popular addition requests
(after people realize that `evalScripts` does not evaluate within
global scope :))
It's funny that after playing with comments stripping (as per author
suggestion) I realized that out `extractScripts` is not as robust as
it could be:
var s = 'script(function(){ return /script })();/script';
s.extractScripts(); // '(function(){ return '
and so `evalScripts` obviously fails when given a cut-off function
expression : )
[1]http://www.prototypejs.org/contribute
[2]http://www.ecma-international.org/publications/standards/Ecma-262.htm
--
T.J. Crowder
tj / crowder software / com
[...]
--
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: Prototype.js mistakes
Yaffle,
(Just FWIW, I sense you're not a native English speaker, so I'll just
mention that posting a message called Prototype.js mistakes will
tend to be unnecessarily offensive to the folks you're trying to talk
to.)
On the script thing, by all means open a ticket on Lighthouse (details
here[1]) and submit a patch; thank you in advance.
On the eval thing: eval is a global function, not a property of the
window object.[2] Some implementations (like Firefox and Opera) let
you use window.eval and interpret the script in the context of the
window object, which is great, but it's non-standard behavior not
implemented by other browsers (IE and Safari, for instance).
[1] http://www.prototypejs.org/contribute
[2] http://www.ecma-international.org/publications/standards/Ecma-262.htm
--
T.J. Crowder
tj / crowder software / com
On Nov 8, 7:04 am, Yaffle [EMAIL PROTECTED] wrote:
var Prototype = {
//
ScriptFragment: 'script[^]*([\\S\\s]*?)\/script',
//
}
May be next code would a little better?
var Prototype = {
//
ScriptFragment: 'script[^]*(?:!\\-\\-)?([\\S\\s]*?)(?:\\-\\-)?
\/script',
//
}
and for:
evalScripts: function() {
return this.extractScripts().map(function(script) { return
eval(script) });
},
evalScripts: function() {
return this.extractScripts().map(function(script) { return
window.eval(script) });
},
--~--~-~--~~~---~--~~
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: Memory Leak on IE
Hi,
FWIW, I don't think this is a bug in Prototype. Prototype keeps track
of the event handlers it hooks up so it can unhook them on page unload
to work around memory leaks in IE. (This also lets it provide the new
stopObserving functionality in release 1.6 where you don't have to
specify the handler to unhook things.) This means that it has to use
a small bit of memory to track the handlers. That's not a *leak*, I
wouldn't say, but a *use* of memory.
If you remove an element from the DOM (directly or by removing its
ancestor), I think it's incumbent on your application logic to remove
any handlers you've registered for it as well. Your function that
does this with a select(*) is obviously one way to do that, but
ideally there'd be something more finely-grained that app logic could
handle. Personally, I wouldn't want to see the select(*) thing
added to Prototype (for instance, in the Element.update method),
because I don't want that overhead every time I remove an element if I
know I don't have any handlers registered on it.
Someday we may get access to the DOM event
DOMNodeRemovedFromDocument[1]. Now that would be nice, because it
would give us notification of an element being removed and let us
release any memory we have associated with it. (I'm not sure I'd want
Prototype to do it for me even then, but I'll make that call when/if
we get the event.)
[1] http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/
If it's very complicated in your app to know which elements within the
element being replaced are being watched, you might look at event
delegation instead, which involves fewer handlers placed at a higher
(e.g., container) level.
FWIW,
--
T.J. Crowder
tj / crowder software / com
On Oct 30, 7:57 am, Yee Keat Phuah [EMAIL PROTECTED] wrote:
Hi,
Was trying to cut the memory leak reported with this tool
-http://home.wanadoo.nl/jsrosman/.
Found out that there are some memory leaks in prototype's
Event.observe, only when the element that is observed is not within
the document DOM, this might happen when
1. I have not attached the element into the DOM, or that
2. I have removeChild or replaceChild the element that was observed
on. (this is what I encountered in my project)
I see this as a leak in prototype because using the attachEvent
(button 2 in the test page) equivalent does not present the same leak.
Attaching the element into the document (button 3 in the test page)
also does not present the same leak.
I have found that the fix from this thread
-http://groups.google.com/group/prototype-core/browse_thread/thread/c2...
solves the problem, contrary to the original poster who reported it
only for IE6, my test program shows that the leak happens for IE7 as
well.
For my project, instead of using the straight forward:
parent.replaceChild(newnode, oldnode);
I have to do this instead:
$(oldnode).select(*).each(function(e) {
$(e).stopObserving();});
parent.replaceChild(newnode, oldnode);
That's quite a lot of work.
Hope to see this fixed in 1.6.1 if not 1.6.0.
Cheers,
Phuah Yee Keat
testobserve.html
2KViewDownload
--~--~-~--~~~---~--~~
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: Memory Leak on IE
Looks like Firefox already has it:
https://developer.mozilla.org/En/DOM_Events
Googling DOMNodeRemovedFromDocument site:microsoft.com brings no
joy, however. :-)
--
T.J. Crowder
tj / crowder software / com
On Oct 30, 9:02 am, T.J. Crowder [EMAIL PROTECTED] wrote:
Hi,
FWIW, I don't think this is a bug in Prototype. Prototype keeps track
of the event handlers it hooks up so it can unhook them on page unload
to work around memory leaks in IE. (This also lets it provide the new
stopObserving functionality in release 1.6 where you don't have to
specify the handler to unhook things.) This means that it has to use
a small bit of memory to track the handlers. That's not a *leak*, I
wouldn't say, but a *use* of memory.
If you remove an element from the DOM (directly or by removing its
ancestor), I think it's incumbent on your application logic to remove
any handlers you've registered for it as well. Your function that
does this with a select(*) is obviously one way to do that, but
ideally there'd be something more finely-grained that app logic could
handle. Personally, I wouldn't want to see the select(*) thing
added to Prototype (for instance, in the Element.update method),
because I don't want that overhead every time I remove an element if I
know I don't have any handlers registered on it.
Someday we may get access to the DOM event
DOMNodeRemovedFromDocument[1]. Now that would be nice, because it
would give us notification of an element being removed and let us
release any memory we have associated with it. (I'm not sure I'd want
Prototype to do it for me even then, but I'll make that call when/if
we get the event.)
[1]http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/
If it's very complicated in your app to know which elements within the
element being replaced are being watched, you might look at event
delegation instead, which involves fewer handlers placed at a higher
(e.g., container) level.
FWIW,
--
T.J. Crowder
tj / crowder software / com
On Oct 30, 7:57 am, Yee Keat Phuah [EMAIL PROTECTED] wrote:
Hi,
Was trying to cut the memory leak reported with this tool
-http://home.wanadoo.nl/jsrosman/.
Found out that there are some memory leaks in prototype's
Event.observe, only when the element that is observed is not within
the document DOM, this might happen when
1. I have not attached the element into the DOM, or that
2. I have removeChild or replaceChild the element that was observed
on. (this is what I encountered in my project)
I see this as a leak in prototype because using the attachEvent
(button 2 in the test page) equivalent does not present the same leak.
Attaching the element into the document (button 3 in the test page)
also does not present the same leak.
I have found that the fix from this thread
-http://groups.google.com/group/prototype-core/browse_thread/thread/c2...
solves the problem, contrary to the original poster who reported it
only for IE6, my test program shows that the leak happens for IE7 as
well.
For my project, instead of using the straight forward:
parent.replaceChild(newnode, oldnode);
I have to do this instead:
$(oldnode).select(*).each(function(e) {
$(e).stopObserving();});
parent.replaceChild(newnode, oldnode);
That's quite a lot of work.
Hope to see this fixed in 1.6.1 if not 1.6.0.
Cheers,
Phuah Yee Keat
testobserve.html
2KViewDownload
--~--~-~--~~~---~--~~
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: Memory Leak on IE
Hi, As noted from the thread I quoted above, prototype 1.6 does not unhook them on page unload anymore, it just do cache[id][eventName] = null. I'll be interested in hearing what someone from Core has to say about that change; I thought maybe they'd realized that that was all that was needed to break the chain (since the issue with IE relates to *circular* references, not just references), but I never quite understood how doing that would be breaking them. But now I can't get IE6 to leak memory if I unload the page even using Crockford's queuetest2[1] (which is designed to demonstrate the circular reference leak, and does so, but within an active page). Maybe somewhere along the line M$ managed to slip a fix into a service pack that at least made IE semi-reliably clean up on page *unload*, even though not otherwise. But I know it doesn't do it reliably. [1] http://javascript.crockford.com/memory/queuetest2.html All of that is tangental, though, to the main point of your thread: Cleaning things up when the page is still loaded, and you're just removing elements. I still think doing that is in the domain of the application logic, not the library. That's my take; others may differ. :-) -- T.J. Crowder tj / crowder software / com On Oct 30, 9:41 am, Yee Keat Phuah [EMAIL PROTECTED] wrote: Hi, On Thu, Oct 30, 2008 at 5:02 PM, T.J. Crowder [EMAIL PROTECTED] wrote: FWIW, I don't think this is a bug in Prototype. Prototype keeps track of the event handlers it hooks up so it can unhook them on page unload to work around memory leaks in IE. (This also lets it provide the new stopObserving functionality in release 1.6 where you don't have to specify the handler to unhook things.) This means that it has to use a small bit of memory to track the handlers. That's not a *leak*, I wouldn't say, but a *use* of memory. As noted from the thread I quoted above, prototype 1.6 does not unhook them on page unload anymore, it just do cache[id][eventName] = null. prototype 1.5 does unblock them on page unload using stopObserving while iterating over each of the handlers. Cheers, Phuah Yee Keat --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
