Permalink
Browse files

Updating Slick to 1.1.5

  • Loading branch information...
cpojer committed Feb 23, 2011
1 parent 37e200e commit 215c2fa02bb6e23fa7d41b18438e2fea01247be4
Showing with 2 additions and 2 deletions.
  1. +2 −2 Source/Slick/Slick.Finder.js
@@ -162,7 +162,7 @@ local.setDocument = function(document){
// native matchesSelector function
- features.nativeMatchesSelector = root.matchesSelector || root.mozMatchesSelector || root.webkitMatchesSelector;
+ features.nativeMatchesSelector = root.matchesSelector || /*root.msMatchesSelector ||*/ root.mozMatchesSelector || root.webkitMatchesSelector;
if (features.nativeMatchesSelector) try {
// if matchesSelector trows errors on incorrect sintaxes we can use it

This comment has been minimized.

Show comment
Hide comment
@asuth

asuth Feb 24, 2011

Typos: throws and syntaxes

@asuth

asuth Feb 24, 2011

Typos: throws and syntaxes

features.nativeMatchesSelector.call(root, ':slick');
@@ -878,7 +878,7 @@ local.attributeGetters = {
var Slick = local.Slick = (this.Slick || {});
-Slick.version = '1.1.4';
+Slick.version = '1.1.5';
// Slick finder

7 comments on commit 215c2fa

@ibolmo

This comment has been minimized.

Show comment
Hide comment
@ibolmo

ibolmo Feb 24, 2011

Member

By the way, why are you modifying Slick directly? Why isn't this a submodule?

Member

ibolmo replied Feb 24, 2011

By the way, why are you modifying Slick directly? Why isn't this a submodule?

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Feb 24, 2011

Member

we only use the Slick code, we don't use the repository. Slick in Core is a copy, not the real thing :D

Member

cpojer replied Feb 24, 2011

we only use the Slick code, we don't use the repository. Slick in Core is a copy, not the real thing :D

@fabiomcosta

This comment has been minimized.

Show comment
Hide comment
@fabiomcosta

fabiomcosta Feb 24, 2011

Member

It's exactly the real/same code, the problem is the structure of the folders...

Member

fabiomcosta replied Feb 24, 2011

It's exactly the real/same code, the problem is the structure of the folders...

@ibolmo

This comment has been minimized.

Show comment
Hide comment
@ibolmo

ibolmo Feb 24, 2011

Member

Not really a problem. Put Slick in the same level as Packager and Specs. Then update package.yml done, no?

Member

ibolmo replied Feb 24, 2011

Not really a problem. Put Slick in the same level as Packager and Specs. Then update package.yml done, no?

@fabiomcosta

This comment has been minimized.

Show comment
Hide comment
@fabiomcosta

fabiomcosta Feb 24, 2011

Member

It's more like "all our source files are on our source folder", i think.
I think we should discuss this on IRC.

Member

fabiomcosta replied Feb 24, 2011

It's more like "all our source files are on our source folder", i think.
I think we should discuss this on IRC.

@Inviz

This comment has been minimized.

Show comment
Hide comment
@Inviz

Inviz Feb 25, 2011

I had to request a feature for my packager to handle this specific issue of bundling 3d party. Even though I can handle it with a packager (i can explicitly state standalone Slick to replace bundled Slick), unbundling it is a better way for everyone.

I had to request a feature for my packager to handle this specific issue of bundling 3d party. Even though I can handle it with a packager (i can explicitly state standalone Slick to replace bundled Slick), unbundling it is a better way for everyone.

@ibolmo

This comment has been minimized.

Show comment
Hide comment
@ibolmo

ibolmo Feb 25, 2011

Member

Yep.

My solution is to register Slick at my own fork in a separate folder. My projects no longer have js dependencies just that Packager is configured correctly. Kind of like gems and pypy. At deployment, I have a script that compiles a frontend.js which has only the dependencies necessary for the projecto run.

The problem with this is that if a different project depends on a different build of a dependency.. so it gets hairy. One improvement is to have a .packager file inside the repo that packager then looks for. I also don't know if packager is looking for version numbers or branches. That would be best.

Member

ibolmo replied Feb 25, 2011

Yep.

My solution is to register Slick at my own fork in a separate folder. My projects no longer have js dependencies just that Packager is configured correctly. Kind of like gems and pypy. At deployment, I have a script that compiles a frontend.js which has only the dependencies necessary for the projecto run.

The problem with this is that if a different project depends on a different build of a dependency.. so it gets hairy. One improvement is to have a .packager file inside the repo that packager then looks for. I also don't know if packager is looking for version numbers or branches. That would be best.

Please sign in to comment.