Ticket
move all javascript into cards+solution
- A "Javascript" cardtype (can either contain js in the db or can pull js code from file)
- A "CoffeeScript cardtype that compiles to js
- A *script rule that points to js files or lists thereof
- automatic compilation and compression
Gerry said:
Are you at all familiar with AMD: https://github.com/amdjs/amdjs-api/wiki/AMD and do you have any opinion on whether we should be thinking of using this 'standard' or just how standard it is?
I think my main question is about as we move forward, whether we want to adopt particular approaches on the client (java/coffeescript) side. As I've said, I'm in explore mode, but I don’t' want to waste a lot of time on things we are likely never to adopt. Often these frameworks are paired with Java based (or even node.js) services on the server side. I'm not that bound to ruby and rails either, but these are big things to bite off and I think we want to be open about the big picture stuff.
BTW, I'm really liking using coffeescript vs. at work where it is all javascript. It get rid of a lot of the annoying things about js. It is a pain that the errors don't report line number, though.
I'm not familiar with AMD but will read up.
Some things I expect we want in the API:
- a set orientation (including probably making codenames available in classes - currently it's just cardnames)
- some sort of balance between our entirely-card-data-based CSS system and the entire-code-based ruby mod system
- the end of wagn's use of the rails asset pipeline (?)
I got worried that the dojo stuff was getting a bit stale (year old last commits), so I started looking for other options. Looking at ShareJS now, which may or may not be a good fit for what I'm playing with.
As far as loading/packaging of javascript, I am seeing some things I also saw reading about AMD. The bottom line for this stuff is about the loading frameworks, and the desire not to pollute the global JS namespace. I do see them using 'require' to load things, but AMD uses 'define' as the single global thing to load everything else. In that space, 'require' is a next level (called by define), and I think it is part of the standards based loading approach for JS. It seems as if AMD is a little more powerful and potentially supports lazy/asynchronous loading moreso.
This is a bit of a different dimension of the problem than what you are listing above. I think we have gotten a lot of benefit from being more standards based (in terms of emerging best practices; faster moving target that standards bodies and design by commitee). When we have gone from vendor/plugins to bundler based loading of gems, and upgraded to Rails 3, that has made our code a lot cleaner. Your re-organizations of the code intuitively will allow us to maybe do 'Wagn as a gem' when the opportunity presents itself, and use concepts like Engines (is that ruby or rails in origin?) so that people can use Wagn as a platform and/or library in the future. I want to capture this sense of emerging into a moving target with what we create for this solution.
I'm looking forward to you better explaining your meaning in the above three bullets. I get the gist of it, but penetrating into what that will mean in practical implementation terms is a bit harder. I want a natural way to move from the kind of experimental work I put on that branch I sent you to splitting it off into a mod or two.
In progress? What are you working towards?
In attempting to get jasmine tests to work, I'm running into version issues with some of the components. We really need something to help with js version dependencies, and I don't know what that would be as of yet.
Most of the work is currently here https://github.com/wagn/wikirate/tree/master/mods/proposed
Rather than add it directly to Wagn code, I'm adding it to a "proposed" mod in wikirate. (note, you'll need some gems from the gemfile).
I'll put some details in the "solution" section above, but basically it's a direct mirror of the CSS. There's no version dependency tracking yet, and I doubt we'll add anything that heavy to the initial API. But I agree that version tracking is desirable in the long run for all our mods (ruby, js, and even css)
speaking of which, I think the jquery upgrade broke our file upload ;)
That isn't too surprising (file upload). Is that about wagn or the mod in wikirate?
I think all of this would be easier if we had automatic dependency handling in javascript. Probably only in development mode, or for some rake tasks or something.
Fantastic!