Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jquery issues #6

Open
darnold opened this issue Sep 28, 2010 · 6 comments
Open

Jquery issues #6

darnold opened this issue Sep 28, 2010 · 6 comments

Comments

@darnold
Copy link

darnold commented Sep 28, 2010

Hey Dom! I really like what you are trying to do here, I just noticed some issues with jquery. From the looks of it you are using yui to compress all the scripts from your init.js file. The problem is that I can not execute jquery code unless I call the jquery.js directly.

You can see here in this quick test that the "view more" button is not working to show more content. However, it works great when I call the jquery file directly. http://jharman.net/new/test.html

Any ideas on this? Great work!

-David

@DominikGuzei
Copy link
Owner

Hi David!

The Flawless Framework includes jQuery, but this is not intended to be used in production, because it's only relevant for the development menu. If you set FLAWLESS_MENU config to 'false' than jquery won't be loaded at all! So you have to include jquery as normally for your site - at the end you should delete or comment out the flawless development scripts and copy the generated and compressed css styles into the production_styles.css file.

Addinionally the dev tools of the framework call jQuery.noConflict() which forces you to not use the $ sign in global namespace. This is happens intentionally to avoid conflicts with other javascript libraries that use the $ sign for their objects. It is best practise to write jquery code that starts with like

  jQuery(document).ready(function( $ ) {
       // here you can use the dollar sign like normal!
  });

I hope this gets you going!
kind regards

@darnold
Copy link
Author

darnold commented Sep 30, 2010

Ah I see what you are saying. It just seems weird to me to have all these scripts loaded for development and then not really being able to use them. For example you are calling jquery.ui which I would normally be using in dev and in production. But your version is missing the ui.button which I normally use. so then what I have to do is include my own but then of course it conflicts with your version. So what I'm thinking is maybe some of the more commonly used scripts like jquery and jquery.ui should be pulled in outside of the init.js.

As you can tell i'm still trying to think through the best way to organize everything :) Just throwing out my thoughts on the matter!

@DominikGuzei
Copy link
Owner

hi darnold!

great point, you are completely right - to be honest, I don't know if the current menu is that important anyhow. For my current project I never activated it and the main purpose was to get the compressed css styles. Maybe we have to think about the way we provide the styles, because the #compress flag (used in first versions of the framework) was not the holy grail either. But it definitely was the easiest and best way ;-)

Thanks for your great feedback, I appreciate that and it really helps me making the framework better!

kind regards

@superstructor
Copy link
Collaborator

Thanks for the feedback Darnold.

The YUI loader is loading the scripts asynchronously so jQuery is not available by the time the inline JavaScript in your HTML is executed. Hence in a JavaScript console it comes up with the error "$ is not defined".

I'm not deeply familiar with YUI but I know you could place your JavaScript in an external file then load that from init.js like the other JavaScripts and specify jQuery as a dependency for your file. See the existing examples in that file. This is not an ideal solution as it was designed for development use but would get you up and running in the meantime I think.

I also would like to use the same JavaScripts in production that I use in development so this is an area I would like to improve.

So far I have

  • put JavaScripts in a "js/" directory in the root of the project
  • used standard distributions of libraries e.g. so jQuery UI is not missing any components
  • replaced YUI loader with RequireJS http://requirejs.org/

RequireJS is also an async loader. It does have jQuery bundled in the main file which is a bonus in that jQuery is available immediately but may be biased and not suitable for users of other frameworks like Mootools or Prototype. There is a standalone version that doesn't include jQuery so maybe I should consider using that then load jQuery separately. I'm not sure about that.

With RequireJS you can have something like the jQuery ready function to wait until the libraries you need are loaded e.g.

require('jquery-ui', function() { 
   /* now jquery ui is loaded */
   jQuery(document).ready(function($) {
        /* do some jquery ui stuff */
   });
});

It also allows a more advanced module format where dependencies are embedded in the JavaScript you write itself e.g.

define('my-awesome-module', 
/* requires jquery ui */
['jquery-ui'],
function() {
 /* return my modules code */ 
 return function() { 

 } 
}); 

It includes a configurable build script that can concatenate into a single script and compress your JavaScripts for production with google closure compiler. The build script is written in and configured via JavaScript. It does depend on Rhino and Java for the closure compiler but there is no better JavaScript compressor so I feel it is worthwhile for that.

This is a bit of a simplification and I havn't gotten it working as smoothly as I'd like yet. There are still some bugs. But the changes are currently being worked on here https://github.com/superstructor/flawless.css

Do you think this would solve your issues ? E.g. if there was a way to execute code after libraries like jQuery UI became loaded/available ? Any feedback is appreciated as I want to make sure any changes benefit the most possible users of the framework and not just my use case.

Best regards.
Superstructor

@darnold
Copy link
Author

darnold commented Nov 29, 2010

Superstructor,

Thank you for your thoughtful response!

I like the ideas you have outlined, they make a lot of sense. I'll see if I can give this workflow a try this week and i'll let you know how it's working for me.

Thanks again,
-d

@superstructor
Copy link
Collaborator

This issue will be easy to resolve once #18 is done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants