girder/covalic — pull request #2 by mgrauer (2014-12-02 23:40:33+00:00)
Title: Submission ui

@zachmullen @cpatrick

Some struggles recently, but I feel like I'm on the path forward now.

The general plan is to have this be a plugin which provides an external web client and supersede Girder's own web client when this plugin is active.

Some complications to note in the Gruntfile. There exists in Girder's Gruntfile the ability to have a plugin register tasks to be run as part of the top level Grunt, but those still assume that the plugin will be working within the Girder client, not replacing it.

With Zach's help, I have a Gruntfile which *explicitly* creates its own tasks that are then added to the top level Grunt--I needed this because I needed specific control over the ordering of js files in the plugin.min.js. Unfortunately, [due to the expectation of the top level Gruntfile](https://github.com/girder/girder/blob/master/Gruntfile.js#L395), a plugin is only searched for its Gruntfile if the plugin has a `web_client` dir, so I have a placeholder dir with that name. Maybe it would make more sense to look in the plugin.json for some specific value so this placeholder isn't required, [as we do for adding in targets from the plugin](https://github.com/girder/girder/blob/master/Gruntfile.js#L373)?

I said *explicitly* earlier because it would be easy to hook into the plugin tasks that the top level Gruntfile creates, but this gives you the ability to *accidently* get your tasks in your plugin's Gruntfile be run as a part of the top level Grunt if you happen to name them the same as the way the top level Gruntfile views them. Instead, we created new and explicit names for each of the plugin tasks, e.g. `covalic:uglify`.