embarassing git testing
Merge branch 'sprint7-profile' into sprint7-dan
Merge branch 'sprint7-profile' into sprint7-dan
Integrates acController and source changes to allow for profile querying
Commits AcController for sake of clean merge
Merge branch 'sprint7' into sprint7-dan

Conflicts:
	api/controllers/CommentController.js
Bump version to 0.0.8 (sprint8)
Added logic and HTML to the Task Show page.

- Also added an ajax loader transition paradigm, and implemented it, with the
  assets, to the project show and task show view transitions.  This
  transition takes place during the page transfer from one to the other.
  Ideally always placed in the router, and abstracted using the helper
  methods within the utility file.
Updated class and styles to follow paradigm.

Updated the class and styles for the ui-loader and ajax-loader to follow
our paradigm, and cleaned up the CSS file a bit.
Tests autocomplete methods for participants
Show projects in profile

This is a first checking of showing all the projects that you
own in your profile page.  It is designed as an 'activity app'
so it will be reused to show your tasks.

There's a few things I want to do, like configurable columns
passed as parameters to the activity view (for example, tasks
may want to show a deadline).

Also an open question how to format the dates.
Merge branch 'sprint8' into sprint7-dan
Add iCal download to profiles

If you're the owner, give you a button to download your iCal
calendar.  Fix up the calendar code so that the calendars
have a filename when downloaded.
Cleanup.

- Removed ajax loader for paradigm incoming in next commit.
- Added a comment to the top of task_show_controller regarding what I
  will be doing with it.
- Removed uneeded ajax spinner styles.
- Fixed whitespace.
Cleanup of ajax-spinner styles mentioned in previous commit.
Added new paradigm for Ajax Spinner, details below

There is now a base_view class that every RENDER ONLY child view should
extend off.  This base_class will automatically render the view once it
is ready to do so.  In this case, once it has set the ajax spinner and
attached it to the $el of the child class.  The child class then has its
render method called in which it flushes the DOM and adds new content to
its $el.

Definition of render only:
- It only renders, and that's it.
- NOTE: We have been adding more logic than is needed into the views
  themselves, and with this paradigm I hope to slowly get us back to
  using the controller more.  This is just the first step in bringing as
  much generic functionality as we can to the base_view class.

This means we no longer need to do this:

var viewName = new ViewName({
  el: "#someEl",
  model: someModel
  // ...
});
this.viewName.render();

We can simply do this:

var viewName = new ViewName({
  el: "#someEl",
  model: someModel
  // ...
});

And it will automatically know to initialize logic within the base class
with a reference to the view you call new on, and then render the
immediate child view of the base class (current instance initialized).

Based on analysis of our application, there is no situation in which we
initialize a view class but don't render it right there.  Sometimes
there is logic within the view if it is large, and thereby making it NOT
a -render only view-, in which the render method is the second, third,
or fourth method called within said view.  That class for now would not
be a good one to extend the base_view class on, as I mentioned above it
has to be a render only view class.  But eventially I'd like to check
for that and/or pass in a param to the constructor that allows the
parent class to know how and when to render its child view.
Added Production methods to the Gruntfile.

I added a production compile method to the grunt file, and the deps for
it in the package.json, tested, and built our project and stored it in
/assets/js/prod/midas.js.  We can change that directory we house this
in, but for now that seems fine.

To run this command simply open terminal, do an npm install, and
preferably npm install grunt-contrib-requirejs --save-dev, then type
"grunt requirejs" to execute the requirejs grunt command, and you will
see the app compiling.
Updated Tasks Show View Logic

Updated the logic and initialization on the task show view to behave the
same as Profiles (to an extent).  There is now the ability to render the
view state (tags, task specific data, etc) and then edit that as well,
fetching all the data needed right there in the show view.  Eliminating
the need to do it again in the edit view.  Template files have yet to be
checked in, still working out bugs.
Get requirejs to work in production.

This was a pretty hairy ugly undertaking.  Our requirejs
app was really not set up for use in dual-mode development
and production.  I've hacked the app to look more like a
well-defined require module.

I've then modified layout.ejs to check what environment
sails is running in (development or production)
and render to the page the correct <script> html.

When you lift sails, it does NOT generate the production
javascript... instead you need to do:

	grunt requirejs
	sails lift --prod

This will run the server in production mode with a single
javascript file (other than jquery).

There's still more work to be done here -- like figuring
out how to include jQuery in the configuration rather than
hacking it in as a <script> tag, but this seems to run
well locally.  The other thing would be to compile
the production js on sails lift (And also inspect what
sails is really doing during production to minimize
cpu and memory resources hogged by grunt)

Still need to test it on the remote demo server.
Remove debugging commented out script tag
alters the project view for select2 participants