See this LIVE Marionette Bookstore application before digging in...
This is a 100% client-side Single Page Application utilizing the Google Books API as a data source. It is not a true WebApp because there's no server-side responsibility for setting up endpoints-- with the additional stack overhead of including libraries such as: NodeJS: connect/express, MongoDB or Ruby: active-record. The simplicity of a SPA allows us to focus on learning Marionette, AMD and application architecture ideas borrowed from the Rails Asset Pipeline. I struggled a bit with Backbone.Marionette and RequireJS; most of my struggles were consequence of my enterprise C#/VB.NET server-side background, so coming to grips with modular javascript client application architecture was way more of a challenge than I had expected. I hope this repo can help others get up to speed faster than I did!
Switching to coffeescript has made me a javascript BALLER! I knew about coffee-script, read the little book about it, but never changed my ways. After watching Brian Mann's screencast and seeing it in action, I became convinced of the power and flexibility of coffeescript and it's ease of use. I'm SO much better a JavaScript programmer because of it. BTW, you should follow the creator of Coffee-script Jeremy Ashkenas
So easy to install, it's a shame not to:
$ npm install -g coffee-script
To begin using coffee-script in this project:
$ coffee -o assetsAMD/js/ -cw assetsAMD/js/
Now, all changes to any .coffee file is automatically compiled to javascipt. For more coffescript usage info go to the source: coffeescript.org and to help convert your existing javascript to CoffeeScript: go here js2coffee.org
###assets### The assets folder is the original fork of [David Sulc's repo] https://github.com/davidsulc/backbone.marionette-atinux-books) I learned alot from David's Marionette app about marionette's application features and it dealt with a more interesting real world back end. The original app used traditional javascript namespacing and modular layout but converting this app over to RequireJS and a modular design required a different approach to the application architecture. Modular AMD applications can be a blessing and a curse... at the end of the day AMD forces the developer to pursue a higly decoupled modular architecture.
###assetsAMD### I've added source located under the assetsAMD folder. Refer to the assets folder to see the orig. repo of Backbone.Marionette application using javascript namespacing, which was based on [Atinux] http://www.atinux.fr)'s Backbone books example app and covers features, such as external templates, modal dialogs.
After watching the excellent BackboneRails screencasts I have Mann'd up by re-structuring this application's architecture. Brian's excellent tutorials use ruby rails and Marionette.module patter with javascript namespacing. My focus here was to use an RequireJS/AMD based application architecture. I've tried to follow the Rails Asset Pipeline approach from Brian's screencast which entails more or less following a consistant folder structure when building out your application/module architecture. The AMD approach does not follow the same javascript namespaing pattern made so easy by the Marionette.module but the AMD approach does offer what I feel is a more modular building block approach with true modules that are not necessarily coupled to the application specific namespaceing patterns. I used a msgBus module that leverages backbone.Wreqr events, commands and request/response patterns to facilitate inter-application communication.
I've also updated the project recently to use as of Oct 16, 2013 the latest versions of backbone/marionette and bootstrap 3.
###config The config folder holds global application level configuration for underscore templatesettings, marionette templatecache and a custom Marionette.Region.Dialog class that displays a boostrap modal and also takes care of view/event cleanup. I picked this up from Brian Mann These techniques are a huge improvement over what I had been using previously. Don't think I could have coded this stuff with my own hand crafted javascript.
- config/_base.coffee
- config/marionette/region/dialog.coffee
- config/marionette/templatecache.coffee
- config/underscore/templatesettings.coffee
Take a look at indexAMD.Devel.html or indexAMDel.html, the Single Page that gets served for this single page application. One of the benefits of RequireJS/AMD is this simplicity. There is no right or wrong way to organize a Marionette app, but I favor the AMD approach for it's ease of loading of a single page application. Notice there is only one javascript loaded js/main or js/main.optimized
The js/main.coffee file loaded at the bottom of index.html is the requirejs bootloader. See requirejs.org for up to date information on RequireJS and the benefits of AMD script loading.
A Backbone.Collection entities/book is used to encapsulate the Google Books API. Checkout the search, fetchBooks and moreBooks methods and the msgBus.events setup in the initialize method. The msgBus pub/sub pattern is used to help create a decoupled modular architecture.
Drill down on the modular source for the apps/book application listed below. Notice how the apps/book/app requires the apps/book/list/controller module. The CONTROLLER requires the VIEWS module and the VIEWS module requires the TEMPLATES module and the templates are ultimately made of HTML snippets in {{MUSTACHE}} format.
- apps
- book
- list
- controller.coffee - the book list controller
- templates.coffee - the book list templates
- views.coffee - the book list views
- templates (template files <3 mustache format)
- list
- app.coffee - apps/book/app the book application
- book
- app.coffee - app (the main marionette application)
Get to know BOWER and automatically maintain project dependencies.
My biggest early challenge with open source software was maintaining the ever increasing dependencies. If you've never used BOWER](http://twitter.github.com/bower/) I highly recommend taking a the time to detour over there and grok it out. Grok NODEJS. Lucky for me I'm using Cloud9 IDE a web based IDE with a built in unix terminal and __SH__ell with Node pre-installed.
From the terminal/BASH $ prompt: First off, NODE v0.8+ is required for BOWER installation, as I'm writing this, NODE v 6.2.1 is pre istalled in the Cloud9 IDE but they also pre-install NVM Node Version Manager so you can update the Cloud9 workspace to NODE v0.8+ as required for BOWER
Press [alt-t] to open a terminal with bash shell commands. Pretty amazing, the project has a full featured unix environment available in a browser based Cloud9 IDE!
***Install BOWER and Coffee-script ***
$ npm install -g bower
$ npm install -g coffee-script
Bower will be installed globally
- See bower.json to see this project's open source dependencies.
$ bower install
As time passes on, update the project dependencies with ONE command:
$ bower update
Even I can handle that!
Modular design in javascript is the key to building scaleable and maintainable web applications. However, each module can create multiple http get requests when our page loads. Remove the curse with R.js optimizer.
R.js build Optimizer
Using R.js optimizer to compress/minimize/uglify your main.js file. Eliminate or dramatically reduce server requests upon you first page load.
Here's how I did it for this project in Cloud9IDE
Build the main.optimized.js verions of main.js
Run the buildoptimized.sh file at the console prompt $
./buildoptimized.sh
This previous step can/should be scrpted into a grunt/build process
The optimizer 'output' builds the assetsAMD/js/main.optimized.js that gets linked to indexAMD.html.
SEE indexAMD.Devel.html for details.
sample background image: 
Big shout-out to Cloud9 IDE and Google Chrome Extension Cloud 9 Button for Github one click to clone/edit any github repo. Fantastic!
Good luck on your open source journey! and please feel free to drop me a line if you want any help with this project.