Footprint override

[jaumard]

Give us the possibility to override the default FootprintController methods per controller. It can be related to https://github.com/trailsjs/trails/issues/42 cause if we have class for controllers we can but defaults Footprint methods under that class and under each controller we can override or not footprint behavior :)

[tjwebb]

@jaumard there are three ways to achieve this. Let's discuss which ones we think are the best fit for Trails.

1. Route Config Override

This is the most Sails-ey way to do this, and should work out-of-the-box currently. Create FooController.myHandler and create a corresponding route object in config/routes.js that points to it. So if you want to override FootprintController.find, your route object would look something like this:

{
  method: 'GET',
  path: '/{model}',
  handler: 'FooController.myHandler'
}

2. Mixin

When the trailpacks are loaded, all the stuff under the api namespace is basically _.merged together. Create your own FootprintController.find handler, and since it's in the main project, it should take precedence over the FootprintController in the trailpack and overwrite it. This is also very Sails-ey, since Sails "hooks" can be used to achieve the same thing.

3. Inheritance

This is the most object-oriented way of doing this. extending a class makes this use case very clean, but complicates some of the core logic that interrogates the properties of controllers/models to determine which routes to generate. An example could be:

const HapiFootprintController = require('trailpack-hapi/api/controllers/FootprintController')

class FooController extends HapiFootprintController {

  /**
   * @override
   */
  find () {

  }
}

[jaumard]

Very nice ! I prefer the inheritance way (3) :) it's more "natural" than 1 and less magical then 2. Also you can call super.find... if you want/need and add you own stuff without rewrite all you already did in the mother (web server) footprint.

[thejones]

My preference also falls into #3 for a few reasons:

1. Not all users are coming from Sails.
2. Trails has been embracing ESWhatever and the OO feels like it is a great fit.
3. I don't want to change my routes just so I can apply a policy for securing the default actions.
4. Per recent gitter discussion this is what I thought would happen without finding this issue...

module.exports = class MyController extends Controller {

  create(request, reply) {
     super()
     //stuff
     reply() 
  }
}

[wbprice]

Did we decide what approach to take for this?

[tjwebb]

My preference is for number 3, and it's the way I've started implementing other parts of the system. Inheritance is a natural way to define an interface and communicate which operations have been re-implemented.

[jaumard]

@wbprice also 1 and 2 are already possible actually, we can define a custom FootprintController or (re)define a footprint route to a custom controller. 3 is not yet available but sound the most easy/natural to implement for end user.

[scott-wyatt]

I also agree with 3. OOP is way more natural to someone switching languages and like @jaumard mentioned, 1 and 2 are technically already achievable.

[jaumard]

@tjwebb can this be planned for the V3 ? As the v1 beta is far behind :D Because I think this is actually a limitation in Trails as it's not "easily" possible to override Footprint for one (or more) model.