[Prototype-core] Re: Suggested alteration to PrototypeJS' Object.keys implementation.
Patch welcomed.
On Oct 14, 10:45 pm, Andy E wrote:
> I recently discovered that several compatibility implementations of
> Object.keys() on the web will throw an error for DOM objects in
> Internet Explorer 8 and lower. This differs from the current browsers
> having a native implementation and how the ECMAScript 5th edition
> defines the behaviour of Object.keys.
>
> The problem lies with the hasOwnProperty() check, which is not a valid
> method on Internet Explorer DOM objects because they aren't instances
> of Object. The fix is very simple; "borrow" hasOwnProperty() from
> Object.prototype.hasOwnProperty() instead. The fixed PrototypeJS
> implementation would be:
>
> function keys(object) {
> if (Type(object) !== OBJECT_TYPE) { throw new TypeError(); }
> var results = [];
> for (var property in object) {
> if (object.prototype.hasOwnProperty.call(object, property)) {
> results.push(property);
> }
> }
> return results;
> }
>
> I've outlined the issue in more detail on my
> blog:http://whattheheadsaid.com/2010/10/a-safer-object-keys-compatibility-
>
> Cheers,
>
> Andy E
--
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
[Prototype-core] Re: Proposal: Make bound (curried, delayed...) functions look nicely in Web Inspector "Event Listeners" pane
> I think it's not a option for Prototype. At this case, bound function > could be evaluated with errors. Hadn't thought about that. Thanks for pointing it out! -- You received this message because you are subscribed to the Google 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 for second parameter to AJAX callbacks.
> headerJSON for the status (data retrieved, errors, etc.) and > responseJSON the the content (data, error messages, etc.) from the > server side app. Yes, headerJSON is particularly useful combined to HTML in the response body. -- You received this message because you are subscribed to the Google 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 for second parameter to AJAX callbacks.
> It may be just a case of the code and the documentation not agreeing > and no comments saying that the second parameter is deprecated. Right on. I also wasn't aware it was documented for Responders. We never marked it deprecated for ajax callbacks, as it never actually was documented. 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: Documentation for second parameter to AJAX callbacks.
It's been deprecated in favor of Ajax.Response#headerJSON. 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: Return value of Event.stop()
Great idea.
Would you mind submitting a patch with tests?
Thanks,
Tobie
On May 25, 12:01 pm, Johan Arensman 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
Thanks for your suggestion. This would be quite an undertaking… and falls completely out of the scope of Prototype, so it's certainly something that won't make it's way into Prototype Core. Sorry for the bad news! 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: Prototype without browser?
Hi, Rüdiger. This is definitely planned for 2.0. toxcct, you might want of have a look at a number of really exciting server side JS frameworks (node.js, narwhal, ringo, etc.). 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: API Documentation "Sections"
Done. On Apr 9, 6:33 am, gf3 wrote: > BAM. > Done:http://github.com/gf3/pdoc/commit/55f6628be7fc5f91b7602ced0fddd5617db... > > On Apr 8, 10:23 am, Tobie Langel wrote: > > > > > May I suggest someone fix this and send me a pull request? > > > 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: Helping with the web site once it's on github
> 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: Helping with the web site once it's on github
> > 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
> Thanks. Purely git? Not ruby (unless you also want to install Jekyll)? Yup. > Mind you, it seems to me even git is a barrier to casual helpers, if > they don't already use it. I think I can live with that. -- You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to 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: API Documentation "Sections"
May I suggest someone fix this and send me a pull request? 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
> 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. Are you suggesting we move the new documentation elsewhere (prototypejs.org/doc) for example and keep the old, 1.5 doc structure on prototypejs.org/api but replace the content with a link to the new documentation or maybe an HTML refresh? Isn't that just a glorified 404? -- You received this message because you are subscribed to the Google 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
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" 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
> Enh, it's not going to take long, I'll go do that now. Awesome. I don't know if you're familiar with jekyll[1], but his sports built- in templating and markdown/textile parsers. Best, Tobie [1] http://jekyllrb.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 To unsubscribe, reply using "remove me" as the subject.
[Prototype-core] Re: Kudos to the documentation team
> How about we create a prototypejs GitHub user and have the site at: > prototypejs.github.com? We'll be using prototypejs.org directly. It's supported by Github. -- You received this message because you are subscribed to the Google 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
Oh, the repo is here: http://github.com/sstephenson/prototype/tree/gh-pages -- You received this message because you are subscribed to the Google 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
You're help would be really welcomed, TJ. We're moving to github pages as it makes contributing to the website the same process as contributing code or documentation. I've started the project already: porting the whole blog archives to jekyllrb and disqus comments (preserving all past comments in the process). Your help is as usual, most welcomed, especially since I'm hoping to merge parts/whole of your unofficial wiki content into it in the long run (and if it's ok with you, of course). 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
> 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
> 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
Robert, that would be great. We unfortunately don't have this level of access to the server. -- You received this message because you are subscribed to the Google 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
A practical solution would be a well designed 404. We could get pdoc to generate it with a search field, etc. We could also try JS redirection. Anyone wants to give it a shot? Best, Tobie On Apr 6, 8:42 am, "T.J. Crowder" wrote: > > 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-document... > > -- T.J. > > On Apr 5, 3:30 pm, Mislav Marohnić wrote: > > > > > On Mon, Apr 5, 2010 at 11:48, Johan Arensman 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] Re: API Documentation "Sections"
> 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. Agreed. -- You received this message because you are subscribed to the Google 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: event memo modified is evaluated to false
The reason for this design choice was to avoid the following
altogether:
if (event.memo) {
foo = event.memo.foo;
}
and allow this instead:
foo = event.memo.foo;
There are memory costs involved with this design choice, but these can
easily be mitigated by passing in a value to the second argument of
Event.fire.
The contract this API tries to make is to systematically return an
object.
I think we should respect that.
Best,
Tobie
On Mar 26, 9:50 am, Christophe Porteneuve wrote:
> Hey C dric,
>
> Hmmm, I'd have to double-check the codebase for justification of this
> defaults, but even if it turns out to be useful, the implementation
> seems clearly faulty. It should go something like:
>
> event.memo = (undefined === memo ? {} : memo);
>
> Thanks for the heads up.
>
> --
> Christophe Porteneuve aka TDD
> t...@tddsworld.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
To unsubscribe from this group, send email to
prototype-core+unsubscribegooglegroups.com or reply to this email with the
words "REMOVE ME" as the subject.
[Prototype-core] Re: Array toJson
Here's a (not so brief) explanation on the recent changes and the
upcoming plans for our JSON API.
Our previous JSON implementation was based on Douglas Crockford's
original proposal in which primitives, Array and Object prototypes
each had their own toJSONString method. We mimicked that behaviour
with two exceptions: 1) we did not extend Object.prototype and 2) we
called our methods toJSON instead of toJSONString because our API was
slightly different (Crockford's implementation took an extra arguments
for prettifying the output string; ours didn't), and because we wanted
to avoid naming collisions.
Unfortunately, the specification was modified a number of times until
it was stabilized in ES5's final draft not long ago.
First of all, the toJSONString method was dropped in favor of a toJSON
method (hello naming collision).
Secondly, all but Date.prototype.toJSON methods where dropped.
Finally, where the toJSONString method returned… a string, the new
toJSON method now returned a native object or primitive ready to be
stringified:
new Date().toJSONSting();
// -> "\"2010-02-26T16:23:40Z\""
new Date().toJSON();
// -> "2010-02-26T16:23:40Z"
Notice how the first example returns a quoted string while the return
value of the second one isn't quoted.
Our JSON implementation had the method names of the ES5
implementations with the behaviour of the original JSON spec. That
obviously caused a lot of issues with services which relied on the
native JSON object when present, hence the decision to modify this
behaviour for our next release (1.7).
String.prototype.evalJSON behaves like JSON.parse except:
a) it does not accept a reviver,
b) it internally calls String.prototype.unfilterJSON to help protect
against JavaScript Hijacking[1].
Whenever the native JSON object is present _and works correctly_
String.prototype.evalJSON acts as a wrapper around it. Whenever the
native JSON object isn't present (or is broken), we provide our own
implementation. In which case the JSON-formatted string is not parsed
but evaled, but can be sanitized using JSON2's regexp tests by setting
the sanitize flag to true.
Object.toJSON behaves like JSON.stringify except:
a) it doesn't accept replacer and space arguments, and
b) Object.toJSON(Object) will yield undefined instead of {} (not that
this seems like such a big deal).
Again, whenever the native JSON object is present and works properly
our implementation just acts like a wrapper around it.
The reason for not providing the JSON object when it's missing is
threefold:
1. For now, we don't judge the reviver, replacer and prettifier
options necessary. Providing our own API allows us to avoid
implementing those for the time being.
2. Some browsers' JSON implementations are broken. If we weren't
relying on a wrapper, we'd be forced to replace these altogether.
3. The native API is made of static methods, so being forced to use a
wrapper API has a lot less impact on code readability than when
"instance" methods are missing. Compare:
JSON.stringify(foo);
// and
namespace.JSON.stringify(foo);
with
[1, 2, 3].map(function(e) { return i++; }).join(', ');
// and
namespace.map([1, 2, 3], function(e) { return i++; }).join(', ');
I can imagine that our JSON implementation in Prototype 2.0 will match
the native API more closely but will stay in it's own namespace (as in
the example above).
Hope this clarifies the recent changes.
Best,
Tobie
1.
http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf
--
You received this message because you are subscribed to the Google 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 common loader for browser-based toolkits
Hi, James. Thanks for popping in. I'm working on a Sprockets-inspired CommonJS module implementation targeted at browsers[1]. It's more of a POC right now than anything else, but with a bit of polish, I can very well imagine it fitting the bill for most use- cases. In a nutshell all it does is a recursive static analysis to collect the dependencies of the JavaScript file it's fed with. In production mode, the result is concatenated. In development mode (not implemented yet as it's server-side dependant) each file will be wrapped with code similar to your require.def(...) call and served by it's own static SCRIPT tag thus preserving file names and line numbers. I'm fully aware of the limits of CommonJS at the time being (sync vs. async, etc.). >From what I understand, there are plans to address these issues via a module loader of some sort. Any reasons why you are trying to circumvent that emerging standard altogether rather than pushing for the loader API to be standardized? Best, Tobie 1. http://github.com/codespeaks/modulr On Feb 23, 2:30 am, James Burke wrote: > Hi, > > My name is James Burke, and I am usually a Dojo contributor. However, > I have been working on a standalone, non-Dojo script/module loader, > RequireJS,http://requirejs.org. > > I want to see if Prototype is interested in using it, and if not the > actual implementation, at least agreeing on the format/API to allow > better interop. > > While a Prototype project is capable of using RequireJS without doing > any explicit integration with the Prototype Core, there are some > things that can be done to provide a better experience, mainly making > sure dom:loaded is not fired until any inflight modules/scripts are > loaded. This could be accomplished by modifying > fireContentLoadedEvent() to know if there are require()-ed inflight > modules and to register fireContentLoadedEvent with RequireJS so it > can be called when modules are loaded. > > Since RequireJS uses dynamically generated script src="" tags, loading > of scripts/modules is async in nature, and can finish after > DOMContentLoaded. > > While smaller projects may not need a script/module loader, larger > ones do, and RequireJS has an optimization tool that can be run a > packaging/deployment time to combine scripts/modules together. > > I also believe that browser toolkits should work together to make sure > they have a loader that works well in the browser. Otherwise, as time > goes on, we will be pressed to use a format as described by CommonJS, > which as it stands today does not work well natively in the browser. > > If you are interested, I am happy to prep a fork of Prototype that > shows the integration, with unit tests. I have been able to convert > Dojo to RequireJS, and have a fork of jQuery with integration and unit > tests. The jQuery fork assumes optional integration in the JavaScript, > and I would do the same with the Prototype code, only activating the > hooks if require is present. > > James -- You received this message because you are subscribed to the Google 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's error.
PDoc turns the source code comments into Ruby objects which can then ben passed into any kind of documentation generator. Currently, the only written generator is for a static HTML website. But PDoc was built keeping in mind other formats would be highly desirable. Shoot me an email if you'd be interested in helping out with writing the DocBook generator. Best, Tobie On Jan 6, 3:13 pm, Richard Quadling wrote: > 2010/1/6 Tobie Langel : > > > > > > > Erh... but the documentation IS the website. > > > And DocBook support is planned. Maybe you'd like to help with it? > > > Best, > > > Tobie > > > On Jan 6, 11:43 am, Richard Quadling wrote: > >> 2010/1/5 Tobie Langel : > > >> > Yes. > > >> > Or you can use coderay instead, but I haven't included a stylesheet > >> > for that yet. > > >> > We choose pygments as it's already the default for github and Jekyll. > > >> > Thought this consistency might end up being useful. > > >> > Also Pygment's a real lexer. > > >> > Best, > > >> > Tobie > > >> > On Jan 5, 12:00 pm, Richard Quadling wrote: > >> >> 2010/1/5 Tobie Langel : > > >> >> > Hi Richard. > > >> >> > You'll have to use another syntax highlighter ATM or build the > >> >> > documentation without syntax highlighting. > > >> >> > To do so, just modify the rake task like so: > > >> >> >http://gist.github.com/266858 > > >> >> > Hope this helps. > > >> >> > Best, > > >> >> > Tobie > > >> >> > (Also, a patch to make pygments work on windows would be absolutely > >> >> > awesome!) > > >> >> > On Jan 4, 2:50 pm, Richard Quadling wrote: > >> >> >> Hi. > > >> >> >> Using open4 on Windows seems to be an issue. > > >> >> >> (in D:/Personal > >> >> >> Files/Downloads/Software/Programming/Javascript/prototype) > >> >> >> mkdir -p D:/Personal > >> >> >> Files/Downloads/Software/Programming/Javascript/prototype/test/unit/tmp > >> >> >> rm -rf D:/Personal > >> >> >> Files/Downloads/Software/Programming/Javascript/prototype/doc > > >> >> >> Parsing source files: D:/Personal > >> >> >> Files/Downloads/Software/Programming/Javascript/prototype/test/unit/tmp/pro > >> >> >> totype.temp.js. > >> >> >> Parsing completed in 46.735 seconds. > > >> >> >> Generating documentation to: D:/Personal > >> >> >> Files/Downloads/Software/Programming/Javascript/prototype/doc. > > >> >> >> rake aborted! > >> >> >> uninitialized constant Fcntl::F_SETFD > >> >> >> D:/Personal > >> >> >> Files/Downloads/Software/Programming/Javascript/prototype/rakefile:75:in > >> >> >> `build_doc_for' > >> >> >> (See full trace by running task with --trace) > > >> >> Isn't Pygments python? Do I need to have Python as well now? > > >> >>http://pygments.org/docs/lexers/ > > >> >> -- > >> >> - > >> >> 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=ZEND002498&r=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 > >> > athttp://groups.google.com/group/prototype-core?hl=en > > >> I think I'll skip all of this and use the website instead. > > >> I'd much rather have DocBook V5 orientated documentation. > > >> But then the dox wouldn't be inline. > > >> Swings and roundabouts. > > >> -- > >> - > >> Richard Quadling > >> "Standing on the s
[Prototype-core] Re: rake doc's error.
Erh... but the documentation IS the website. And DocBook support is planned. Maybe you'd like to help with it? Best, Tobie On Jan 6, 11:43 am, Richard Quadling wrote: > 2010/1/5 Tobie Langel : > > > > > > > Yes. > > > Or you can use coderay instead, but I haven't included a stylesheet > > for that yet. > > > We choose pygments as it's already the default for github and Jekyll. > > > Thought this consistency might end up being useful. > > > Also Pygment's a real lexer. > > > Best, > > > Tobie > > > On Jan 5, 12:00 pm, Richard Quadling wrote: > >> 2010/1/5 Tobie Langel : > > >> > Hi Richard. > > >> > You'll have to use another syntax highlighter ATM or build the > >> > documentation without syntax highlighting. > > >> > To do so, just modify the rake task like so: > > >> >http://gist.github.com/266858 > > >> > Hope this helps. > > >> > Best, > > >> > Tobie > > >> > (Also, a patch to make pygments work on windows would be absolutely > >> > awesome!) > > >> > On Jan 4, 2:50 pm, Richard Quadling wrote: > >> >> Hi. > > >> >> Using open4 on Windows seems to be an issue. > > >> >> (in D:/Personal > >> >> Files/Downloads/Software/Programming/Javascript/prototype) > >> >> mkdir -p D:/Personal > >> >> Files/Downloads/Software/Programming/Javascript/prototype/test/unit/tmp > >> >> rm -rf D:/Personal > >> >> Files/Downloads/Software/Programming/Javascript/prototype/doc > > >> >> Parsing source files: D:/Personal > >> >> Files/Downloads/Software/Programming/Javascript/prototype/test/unit/tmp/pro > >> >> totype.temp.js. > >> >> Parsing completed in 46.735 seconds. > > >> >> Generating documentation to: D:/Personal > >> >> Files/Downloads/Software/Programming/Javascript/prototype/doc. > > >> >> rake aborted! > >> >> uninitialized constant Fcntl::F_SETFD > >> >> D:/Personal > >> >> Files/Downloads/Software/Programming/Javascript/prototype/rakefile:75:in > >> >> `build_doc_for' > >> >> (See full trace by running task with --trace) > > >> Isn't Pygments python? Do I need to have Python as well now? > > >>http://pygments.org/docs/lexers/ > > >> -- > >> - > >> 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=ZEND002498&r=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 > > athttp://groups.google.com/group/prototype-core?hl=en > > I think I'll skip all of this and use the website instead. > > I'd much rather have DocBook V5 orientated documentation. > > But then the dox wouldn't be inline. > > Swings and roundabouts. > > -- > - > 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=ZEND002498&r=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: rake doc's error.
Yes. Or you can use coderay instead, but I haven't included a stylesheet for that yet. We choose pygments as it's already the default for github and Jekyll. Thought this consistency might end up being useful. Also Pygment's a real lexer. Best, Tobie On Jan 5, 12:00 pm, Richard Quadling wrote: > 2010/1/5 Tobie Langel : > > > > > > > Hi Richard. > > > You'll have to use another syntax highlighter ATM or build the > > documentation without syntax highlighting. > > > To do so, just modify the rake task like so: > > >http://gist.github.com/266858 > > > Hope this helps. > > > Best, > > > Tobie > > > (Also, a patch to make pygments work on windows would be absolutely > > awesome!) > > > On Jan 4, 2:50 pm, Richard Quadling wrote: > >> Hi. > > >> Using open4 on Windows seems to be an issue. > > >> (in D:/Personal Files/Downloads/Software/Programming/Javascript/prototype) > >> mkdir -p D:/Personal > >> Files/Downloads/Software/Programming/Javascript/prototype/test/unit/tmp > >> rm -rf D:/Personal > >> Files/Downloads/Software/Programming/Javascript/prototype/doc > > >> Parsing source files: D:/Personal > >> Files/Downloads/Software/Programming/Javascript/prototype/test/unit/tmp/pro > >> totype.temp.js. > >> Parsing completed in 46.735 seconds. > > >> Generating documentation to: D:/Personal > >> Files/Downloads/Software/Programming/Javascript/prototype/doc. > > >> rake aborted! > >> uninitialized constant Fcntl::F_SETFD > >> D:/Personal > >> Files/Downloads/Software/Programming/Javascript/prototype/rakefile:75:in > >> `build_doc_for' > >> (See full trace by running task with --trace) > > Isn't Pygments python? Do I need to have Python as well now? > > http://pygments.org/docs/lexers/ > > -- > - > 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=ZEND002498&r=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: rake doc's error.
Hi Richard. You'll have to use another syntax highlighter ATM or build the documentation without syntax highlighting. To do so, just modify the rake task like so: http://gist.github.com/266858 Hope this helps. Best, Tobie (Also, a patch to make pygments work on windows would be absolutely awesome!) On Jan 4, 2:50 pm, Richard Quadling wrote: > Hi. > > Using open4 on Windows seems to be an issue. > > (in D:/Personal Files/Downloads/Software/Programming/Javascript/prototype) > mkdir -p D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/test/unit/tmp > rm -rf D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/doc > > Parsing source files: D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/test/unit/tmp/pro > totype.temp.js. > Parsing completed in 46.735 seconds. > > Generating documentation to: D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/doc. > > rake aborted! > uninitialized constant Fcntl::F_SETFD > D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/rakefile:75:in > `build_doc_for' > (See full trace by running task with --trace) > > I've added popen4 and systemu (no difference). > > With trace ... > > (in D:/Personal Files/Downloads/Software/Programming/Javascript/prototype) > ** Invoke doc (first_time) > ** Invoke doc:build (first_time) > ** Invoke doc:require (first_time) > ** Execute doc:require > ** Execute doc:build > mkdir -p D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/test/unit/tmp > rm -rf D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/doc > > Parsing source files: D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/test/unit/tmp/pro > totype.temp.js. > Parsing completed in 46.985 seconds. > > Generating documentation to: D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/doc. > > rake aborted! > uninitialized constant Fcntl::F_SETFD > C:/Ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2503:in `const_missing' > C:/Ruby/lib/ruby/gems/1.8/gems/open4-1.0.1/lib/open4.rb:20:in `popen4' > D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/vendor/pdoc/lib/. > ./vendor/albino.rb:64:in > `execute' > D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/vendor/pdoc/lib/. > ./vendor/albino.rb:74:in > `colorize' > D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/vendor/pdoc/lib/p > doc/generators/html/syntax_highlighter.rb:33:in > `highlight_block' > D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/vendor/pdoc/lib/p > doc/generators/html/syntax_highlighter.rb:17:in > `parse' > D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/vendor/pdoc/lib/p > doc/generators/html/syntax_highlighter.rb:14:in > `gsub' > D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/vendor/pdoc/lib/p > doc/generators/html/syntax_highlighter.rb:14:in > `parse' > D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/vendor/pdoc/lib/p > doc/generators/html/helpers.rb:24:in > `htmlize' > D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/vendor/pdoc/lib/p > doc/generators/html/website.rb:154:in > `index_page_content' > D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/vendor/pdoc/lib/p > doc/generators/html/website.rb:75:in > `render_index' > D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/vendor/pdoc/lib/p > doc/generators/html/website.rb:62:in > `render' > D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/vendor/pdoc/lib/p > doc/runner.rb:36:in > `render' > D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/vendor/pdoc/lib/p > doc/runner.rb:43:in > `run' > D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/vendor/pdoc/lib/p > doc.rb:21:in > `run' > D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/rakefile:75:in > `build_doc_for' > D:/Personal > Files/Downloads/Software/Programming/Javascript/prototype/rakefile:163 > C:/Ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:636:in `call' > C:/Ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:636:in `execute' > C:/Ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:631:in `each' > C:/Ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:631:in `execute' > C:/Ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:597: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.7/lib/rake.rb:590:in > `invoke_with_call_chain' > C:/Ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:607:in > `invoke_prerequisites' > C:/Ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:604:in `each' > C:/Ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:604:in > `invoke_prerequisites' > C:/Ruby/lib
[Prototype-core] Re: parameters Encoding differents in Ajax Request
OP should try:
new Ajax.Request('http://www.test.com/search.php', {
method: 'get',
onSuccess: function(){...},
parameters: {
search: 'bogotá'
},
onFailure: function(){...}
});
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: An invalid or illegal string was specified" code: "12
Sorry you're having trouble. This mailing list is reserved for development purposes. Please direct assistance requests to http://groups.google.com/group/prototype-scriptaculous Thank you. Tobie On Dec 16, 4:11 am, Wen wrote: > Hi > I was trying to use protoaculous1.8.3.min.js > like I did before in my template, include it in the following format > type="text/javascript"> > > but then I got the error message "An invalid or illegal string was > specified" code: "12" > > Don't know what's the error... Does anyone here know how to solve the > issue? > > Thanks in advance. > Wen -- You received this message because you are subscribed to the Google 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
Doc related tickets have been moved to their own Lighthouse project: https://prototype.lighthouseapp.com/projects/42103-prototype-documentation/overview Best, Tobie On Dec 4, 8:49 pm, Mike Rumble wrote: > These tickets seem to have been deleted from Lighthouse. > > Any reason for this? Was there a problem with the patches being > submitted? > > Thanks, > Mike. > > On Nov 17, 9:56 pm, "T.J. Crowder" wrote: > > > > > 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 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" 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] Re: Native JSON breakage
Hi, Bob. Thanks for your post. We'll be including fixes for native JSON in Prototype 1.7, a prerelease of which is just around the corner. I understand your frustration with this issue. It's on our top priority list. 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: Support full HTML set in (un)escapeHTML
We previously used different variants of that and moved away from it.
It's slow and full of inconsistencies across browsers.
On Nov 24, 1:37 am, disccomp wrote:
> How about this sweet little scripty I found[1], call it a textarea
> hack:
>
> function html_entity_decode(str) {
> var ta=document.createElement("textarea");
> ta.innerHTML=str.replace(//g,">");
> return ta.value;
>
> }
>
> [1]http://javascript.internet.com/snippets/convert-html-entities.html#
--
You received this message because you are subscribed to the Google 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
Good point (and sorry if the tone of my earlier post came out wrong, that wasn't my intention). There's indeed a number of entities which are part of the HTL 4.01 spec [1]. It's legitimate to want to be able to convert those, notably when dealing with legacy or external content. However, given the sheer size of the code compared its usage (now that utf-8 is ubiquitous), I don't think this belongs in Prototype core. Would be welcomed as a plugin, though. Best, Tobie [1] http://www.w3.org/TR/html401/sgml/entities.html -- You received this message because you are subscribed to the Google 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
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: Function.EMPTY and Function.K
Hi, Andrew.
As previously mentioned, K is ambiguous, as it can mean both:
function K(arg) { return arg; }
or:
function K(arg) { return function() { return arg; }; }
depending on your reference (Tcl for the former, combinatory logic for
the latter).
My vote therefore goes for using Function.IDENTITY.
I'm also strongly in favor of using uppercase for constant-like
objects. Given the language, this is of course purely conventional
(much like the underscore prefix for private methods). It's a very
useful nonetheless.
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: Units Of Measurement Options Stated Using Lowest Common Denominator Unit Practical
For the record, the unit of time measurement in Ruby is seconds, which explains the reason behind that choice for Prototype. Given the backwards compatibility issues, and the benefits of using seconds rather than milliseconds in most but edge cases, there's litte chance of seeing that change. Best, Tobie On Oct 10, 2:30 pm, "T.J. Crowder" wrote: > 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 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 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: Suggestion: "Prototype.Compatibility" (was "Units of Measurement...")
> Does that update helper identify where code accessed Hash objects. Yes, provided there had been set before. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google 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...")
[OT] Robert, had you tried the update helper to help out with this migration? On Oct 12, 2:34 am, Robert Kieffer wrote: > Regarding "added weight of compatibility stuff I will never use", one > of the main reasons I proposed this is that allows devlopers to decide > on a per-case basis when and where to support backward compatibility. > I.e. if the code .vs. benefit analysis doesn't make sense, don't > support it. > > T.J, You make a good point about testing. Testing complexity to be > part of the benefit analysis. > > I provided the delay() method above as one example of where this might > make sense. But let me point to another example where I think > conditional backward compatibility would have been tremendously > valuable: The Hash API change that happened in v1.6. This broke a > _lot_ of code, and was a significant hurdle to teams that wanted to > upgrade. At Zenbe, the 1.6 release put us in a real bind - it had a > lot of exciting new features, features that we desperately wanted > (e.g. real subclassing support), but we simply couldn't afford the > time required to identify and fix the 100's of dependencies we had on > Hash in our code base. We ended up using a monkey-patched version of > 1.6 on our production site for several months, while using the "real" > version of 1.6 in development and testing. It would have been great > to have a switchable compatibility option in that case. > > I'll risk shooting my own idea in the foot by pointing out that the > biggest issue with this idea is not what effect it has on the code, > but rather slippery slope it starts down. Once you start providing > Compatibility support for one or two features, users are going to > start clamoring for it all over the place. There should probably be > some firm guidelines about what factors decide whether or not a > feature supports this, and for what versions Compatibility support > will be provided for. (E.g. "Compatibility is only offered for the > previous dot-release" or something like that.) > > On Oct 11, 2:46 pm, Allen Madsen wrote: > > > > > I have to agree with T.J. In addition to complexity, there is also a > > concern for size. If I am using the newest version of the code, why > > would I want the added weight of compatibility stuff I will never use? > > > 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: Event#element deprecated?
> > Where? Certainly not in the old API > > docs:http://prototypejs.org/api/event/element. > > I thought I was going crazy. Looks like we haven't communicated this too well so far. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google 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?
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 wrote: > On Oct 7, 12:34 pm, Tobie Langel 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?
> 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). > Maybe it's just the way my brains > are wired, but `findElement` for me is associated with traversing or > searching something (i.e. "find" verb). It feels strange to say - `var > targetEl = e.findElement();` when my intentions are not to _search_ > for something, but merely _retrieve_ it. Well, both Evemt#element and Event#findElement without argument often return the element that's right above the target node (which as per specs can be a textnode). So whether or not we're finding vs. retrieving is questionable, but I get your point. > 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. > What do you think? As I said in my previous comment, worth discussing in the context of Sam's upcoming work on 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. It made sense to extend it for the reasons I explained above. And it's unquestionably much better than Event#element. 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: Observing objects
Hi. I really don't understand how polluting the document object with otherwise useless elements is a better solution than using namespaces. Here's a revamped version which implements basic namespacing: http://gist.github.com/204012 As your namespacing needs are probably specific, I encourage you to try out different patterns and decide which one is a better fit given your specific domain. Also, I think this conversation now really belongs in the Proto- Scripty group[1] where others could benefit from it. Best, Tobie [1] http://groups.google.com/group/prototype-scriptaculous --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google 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: Observing objects
Hi again,
For the record, custom events need to be namespaced ('foo:changed',
not 'changed').
The way you handle namespacing is entirely up to you. It can be
instance based, class based or arbitrary.
It just needs to be provided by the class / instance itself, and the
Observable mixin has to take it into account.
Best,
Tobie
On Oct 7, 9:50 am, Jim Higson wrote:
> In another thread I wrote:
>
> > The biggest problem with events at the moment is only Elements can fire
> > them. This makes MVC difficult because the Model (javascript objects) not
> > the view (HTML elements) would ideally fire the events.
>
> > For Prototype2, maybe there should be an observable mixin. When mixed in,
> > any object can fire events.
>
> To which Toby replied:
>
> > This is already possible with our current event system using the
> > `document` object as broker.
>
> > Please see a basic, untested implementation here:
>
> >http://gist.github.com/203193
>
> The implementation linked here is good, but isn't there a problem with:
>
> //Foo mixes in Observable
> var a = new Foo();
> var b = new Foo();
>
> a.observe( 'change', function(){alert( 'a changed' )};
> b.observe( 'change', function(){alert( 'b changed' )};
>
> a.fire('change');
>
> // both listeners are now notified even though only object a fired.
>
> One fix might be to do:
>
> line22:
> document.fire( this.somethingUnique + eventName, data);
>
> line 26:
> document.observe( this.somethingUnique + eventName, callback);
>
> But I don't know where the somethingUnique would come from.
>
> 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: Event#element deprecated?
Jim, Ngan. This is already possible with our current event system using the `document` object as broker. Please see a basic, untested implementation here: http://gist.github.com/203193 If you ant to discuss this in more details, please do kindly start another thread. Thank you. 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: Event#element deprecated?
Hi. Please allow me to clarify the issue here. Event#element was deprecated because of it's inconsistency with the rest of our API (which systematically uses verbs for method names). There were two options for renaming this method: 1) add an Event#getElement method or 2) reuse the existing Element#findElement method. Given precedence in the framework for methods accepting a selector to also work without arguments (As far as I known, that's the case for all methods returning a single element) the latter was chosen. In retrospect I think it was a good choice. It strengthened consistency across the framework for using methods with and without a selector argument. It also made event delegation one step closer by introducing Event#findElement as one of the key methods of the event object. I know that Event#findElement currently calls Event#element. This is an implementation detail, it's obviously temporary, and shouldn't distract us from the main issue at hand here which is our API. Finally, Sam is working on a new API for event delegation in 1.7 / 2.0. If changes are to be made, they should be discussed once he's posted his initial implementation. Hope this helps. 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: Suggestion: String#isEmpty instead String#empty
Hi all. Can we please try to stay on topic. This thread's topic is about renaming methods whose ruby counterparts were suffixed with a question mark. It would be very helpful to list all of the methods which fall in that category so we have a better idea of the implications of such a change. For discussing deprecation of particular methods, please create another thread. Please keep in mind that deprecation makes upgrading harder and is generally best avoided. 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: Suggestion: String#isEmpty instead String#empty
Hi everyone. There are various reasons to keep those methods around, some of which are: 1) Follow the Principle Of Least Surprise (POLS) by exposing a similar API across the whole platform, 2) simplify duck-typing, and 3) abstract implementation details (for example, Hash#isEmpty isn't as trivial to write as Array#isEmpty). Some of these methods clearly deserve to have better names. We're going to introduce naming changes in the upcoming versions of Prototype. Here's a tentative schedule using Array#(empty|isEmpty) as an example: In version 1.7: - Array#empty is renamed Array#isEmpty. - Array#empty, an alias of Array#isEmpty is added to source. - Array#empty is tagged as "deprecated" and "alias of" in the documentation. - Array#empty is marked as deprecated in the upgrade helper. In version 2.0: - Array#empty is removed from source code. - Array#empty is marked as removed in the upgrade helper. - Array#empty is completely removed from the documentation. It's obviously applicable to other method names. I don't see any incentives to remove those methods altogether. If you don't want to use them, just don't. Thanks all for our input. 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: Suggestion: String#isEmpty instead String#empty
It's specifically because JavaScript disallows certain characters in identifiers (such as '?', for example), that we have decided to prefix certain methods with 'is', 'has', etc. for version 1.7 / 2.0. Without neither those characters nor adequate prefixes, the name of certains methods are ambiguous and misleading. 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: $H({}).get('__proto__') in Firefox =)
> Sorry, I'm not following. How does prefixing a key avoid object > creation? We can't inject stuff directly onto a hash instance. We > still need an object for that. Not necessarily. Though that might make some requests more expensive. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google 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: $H({}).get('__proto__') in Firefox =)
> Why not to patch Hash to use some prefix for keys? That was my plan for 1.7, actually. It fixes that issue and also avoids creating an extra, internal object. Good to see that we're on the same page, here. 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: Private methods for prototype class
Hi, Ngan. Sorry you're having trouble. This mailing list is reserved for development purposes. Please direct assistance requests to http://groups.google.com/group/prototype-scriptaculous Thank you. 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: A more efficient $super for Prototype 2
> T.J., could you point me to the exact section specifying `name` on > Function objects? I don't remember seeing it in ES5. That's because it's not part of that spec. If I remember correctly it was discussed for Harmony. 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: A more efficient $super for Prototype 2
Allen, You can do this already pretty easily.
Just do:
Var A = Class.create(function(){
var privateVar = 0;
function privateFunction(){}
function nifty(){
privateFunction();
privateVar = 3;
}
return {nifty: nifty};
}());
Just note that in both cases, those private variables are `class`
variables
shared between all instances.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google 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: Simplify working with Hash selections
Hi, Julian. Thanks for your suggestions. There's indeed an issue when using some of Enumerable's methods with hashes. This should be addressed in n upcoming version of Prototype. the way to address this is simply to define those methods on Hash itself and make sure they return a hash instance too. Any kind of Array#toHash implementation is too application specific to be part of Core. 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: Array#intersect and Array#without inconsistency
> Tobie, > Do you have any input on this? Yes, I'm in favor of strict equality. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google 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: String.toObject and Object.toString
Hi, Joran. Thank you for your suggestions. Unfortunately, there's a number of reasons why they're not practical and why they will not be implemented in the framework.. 1. We have a strict policy of not shadowing standardized properties/ methods of native objects. We're busy right now cleaning up our act towards methods which are in the process of being standardized in EcmaScript 5. 2. There's a number of issues related to over-writing properties of the Object.prototype. It notably prevents using vanilla objects as hashes. It also breaks for...in loops which don't check internally for hasOwnProperty. 3. Finally, JSON is a subset of JavaScript (which doesn't contain functions, for example). So an API that would imply otherwise would just be misleading. Thanks for your suggestions nonetheless. 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: Copying arguments
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: Copying arguments
Robert, Could you kindly point me towards that patch. I don't think it's the one kangax mentioned. Thanks, 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: Copying arguments
Hi, kangax. I understand and appreciate your eagerness (I feel the same). However, for the benefit of our users and the code base, I think it's important that we: 1) handle the most pressing issues at hand first (mainly doc related), 2) agree on stylistic issues (this patch clearly doesn't look very prototypish to me), and 3) discuss performance versus LOC issues and reformat that patch accordingly. Let's focus our attention where it's most needed at the moment: completing the documentation. Thanks for your understanding. 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: Copying arguments
We have a rewrite of function.js waiting to be included. It does
something even smarter thanks to a great idea by Broofa.
We'll add it in as soon as we've handled our pdoc and website issues.
Best,
Tobie
On Sep 4, 5:03 pm, "T.J. Crowder" wrote:
> 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-crea...
> --
> T.J. Crowder
> tj / crowder software / comwww.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: $ and $$ in top-level scope
Yes, these are part of the plans. On Aug 31, 11:58 am, Radoslav Stankov wrote: > I really liked the Mootools solution, they have Element.get as an > alias of $. > I'm wondering if, it will be good idea for Prototype 2.0, Element to > become something like Prototype.Element and only if user wants Element > to be exposed as global Element object. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google 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: $ and $$ in top-level scope
A more elegant solution to this problem is to use a closure around the library, avoid using free variables internally and define an numbers of exports for external consumption. Such changes are planned for Prototype 2.0. Hopes this helps. 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: Suggested addition to Function Methods: .repeat(seconds[, arg...])
> Unless $break is removed from Prototype altogether, I don't see how > this is an issue. That was the idea. I don't know how feasible it is for Hash, but it certainly is for Array. 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: Custom event firing with document from iFrame issues
Please open a ticket with your issue.
Thank you.
Tobie
On Aug 27, 11:37 pm, Ngan wrote:
> Hi I came an issue with Firefox (works for Safari and IE8 correctly)
> RE: Event.observe(...) vs ___.observe(...). You'll need both of the
> files below.
>
> Notice that firefox only receives the fire when it is using "observe"
> directly on the iframe's document element. Whereas Event.observe does
> not work. Safari and IE8 picks up both observes and prints out both
> messages to console.
>
> FILE: test.html -
>
>
>
>
> Event.observe(window, 'load', function() {
> $('ifr').writeAttribute('src', 'test2.html');});
>
> function register(ifrDocument) {
> ifrDocument.observe('custom:event', function() {
> console.info('received fire 1');
> });
> Event.observe(ifrDocument, 'custom:event', function() {
> console.info('recieved fire 2');
> });}
>
>
>
>
>
>
>
>
> FILE: test2.html -
>
>
>
>
> Event.observe(window, 'load', function() {
> parent.register(document);
> console.info('firing event from iframe...');
> document.fire('custom:event');});
>
>
>
>
>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google 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...])
> *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: Future extensions to the Template class
For the record, here's my initial email which I mistakenly sent (twice!) to T.J. instead of to the whole list: --- Hi, TJ. I thought about your suggestion some more (regarding escaping asterisk- prefixed property names). It's feels very much too application specific to me. Also, it couples the LANG section to the DOM. As we'd like to remove all DOM dependencies out of the LANG section for Prototype 2.0 to allow using it server side, this is better avoided. Would there be a simple solution to allow for customizing such behaviour using an optional reviver or through subclassing Template? Finally, I'm all for changes improving performance of Template. In you benchmarks, can you make that it doesn't hurt the perf of String#interpolate, though. Best, Tobie On --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google 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...])
Food for thought: 1. We would like to completely decouple native and host objects in the LANG section for version 1.7. `setTimeout` and `setInterval` are host objects... 2. We're planning strict ES 5 compliance of enumerables for 1.7. that implies removing $break. Best, Tobie On Aug 27, 5:29 pm, "T.J. Crowder" wrote: > 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 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: Event#isLeftClick works only for mouse down/up in IE, may be this information will be useful in documentation?
Patch welcomed! ;-) On Aug 25, 11:18 pm, Yaffle wrote: > ??? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Element.readAttribute improvement for IE
Thanks! Please kindly open a ticket for this issue here:https:// prototype.lighthouseapp.com/projects/8886-prototype/tickets/new Best, Tobie On Jul 23, 1:47 am, Ilya Furman wrote: > There is a bug with Element.readAttribute for IE. While trying to read > dynamically set attribute method fails since those attributes have no > function wrapper. > > I wrote a little patch and test for that, please find it > attachedhttp://groups.google.com/group/prototype-core/web/0001-Fixes-readAttr... > > We using Prototype a lot in our Acunote tool (http://acunote.com), so > its about time to start contributing to Prototype :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google 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: General Usage / Consumption questions
Hi Bryant, Thanks for your post. I suspect you are mainly worried about license issues and possible copyright infringements. Since it's inception, five developers in total have had commit rights to the Prototype repository, all of which are still actively contributing to the project. All patches are reviewed by one at least one of these five committers before inclusion in the library. Complex/large patches are discussed collectively before inclusion. When patches contain copyrighted code, copyright owners are contacted in order to obtain inclusion permission under the terms of Prototype's MIT license. Our reviewing process also verifies code quality and adherence to our style guidelines (which we are in the process of formalizing). Hope this answers your questions. If not, please don't hesitate to ask again. Best, Tobie On Jul 21, 12:49 am, bhlee27 wrote: > Hello, > I'm currently working with my development team in consuming Prototype > JS for our GUI and before including into my product I needed to verify > a couple items: > > 1. Is there a policy / procedure in place on how code is maintained? > tMainly need some assurances that code that we're using doesn't > contain any contaminated code or code that wasn't originally written > by the developer. > > 2. Is there some verification (i.e. code scans) done to ensure that > there isn't any violation of your policies (assuming the answer to #1 > is yes). > > Thanks in advance, > Bryant Lee > Development Manager @ IBM --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Element.fire -> Starck Overflow
Nope. Using it in production in various apps without issues. You might want to make a reduced failing testcase and submit it to the Prototype mailing list[1]. Best, Tobie [1] http://groups.google.com/group/prototype-scriptaculous On Jul 20, 8:25 pm, Luisgo wrote: > Has anyone experienced Stack Overflow errors in IE (all versions) when > using Element.fire? > > I've managed to narrow down the error to a call to fire but still > haven't managed to get pass that point. > > 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: IE6: This page contains both secure and nonsecure items.
That's a blocker and will be fixed before 1.6. final. Best, Tobie On Jun 30, 5:52 pm, "Ryan Holliday (wrh2)" wrote: > I filed a bug on this issue with a suggested fix (https:// > prototype.lighthouseapp.com/projects/8886/tickets/648-ssl-error-on-ie6- > with-161_rc2). I'm not sure what the status is for getting this > resolved for 1.6.1, although we've been running successfully with the > proposed fix for several months in a production environment. > > > > > 2009/6/29 Diodeus > > > Hi gang, > > > When testing with 1.6.1_rc2 and 1.6.1_rc3 I got complaints from some > > corporate clients that they're getting the following dialog on IE6. > > > "This page contains both secure and nonsecure items." > > > I managed to test this, and confirmed this is the case. Older versions > > of Prototype do not cause this problem. I'm not sure why it's > > happening. I searched through rc3 and other than comments I didn't > > find any obvious culprits. > > > So I cannot concurrently support both IE8 and IE6 users. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google 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...])
> 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 dislike, but
that shouldn't make you throw away all of the work that's been put
into previous solutions.
FWIW, I just noticed a patch wasn't applied to PE in current trunk
(it's missing a throw statement).
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: Suggested addition to Function Methods: .repeat(seconds[, arg...])
Hi Rick, hi Robert.
Fully agree regarding PE. It does however handle issues a regular
setInterval doesn't (as you mentioned).
It's clearly an area which would need refinement, but that's better
done in a backwards compatible way.
Personally, I'd love to see PE implemented as a method of Function
instances.
So since this is the core mailing list, I'm trying to give directions
on how it could be best implemented given legacy constraints and
consistency with the rest of the API.
Clearly, consistency with Function#defer and Function#delay would
imply returning a setInterval index. Unfortunately, since setTimeout
is used instead of setInterval, this isn't possible.
Maybe the simplest solution would be to make Function#repeat return an
instance of PE. Implementation would then be roughly:
Function.prototype.repeat = function(interval) {
return new PeriodicalExecuter(this, interval);
}
Note that in that case, modifying Function#delay and Function#defer to
return a PE-like object instance with a stop method would make more
sense API wise, but at the expense of a larger memory footprint and
backwards compatibility.
As you can see, making the right choice isn't simple.
Best,
Tobie
On Jun 24, 11:28 pm, Rick Waldron wrote:
> Tobie,
>
> I had in fact looked into PeriodicalExecuter and to be perfectly honest,
> with no offense intended, i think it's usage syntax is hideous which is what
> led me to writing my own Function.prototype method instead, taking
> inspiration from .delay()
>
> It doesnt matter to me whether or not .repeat() makes it into the prototype
> core - I will always have it at my disposal, I simply wanted to share the
> concept with the group.
>
> I think everything I've said sounds like I'm in a bad mood, sorry about
> that! :D
>
> Rick
>
> On Wed, Jun 24, 2009 at 12:53 PM, Tobie Langel wrote:
>
>
>
>
>
> > Just to clarify the above: Prototype Core already contains a similar
> > functionality: PeriodicalExecuter. The API is different but the
> > functionality is the same.
>
> > I'd strongly suggest looking into combining both approaches if you
> > want your suggestion to be included in core and not just stay a thread
> > in the mailing list. :)
>
> > Best,
>
> > Tobie
>
> > On Jun 24, 4:50 pm, Rick Waldron wrote:
> > > I've subbed my implementation with your to do some use-case testing. I'll
> > > report back anything of interest as I go along.
>
> > > Rick
>
> > > On Wed, Jun 24, 2009 at 10:49 AM, Rick Waldron > >wrote:
>
> > > > This is fantastic feedback - thanks!
>
> > > > On Wed, Jun 24, 2009 at 9:55 AM, Robert Kieffer
> > wrote:
>
> > > >> I can't say I'm a big fan of this. For several reasons.
>
> > > >> First, it's just a cosmetic replacement for setInterval(myfunction
> > > >> (...).bind(), ...) which simply isn't all that bad.
>
> > > >> Second, I'm not a fan of setInterval in general. I've seen some
> > > >> rather nasty behavior with calls queuing up if the invoked function
> > > >> takes longer than the delay to execute. In particular, this seems to
> > > >> be an issue if you do something like put a laptop to sleep. (But
> > > >> maybe others haven't seen this problem???) Thus, I prefer to use a
> > > >> self-invoking timeout like so:
>
> > > >> function myFunction() {
> > > >> // do stuff ...
> > > >> // call ourselves again
> > > >> if (/*we want to continue?*/) setTimeout(myFunction, 1000)
> > > >> }
>
> > > >> This doesn't call the function at exactly one second intervals, but
> > > >> that type of accuracy is rarely important. Instead, it guarantees you
> > > >> have at least one second of delay between invocations, which for
> > > >> distributing cpu load or polling (the more common cases where
> > > >> setInterval might be used), is more desireable.
>
> > > >> Finally, as Joe T. points out, there should be a way of cancelling the
> > > >> interval that doesn't require the user to store the returned value
> > > >> (*that* is what I find most annoying, not the syntax of
> > > >> "setInterval").
>
> > > >> Thus, I'd suggest this instead:
>
> > > >> Object.extend(Function.prototype, {
> > > >> repeat: function(delay) {
> > > >> // Reset state
> > > >> if (this._repeat
[Prototype-core] Re: Suggested addition to Function Methods: .repeat(seconds[, arg...])
Just to clarify the above: Prototype Core already contains a similar
functionality: PeriodicalExecuter. The API is different but the
functionality is the same.
I'd strongly suggest looking into combining both approaches if you
want your suggestion to be included in core and not just stay a thread
in the mailing list. :)
Best,
Tobie
On Jun 24, 4:50 pm, Rick Waldron wrote:
> I've subbed my implementation with your to do some use-case testing. I'll
> report back anything of interest as I go along.
>
> Rick
>
> On Wed, Jun 24, 2009 at 10:49 AM, Rick Waldron wrote:
>
>
>
> > This is fantastic feedback - thanks!
>
> > On Wed, Jun 24, 2009 at 9:55 AM, Robert Kieffer wrote:
>
> >> I can't say I'm a big fan of this. For several reasons.
>
> >> First, it's just a cosmetic replacement for setInterval(myfunction
> >> (...).bind(), ...) which simply isn't all that bad.
>
> >> Second, I'm not a fan of setInterval in general. I've seen some
> >> rather nasty behavior with calls queuing up if the invoked function
> >> takes longer than the delay to execute. In particular, this seems to
> >> be an issue if you do something like put a laptop to sleep. (But
> >> maybe others haven't seen this problem???) Thus, I prefer to use a
> >> self-invoking timeout like so:
>
> >> function myFunction() {
> >> // do stuff ...
> >> // call ourselves again
> >> if (/*we want to continue?*/) setTimeout(myFunction, 1000)
> >> }
>
> >> This doesn't call the function at exactly one second intervals, but
> >> that type of accuracy is rarely important. Instead, it guarantees you
> >> have at least one second of delay between invocations, which for
> >> distributing cpu load or polling (the more common cases where
> >> setInterval might be used), is more desireable.
>
> >> Finally, as Joe T. points out, there should be a way of cancelling the
> >> interval that doesn't require the user to store the returned value
> >> (*that* is what I find most annoying, not the syntax of
> >> "setInterval").
>
> >> Thus, I'd suggest this instead:
>
> >> Object.extend(Function.prototype, {
> >> repeat: function(delay) {
> >> // Reset state
> >> if (this._repeater) delete this._repeater;
> >> this._repeatTimeout = clearTimeout(this._repeatTimeout);
>
> >> if (!delay) return; // (stop repeating if no args or delay==0)
>
> >> // Create setTimeout-based invoker
> >> var _method = this;
> >> if (!this._repeater) this._repeater = function() {
> >> // Let _method cancel repeat by doing "return false;"
> >> if (_method() !== false) setTimeout(_method._repeater, delay);
> >> }
>
> >> // Start repeating
> >> this._repeatTimeout = setTimeout(this._repeater, delay);
> >> },
>
> >> stopRepeating: function() {
> >> this.repeat();
> >> }
> >> });
>
> >> For example:
>
> >> var count = 0;
> >> function foo() {
> >> console.log(count++);
> >> return count < 10; // Return "false" when count >= 10 to cancel
> >> the repeat
> >> }
>
> >> // Start repeating 1/sec
> >> foo.repeat(1000);
> >> //... some time later change interval to 2/sec
> >> foo.repeat(500);
> >> // ... later still stop repeating.
> >> foo.stopRepeating();
>
> >> As you can see, this implementation of repeat() does a lot more for
> >> you than simply alias'ing "setInterval":
> >> - It guarantees your function is only invoked by one interval
> >> - It makes changing the interval or cancelling it altogether
> >> trivial.
> >> - It allows you to conditionally cancel the repeat from w/in the
> >> function itself.
>
> >> The only thing missing is the bind() behavior but, well, that's what
> >> bind is for. If you need to bind arguments, just bind() your
> >> arguments first.
>
> >> On Jun 23, 8:25 am, Rick Waldron wrote:
> >> > I detest the way setInterval() looks, so I came up with this... have
> >> been
> >> > using it my personal JS for some time.
>
> >> > Object.extend(Function.prototype, {
> >> > repeat: function() {
> >> > var __method = this, args = $A(arguments), interval = args.shift() *
> >> > 1000;
> >> > return window.setInterval(function() {
> >> > return __method.apply(__method, args);
> >> > }, interval );
> >> > }
>
> >> > });
>
> >> > // usage:
> >> > var _pollInt = 0;
> >> > function repetiousPollFn() {
> >> > console.log(_pollInt++);
>
> >> > }
>
> >> > repetiousPollFn.repeat(.5);
>
> >> > Will, of course, repeat repetiousPollFn() every half second.
>
> >> > Almost identical to .delay(), except that it returns setInterval instead
> >> of
> >> > setTimeout. One thing I intend to add is support for clearInterval,
> >> however
> >> > I figured I'd at least bring it up here first. I've never
> >> > proposed/contributed here before (i'm a lurker of the list :D ) - any
> >> > guidance is appreciated.
>
> >> > Rick
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" g
[Prototype-core] Re: Suggested addition to Function Methods: .repeat(seconds[, arg...])
You might also want to look at the already existing
PeriodicalExecuter.
Any implementation of a Function#repeat API should take this in
account.
On Jun 24, 2:55 pm, "joe t." wrote:
> Only suggestion i can think of is that your method strongly implies a
> requirement that "repetitionsPollFn.repeat()" get assigned to a
> variable so it can be cleared later:
>
> var interval = repetitiousPollFn.repeat(0.5);
> // interval is the setInterval ID
>
> then later
> window.clearInterval(interval);
>
> i could also see potential for more "scheduling" options
> (repeatUntilTime, repeatXTimes, etc) built into your #repeat idea, but
> don't really have the time to flesh them out.
>
> i find it an interesting idea though. :)
> -joe t.
>
> On Jun 23, 11:25 am, Rick Waldron wrote:
>
>
>
> > I detest the way setInterval() looks, so I came up with this... have been
> > using it my personal JS for some time.
>
> > Object.extend(Function.prototype, {
> > repeat: function() {
> > var __method = this, args = $A(arguments), interval = args.shift() *
> > 1000;
> > return window.setInterval(function() {
> > return __method.apply(__method, args);
> > }, interval );
> > }
>
> > });
>
> > // usage:
> > var _pollInt = 0;
> > function repetiousPollFn() {
> > console.log(_pollInt++);
>
> > }
>
> > repetiousPollFn.repeat(.5);
>
> > Will, of course, repeat repetiousPollFn() every half second.
>
> > Almost identical to .delay(), except that it returns setInterval instead of
> > setTimeout. One thing I intend to add is support for clearInterval, however
> > I figured I'd at least bring it up here first. I've never
> > proposed/contributed here before (i'm a lurker of the list :D ) - any
> > guidance is appreciated.
>
> > Rick
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google 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: Changes under the hood to event handling
The former, I believe. I would tend to think that these changes would actually cause higher memory consumptions on one-paged applications (handlers of removed DOM nodes cannot be garbage collected). On Jun 23, 11:53 pm, Mike Rumble wrote: > I was having a poke around under the hood of the latest RC and noticed > some changes to event handling (I think the changes were actually made > for RC1, but none the less). > > The event handling system now uses the new Element Storage to cache > handlers, and I'm interested to learn the rationale for this. Was the > change made simply to adopt Element Storage or are there performance > benefits? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google 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: Ajax.Updater related question
Hi Anthony,
This mailing list is reserved for development purposes.
Instead, please use: http://groups.google.com/group/prototype-scriptaculous
Thanks!
Tobie
On Jun 1, 11:33 pm, anthony wrote:
> I have got a working example, but now I need to add something, and I
> am not sure how to do it.
>
> I have a function:
>
> function getAdjForm() {
> var params = Form.serialize($('createAdjForm'));
> new Ajax.Updater(
> "adjForm",
> "/link/to/somewhere",
> {method:'post',
> parameters: params});}
>
>
>
> My HTML
>
> .//Lots of options listed
>
> .
> .
> .
> More HTML
> .
> .
> .
>
>
>
> This works, and my text appears inside the
> . My problem is where I have the more HTML code, I need to have
> dynamic text appear there as well, but it is based on the same logic.
> Is there a way to do this w/o calling a second url in my function?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
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 JQuery's .live extension to prototype.
You might want to have a look at the API and implementation of
Event.observe.
Best,
Tobie
On May 28, 9:15 am, Luisgo wrote:
> Cool.
>
> Sorry for the questions but can you point me to an example of storing
> a handler for removal and removing it and an explanation of what you
> mean by adequate API?
>
> I'll work on it, just need a little guidance.
>
> Thanks!
>
> On May 28, 12:10 am, Tobie Langel wrote:
>
> > Hi,
>
> > You'll need to store the handler so you can remove it too, and provide
> > an adequate API for this.
>
> > Best,
>
> > Tobie
>
> > On May 28, 7:49 am, Luisgo wrote:
>
> > > So... here's a first pass. I forked the project committed the changes
> > > to my fork and sent a pull request to sstephenson for review. In the
> > > mean time, you can take a look and give me your feedback
> > > here:http://github.com/lgomez/prototype/commit/eb3fa460b2e850440b5aa89e525...
>
> > > This is my first patch and contribution ever to an open source project
> > > so please bare with me if you find some obvious mistakes. I also added
> > > a first iteration of a functional test.
>
> > > Thanks!
>
> > > On May 27, 8:42 pm, Luisgo wrote:
>
> > > > That makes a lot of sense! All the while I've been thinking of
> > > > extending the library when delegation makes all the sense and is
> > > > probably going to perform better. Nice.
>
> > > > Now, wouldn't it make sense to put this under Event.delegatedObserver
> > > > (selector, eventName, handler) ?
>
> > > > I think using the word 'observer' in there would help make it's
> > > > purpose clearer and I put it under Event for consistency.
>
> > > > What do you think?
>
> > > > I'll look into creating the patch as soon as I have some time off and
> > > > sharing it here to get your input.
>
> > > > Thanks!
>
> > > > On May 27, 7:40 pm, Samuel Lebeau wrote:
>
> > > > > Josh:
> > > > > I believe the `e.element()` line should use `Event#findElement`
> > > > > instead to walk the DOM tree up to find the first parent matching.
>
> > > > > i.e.:
> > > > > document.observe('click', function(e) {
> > > > > if (e.findElement('.test')) {
> > > > > console.log('clicked');
> > > > > }
> > > > > });
>
> > > > > Luisgo:
> > > > > I think it's definitely worth the effort, I've been personnally using
> > > > >
> > > > > this pattern successfully in many applications.
> > > > > In previous discussions, we ended up with the following signature:
>
> > > > > `Element.delegate(@element, selector, eventName, callback)`
>
> > > > > Then jQuery's `.live` query :
>
> > > > > `$(selector).live(eventName, callback);
>
> > > > > would become:
>
> > > > > document.delegate(selector, eventName, callback);
>
> > > > > IMO it should definitely be part of the framework.
>
> > > > > Best,
> > > > > Samuel.
>
> > > > > On 28 mai 09, at 03:31, Josh Powell wrote:
>
> > > > > > $(document).observe('click', function (e) {
> > > > > > if (e.element().match('.test')) {
> > > > > > console.log('clicked');
> > > > > > }
> > > > > > });
>
> > > > > > Ok, that's not tested. The e.element() line is probably wrong, but
> > > > > > it
> > > > > > accomplishes what .live() in jQuery does. You set an event handler
> > > > > > on
> > > > > > the document, which all events filter up to, and then check to see
> > > > > > if
> > > > > > the element that bubbled up the event matches your selector and
> > > > > > execute your code if it does.
>
> > > > > > Josh Powell
>
> > > > > > On May 27, 5:46 pm, Luisgo wrote:
> > > > > >> I have thought about creating an extension for prototype to emulate
> > > > > >> JQuery's ".live" behavior but, it not being available makes me
> > > > > >> think
> > > > > >> that maybe it's not possible or worth the effort.
>
> > > > > >> I know how to apply behaviors after changing the DOM but no one can
> > > > > >> deny .live is very handy.
>
> > > > > >> 1. Any thoughts on this?
> > > > > >> 2. Has anyone tried to implement it?
> > > > > >> 3. Can I help?
> > > > > >> 4. How would you implement it?
>
> > > > > >> I thought about extending both the selector (to keep an array of
> > > > > >> executed queries/CSS selectors) and Ajax.Request but this would not
> > > > > >> cover elements added dynamically that are NOT loaded through ajax.
>
> > > > > >> 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: Porting JQuery's .live extension to prototype.
Hi,
You'll need to store the handler so you can remove it too, and provide
an adequate API for this.
Best,
Tobie
On May 28, 7:49 am, Luisgo wrote:
> So... here's a first pass. I forked the project committed the changes
> to my fork and sent a pull request to sstephenson for review. In the
> mean time, you can take a look and give me your feedback
> here:http://github.com/lgomez/prototype/commit/eb3fa460b2e850440b5aa89e525...
>
> This is my first patch and contribution ever to an open source project
> so please bare with me if you find some obvious mistakes. I also added
> a first iteration of a functional test.
>
> Thanks!
>
> On May 27, 8:42 pm, Luisgo wrote:
>
> > That makes a lot of sense! All the while I've been thinking of
> > extending the library when delegation makes all the sense and is
> > probably going to perform better. Nice.
>
> > Now, wouldn't it make sense to put this under Event.delegatedObserver
> > (selector, eventName, handler) ?
>
> > I think using the word 'observer' in there would help make it's
> > purpose clearer and I put it under Event for consistency.
>
> > What do you think?
>
> > I'll look into creating the patch as soon as I have some time off and
> > sharing it here to get your input.
>
> > Thanks!
>
> > On May 27, 7:40 pm, Samuel Lebeau wrote:
>
> > > Josh:
> > > I believe the `e.element()` line should use `Event#findElement`
> > > instead to walk the DOM tree up to find the first parent matching.
>
> > > i.e.:
> > > document.observe('click', function(e) {
> > > if (e.findElement('.test')) {
> > > console.log('clicked');
> > > }
> > > });
>
> > > Luisgo:
> > > I think it's definitely worth the effort, I've been personnally using
> > > this pattern successfully in many applications.
> > > In previous discussions, we ended up with the following signature:
>
> > > `Element.delegate(@element, selector, eventName, callback)`
>
> > > Then jQuery's `.live` query :
>
> > > `$(selector).live(eventName, callback);
>
> > > would become:
>
> > > document.delegate(selector, eventName, callback);
>
> > > IMO it should definitely be part of the framework.
>
> > > Best,
> > > Samuel.
>
> > > On 28 mai 09, at 03:31, Josh Powell wrote:
>
> > > > $(document).observe('click', function (e) {
> > > > if (e.element().match('.test')) {
> > > > console.log('clicked');
> > > > }
> > > > });
>
> > > > Ok, that's not tested. The e.element() line is probably wrong, but it
> > > > accomplishes what .live() in jQuery does. You set an event handler on
> > > > the document, which all events filter up to, and then check to see if
> > > > the element that bubbled up the event matches your selector and
> > > > execute your code if it does.
>
> > > > Josh Powell
>
> > > > On May 27, 5:46 pm, Luisgo wrote:
> > > >> I have thought about creating an extension for prototype to emulate
> > > >> JQuery's ".live" behavior but, it not being available makes me think
> > > >> that maybe it's not possible or worth the effort.
>
> > > >> I know how to apply behaviors after changing the DOM but no one can
> > > >> deny .live is very handy.
>
> > > >> 1. Any thoughts on this?
> > > >> 2. Has anyone tried to implement it?
> > > >> 3. Can I help?
> > > >> 4. How would you implement it?
>
> > > >> I thought about extending both the selector (to keep an array of
> > > >> executed queries/CSS selectors) and Ajax.Request but this would not
> > > >> cover elements added dynamically that are NOT loaded through ajax.
>
> > > >> 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: Element.setOpacity have a strange behaviour on prototype 1.6.1RC2
For ref.: https://prototype.lighthouseapp.com/projects/8886/tickets/684 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Element.setOpacity have a strange behaviour on prototype 1.6.1RC2
Hi David, You'll need to open a ticket in LH and add your patch to it. Please mark it as an enhancement. Thank you! 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: Element.setOpacity have a strange behaviour on prototype 1.6.1RC2
> I will do the unit test but I think I need RoR to do that, so it could > take a couple of days because I did not know Rails. You just need Ruby, which comes bundled with OS 10.5 or is available as a one-click install for Windows. The tests are then just run from the command line. Regarding your initial question, I think there might be legacy versions of FF which had weird issues. 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: Element.setOpacity have a strange behaviour on prototype 1.6.1RC2
Have you tried running the unit tests in all browsers with your
changes?
On May 13, 12:32 pm, david wrote:
> The original setOpacity function just reset the opacity value in case
> the value is one. Which means that you use the class value (if
> exist) :
>
> setOpacity: function(element, value) {
> element = $(element);
> element.style.opacity = (value == 1 || value === '') ? '' :
> (value < 0.1) ? 0 : value;
> return element;
> },
>
> I perdsonnally think that the function should react this way:
>
> setOpacity: function(element, value) {
> element = $(element);
> element.style.opacity = (value === '') ? '' :
> (value < 0.1) ? 0 : (value > 0.9) ? 1 :value;
> return element;
> },
>
> My question is if the original function are used this way for a
> specific browser support?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google 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: Array.prototype.push.apply and "update" used by Function.prototype.bind
The former is much faster. Hence it's use!
Best,
Tobie
On Apr 24, 11:39 pm, Yaffle wrote:
> function update(array, args) {
> var arrayLength = array.length, length = args.length;
> while (length--) array[arrayLength + length] = args[length];
> return array;
> }
>
> Array.prototype.push.apply(array,args) == update(array,args) ?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Add JavaScript Lint to build process?
Oh! You're talking about JavaScript Lint, not JSLint... maybe we could
agree on a set of warnings and publish that on the website.
Best,
Tobie
On Mar 27, 1:06 pm, Robert Kieffer wrote:
> Please note that I didn't mean to imply that Prototype should adhere
> to every warning and suggestiong that JSLint emits. IMHO, many of
> them add little/no value and can safely be ignored. But missing semi-
> colons, and ambiguous if-else blocks (for example) are the sorts of
> things that should probably get cleaned up.
>
> FWIW, here's what our jsl warnings configurations look like As you
> can see, I've disabled a bunch of stuff that just didn't add much
> value for our team:
>
> -no_return_value # function {0} does not always return a
> value
> +duplicate_formal # duplicate formal argument {0}
> -equal_as_assign # test for equality (==) mistyped as
> assignment (=)?{0}
> +var_hides_arg # variable {0} hides argument
> -redeclared_var # redeclaration of {0} {1}
> -anon_no_return_value # anonymous function does not always
> return a value
> +missing_semicolon # missing semicolon
> +meaningless_block # meaningless block; curly braces have
> no impact
> +comma_separated_stmts # multiple statements separated by
> commas (use semicolons?)
> +unreachable_code # unreachable code
> -missing_break # missing break statement
> -missing_break_for_last_case # missing break statement for last case
> in switch
> -comparison_type_conv # comparisons against null, 0, true,
> false, or an empty string allowing implicit type conversion (use ===
> or !==)
> -inc_dec_within_stmt # increment (++) and decrement (--)
> operators used as part of greater statement
> +useless_void # use of the void type may be
> unnecessary (void is always undefined)
> +multiple_plus_minus # unknown order of operations for
> successive plus (e.g. x+++y) or minus (e.g. x---y) signs
> +use_of_label # use of label
> -block_without_braces # block statement without curly braces
> -leading_decimal_point # leading decimal point may indicate a
> number or an object member
> +trailing_decimal_point # trailing decimal point may indicate a
> number or an object member
> +octal_number # leading zeros make an octal number
> +nested_comment # nested comment
> -misplaced_regex # regular expressions should be preceded
> by a left parenthesis, assignment, colon, or comma
> -ambiguous_newline # unexpected end of line; it is
> ambiguous whether these lines are part of the same statement
> -empty_statement # empty statement or extra semicolon
> -missing_option_explicit # the "option explicit" control comment
> is missing
> +partial_option_explicit # the "option explicit" control comment,
> if used, must be in the first script tag
> +dup_option_explicit # duplicate "option explicit" control
> comment
> +useless_assign # useless assignment
> -ambiguous_nested_stmt # block statements containing block
> statements should use curly braces to resolve ambiguity
> +ambiguous_else_stmt # the else statement could be matched
> with one of multiple if statements (use curly braces to indicate
> intent)
> -missing_default_case # missing default case in switch
> statement
> +duplicate_case_in_switch # duplicate case in switch statements
> +default_not_at_end # the default case is not at the end of
> the switch statement
> +legacy_cc_not_understood # couldn't understand control comment
> using /*...@keyword@*/ syntax
> +jsl_cc_not_understood # couldn't understand control comment
> using /*jsl:keyword*/ syntax
> +useless_comparison # useless comparison; comparing
> identical expressions
> +with_statement # with statement hides undeclared
> variables; use temporary variable instead
> +trailing_comma_in_array # extra comma is not recommended in
> array initializers
> +assign_to_function_call # assignment to a function call
> -parseint_missing_radix # parseInt missing radix parameter
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google 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: Add JavaScript Lint to build process?
Please feel free to submit a patch. Just make sure that you understand what you are doing when you make changes and do not blindly follow the suggestions made by the Lint parser. As they are usually incorrect and applying them directly completely breaks the program. Depending on how this patch muddles the source code, it will be accepted in or not (i.e. go for the least invasive solutions whenever you can). 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: Thoughts on Namespacing Native APIs
On Mar 25, 1:32 pm, Robert Kieffer wrote:
> 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.
I'm working on a couple of things remotely related to this. More on
this asap. That said, native object extensions is there to stay: it's
one of Prototype's biggest appeal (for example, that's the main reason
Prototype was included in Palm Mojo Application Framework).
Furthermore, namespacing issues, both for the global object and native
objects' prototypes, can be handled by sandboxing third party code
with Caja--which we'll fully support in the near future--with added
security as a bonus.
> 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().
For one, I'm a strong partisan of modifying our Class API (see a dummy
implementation proposal here: http://gist.github.com/43064) to remove
dependency on function decompiling.
Secondly, some platforms actually return sufficient information for
Function#argumentNames to work, while not truly decompiling the
function. That's the case of Caja, for example:
(function(foo, bar) { alert(foo + ' ' + bar) }).toString();
// -> "function(foo, bar} { [cajoled code] }"
Last but not least, your solution won't be able to handle context
properly (which, btw, is one of the reasons function decompilation
isn't specified in ES).
Try this in your original pastie, for example (a bit contrived, but
you get the point):
var clear = (function() {
var ZERO = 0;
function clear(_this) {
_this.length = ZERO;
return _this;
}
return clear;
})();
// ... do the magick eval tricks
[1, 2, 3].clear();
// -> ReferenceError: ZERO is not defined
> 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.
Platforms which do not support eval obviously support neither new
Function, nor passing a string to setTimeout or setInterval, nor
dynamic script injection.
To summarize, if implementing this was trivial, I would have been done
a long time ago. Unfortunately, it's not!
Over the next few weeks, we'll be concentrating our efforts on
completing the documentation, releasing 1.6.1 and migrating to a
library-agnostic test harness which I'm currently busy working on.
The idea is to get the source code as clean and solid as possible for
Prototype 1.7 (Caja support) and 2.0 development. We can certainly
look at options to remove dependencies between different parts of
Prototype by then. (For example, I would love to see the ajax module
standalone).
Hope this clarifies my point.
Of course, if you're available to help out on our current issues,
you're more than welcomed to do so!
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: Thoughts on Namespacing Native APIs
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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google 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: Updating Supported Browsers List
I wouldn't do a per platform distinction. The list would just be awful to maintain with all the mobile platforms coming up. The reasons you're seeing issues with running the tests: 1) UNITTEST_JS doesn't currently support running tests in WebKit on windows. That should be corrected in UNITTEST_JS[1]. Feel free to send me a push request. 2) CHROME requires that you provide the PATH to the CHROME app unless it's the default one[2]. We should improve the code to throw a helpful message in case Chrome can't be found at the given path. Finally, I'd rather we waited for next release before updating that page. Support for v8.0 coming soon just doesn't cut it imho. Best, Tobie [1] http://github.com/tobie/unittest_js/blob/ba287e78abf99e490ef7fd07f136583e6986f362/lib/unittest_js/browsers/safari.rb [2] http://github.com/tobie/unittest_js/blob/ba287e78abf99e490ef7fd07f136583e6986f362/lib/unittest_js/browsers/chrome.rb#L6 On Mar 21, 12:08 pm, "T.J. Crowder" wrote: > Hi all, > > I'd like to update the download page to show the operating systems on > which different browsers are supported. The page currently just says > this: > > Mozilla Firefox: >= 1.5 > Microsoft Internet Explorer: >= 6.0 > Apple Safari: >= 2.0 > Opera: >= 9.25 > > I have the impression Prototype supports Safari only on Mac OS, for > instance, and not on Windows (since rake test won't test against > safari on Windows). > > Anyone have the definitive list for 1.6.0.3? Here's my stab at it: > > Firefox: > - Windows: v1.5+ > - Mac OS: v1.5+ > - Linux: v1.5+ > > Internet Explorer: > - Windows: v6.0 & v7.0; v8.0 coming soon > > Safari: > - Windows: Not at all? > - Mac OS: v2.0+ > > Opera: > - Windows: v9.25+ > - Mac OS: v9.25+? > - Linux: v9.25+? > > I've listed version numbers there because I wouldn't be surprised if > (for instance) Safari were supported in version 2 and up on Mac OS, > but only 3.2 and up on Windows (Safari 3.0 on Windows having been.../ > not entirely successful/). > > Once we have a solid list, I'll update the page; and then update it > again if the list changes in 1.6.0.4, as I expect it will (e.g., +IE8 > at least, perhaps Chrome?). > > Thanks, > > -- 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: Cloned repo via git, not seeing the unit test html files
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" 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: Add JavaScript Lint to build process?
> Is there any evidence that NOT being strict is slower for a non-strict
> environment?
huh?
> Does missing a few {} or the odd ; in allowable places make the parser
> have more work to do?
That's implementation specific.
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: Add JavaScript Lint to build process?
> I wonder why Caja is taken in so much more consideration than a > practice that always existed in the programming world. There's two reasons to that: 1. I've been consulting for Google Caja team to make Prototype Caja- compliant, 2. Valija[1], the language which was created by the Google Caja team as a result of that work[2], is an approximate subset of the ES3.1 strict mode, so supporting it today means supporting strict mode tomorrow. Best, Tobie [1] http://code.google.com/p/google-caja/wiki/WhatsMissing [2] http://groups.google.com/group/google-caja-discuss/browse_thread/thread/284935fa0784316d/31e476a985ae8c66?lnk=gst#31e476a985ae8c66 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google 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: Add JavaScript Lint to build process?
Some of those have been fixed in my branch for Caja compliance. On Mar 12, 11:10 pm, Robert Kieffer wrote: > Would it be worth doing some sort of javascript lint'ing as part of > the 'dist' or 'test' tasks? ... or as part of whatever the final > release processis? When I run http://www.javascriptlint.comagainst > 1.6.0.3 or trunk, even using a fairly conservative config, I see a > healthy dose of warnings (included below). > > In addition to dozens of 'missing semicolon' warnings, I also see > stuff like this (on latest trunk dist): > > prototype.js|450| lint warning: multiple statements separated by > commas (use semicolons?) > prototype.js|2206| lint warning: multiple statements separated by > commas (use semicolons?) > prototype.js|2745| lint warning: the else statement could be matched > with one of multiple if statements (use curly braces to indicate > intent) > prototype.js|3269| lint warning: multiple statements separated by > commas (use semicolons?) > prototype.js|3577| warning: variable nodes hides argument > prototype.js|3932| lint warning: multiple statements separated by > commas (use semicolons?) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google 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: Palm's Mojo and Prototype
> If I were in an environment where the JSON object and its methods were
> not available, would doing something like this:
>
> if (typeof JSON === "undefined") {
> JSON = {
> stringify : function (o) { return Object.toJSON(o); },
> parse : function (s) { return String(s).evalJSON(); }
> };
>
> }
>
> produce the same output as using native JSON or the json2.js library,
> or would there be differences? If there would be differences, what
> would they be?
There would be a difference.
JSON and json2.js both rely on an implementation based on the idea
that toJSON must return "the value to be stringified".
json.js - on which our implementation is based - relied on the idea
that toJSONString (and we're using toJSON in our implementation) must
return a stringified value.
What this typically means is that for json2 'foo'.toJSON() will return
'foo', so JSON.stringify will add the quotes. Our version of toJSON
actually returns '\"foo\"' so passing it to JSON.stringify means it
will be escaped and quoted twice.
We'll fix this for 1.7.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google 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 and the global namespace
A couple of thoughts about Function#bind: - it's part of the ES 3.1 draft, so will be found in browsers natively pretty soon, and - it's been been completely rewritten for our next release, so the overhead should be much lighter. Regarding extensions of native prototypes in general, a lot of methods originally introduced by Prototype (the so-called rubyisms), which were then added to FF will make it to the ES 3.1 spec. Yes, there's one infortunate issue with Array#reduce, but the fact there we're now a lot more present on the ES 3.1 mailing list helps to make sure this won't happen again. One of the great assets of Prototype is it's language enhancement features. One of the great issues of Prototype is the way this causes pollution. Ideally, we can achieve better balance between those for Prototype 2.0. It's certainly on my plate! 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 -~--~~~~--~~--~--~---
