Envjs envjs → 1.0 Release

Comments and changes to this ticket

• You flagged this item as spam.
  

  larry.karnowski (at gmail) January 31st, 2009 @ 06:33 PM

  Chris, I think you should definitely pull into John's branch... but ONLY when env.js is compatible with the following:

  • jQuery 1.2.6 (done!)
  • jQuery 1.3.1 (a couple of issues captured as Lighthouse tickets)
  • any version of Prototype (currently both 1.6.0.1 and 1.6.0.3 completely break -- both were shipped by recent versions of Ruby on Rails) (to make matters worse, John's original version of env.js worked with 1.6.0.1, so this breakage is a regression caused by the new DOM impl)

  I'm working on the Prototype stuff this weekend and hopefully will have a patch to contribute. If not, I'll at least document what I've learned in a Lighthouse ticket.

• You flagged this item as spam.
  

  larry.karnowski (at gmail) February 1st, 2009 @ 06:37 AM

  Chris, so after rethinking this, I realize that "compatability" is too broad a word. I'm not asking for 100% compatibility, just that we can do the following:

  • load either jQuery or Prototype without crash or complaint
  • successfully fire a "document loaded" event for each toolkit
  • use the core $, $$ functions for basic ID and CSS class name lookups

  I've opened tickets #29 & #30 to cover the problems with Prototype. I've submitted patches for both of those.
  

  You opened tickets #14 & #15 to cover the jQuery 1.3.1 problems I was seeing. I've submitted a patch for #14, but it needs a code review/sanity check. That leaves only #15 open, and I really need some help on that one.

  Once that last bug is fixed, I'd love to see you merge your branch up into John's project. Viva la env.js!

• You flagged this item as spam.
  

  thatcher.christopher (at gmail) February 1st, 2009 @ 07:23 AM

  Thanks Larry. I know 100% compatibility might be too broad a goal but it got me thinking about how to approach our initial testing suite. I think it's a great idea to measure our compliance by running each of the major js library's own unit tests in envjs. As long as they load and run we have a measure of compliance and can then work toward converging on 100% compliance moving forward.

  What do you think about that?

  Thatcher

  ---

  From: Lighthouse no-reply@lighthouseapp.com To: thatcher.christopher@ymail.com Sent: Sunday, February 1, 2009 11:37:04 AM Subject: [envjs #27] pulling to github/jeresig

• You flagged this item as spam.
  

  Larry Karnowski February 2nd, 2009 @ 01:50 AM

  I think using the test suites for jQuery and Prototype are a great start! Those two seem to have the most mindshare right now.

• 

  Thatcher February 16th, 2009 @ 07:53 AM

  • State changed from “new” to “open”
  • Assigned user set to “Thatcher”

  I've roughly integrated jquery 1.2.6 and 1.3.1 testsuites and have prototype 1.6.0.3 tests and code. I might add place holders for other libraries. As soon as I get this cleaned up I'm going to commit and we can start measuring progress against compliance with these unit tests.

• You flagged this item as spam.
  

  larry.karnowski (at gmail) February 17th, 2009 @ 01:47 AM

  Thatcher, sorry for the lack of communication, because I've started working on jQuery 1.2.6 and 1.3.1 compatibility test suites too. My fork (http://github.com/lawjoskar/env-js) has a script that will check out the 1.2.6 and 1.3.1 tags from Subversion, massage the env.js and test files as needed, and then run the test suites. I haven't worked much on Prototype, though. I'll be more vocal about what I'm working on in the future. (Speaking of which, I'm tackling #15, the endless recursion bug next.)

• 

  Thatcher February 17th, 2009 @ 03:56 AM

  No problem. I looked over your tree and like the changes, much cleaner than what I was hacking out. Prototype is a different beast as I'm sure you know. I can get the unit tests to run but not by checking out the source from git... I think it requires checking out some addintional dependencies with git and then calling rake.

  If you are able to take that on let me know and I'll get out of the way. For the recursion bug #15, I've been working on making the ownerDocument a private variable hidden via closure in the dom node constructor and then adding a getter/setter for the ownerDocument property. If it's successful it would allow me to clean up a few other properties that are exposed publicly that otherwise shouldnt be.

  Can you explain the approach youre taking there so we can pick a particular approach and avoid difficulties intrating the changes?

  Thatcher

• 

  Thatcher September 9th, 2009 @ 06:55 PM

  • State changed from “open” to “hold”

  going to ask john about this again at jquery conf