honeydew-ng

We use composer to manage our backend dependencies, npm to manage our frontend build dependencies, and bower to manage the front end deps that get loaded in the browser. We've made a few changes to our bower dependencies, so they're checked in, but you'll need to manually install the composer and npm deps before using grunt to start up the app:

$ gem install compass
$ composer install
$ npm install
$ grunt serve

For the backend to work, you'll need to get backend/rest.php and backend/rest-routes into the root of your folder being served, such that

$ curl localhost/rest.php

would hit this repo's backend/rest.php. Your setup can obviously vary, but if you're on OS X, using the built-in Apache should be feasible. Sudo edit your /etc/apache2/httpd.conf and uncomment the php5 line

LoadModule php5_module libexec/apache2/libphp5.so

if necessary; then sudo apachectl start.

The default folder served by Apache is /Library/WebServer/Documents, so you could symlink the necessary files if you wanted (assuming your httpd.conf has FollowSymLinks set for that directory). Run these commands from the ng directory such that there is a backend folder in your directory.

$ sudo ln -s $(pwd)/backend/rest-routes /Library/WebServer/Documents/rest-routes
$ sudo ln -s $(pwd)/backend/rest.php /Library/WebServer/Documents/rest.php

configuration

Configuration is copied out of the /opt/honeydew/honeydew.ini file via the ngconstant:build task into app/config.js. Empty copies of app/config.js are kept in the module via git's update-index.

usage gotchas

The version of grep that apache/_www/your webserver user has access to might be too old to recognize some of the flags we use. You may need to

$ sudo mv /usr/bin/grep /usr/bin/grep-backup
$ sudo ln -s /usr/local/bin/grep /usr/bin/grep

contributing

grunt tasks of interest

• grunt serve - This will build the app, open it in your browser, and watch the repository files for changes

• grunt ci - This will run the unit tests with karma and watch the generated javascript files for changes. This task needs to be updated to watch the .es6 files instead of the generated js files, though. You'll probably want to run this while developing to make sure you haven't broken any tests.

• grunt config - This will generate a configuration file from /opt/honeydew/honeydew.ini. If the file is missing, it will create an empty config file that will enable the app to run.

style & organization

For the most part, attempt to conform to johnpapa/angularjs-styleguide. For file organization, explicit routes like monitor, editor (features|phrases|sets), landing - those pieces are at the top level along with app.js. Everything else is goes in the components/ folder and they're handled via AngularJS's DI and the grunt fileblocks plugin.

Note that we are explicitly /not/ doing group-by-type. For example, our filetree component has a folder in components/ with all of the filetree services, directives, and controllers. The unit tests and end to end tests are also in the same folder. You should be able to open any folder in the components/ and have all the files there that you need to deal with. And, as usual, use SRP - keep each component in a separate file, with the type of the thing (service, controller, directive, etc) appended to the name: filetree-service.js and filetree-directive.js, for example.

current on-going refactors

1. ng-controller="Ctrl as ctrl" - use the ng-controller ControllerAs syntax in the html templates instead of binding the less explicitly in the router or something. This takes out $scope from your controller and replaces it with binding everything to this, and makes your html more explicit, especially when nesting controllers and dealing with inherited properties in nested scopes.

2. modularize! when applicable, make your new component part of its own module. Currently in progress:

   * sc.cmmodes - this should have all of the CodeMirror modes in
     it, but it currently only has reportMode
   

3. Start using Settings module - currently, many of the settings talk directly to $localStorage and $sessionStorage. That's unhelpful because we're planning to switch out our dependency on the ngStorage module sometime in the future due to poor support and bad performance. Before we do that, we need to switch all direct uses over to the new Settings class in app/components/settings/settings-service.es6.