Options for Engines

[CanisLupusXenonis]

This is inspired by #2982. It adds an option object to engines, and adds an option for bypassing the filesystem mapping and checks done in view.js.

Alternatively, this option could be used to bypass the if (!view.path) { check in application.js:565, or even to assign view.path = name somewhere around there.

Either way, I think it'd be a good idea to have options for engines.
Put into the 5.0 branch because it's a breaking change.

[dougwilson]

Can you have different view engine options for different view engines? Or do all engines ends up with the same options?

[CanisLupusXenonis]

Well, if no engine options are given, it uses app.get('view engine options') or {} as a fallback.

But I've added a parameter to app.engine which lets you pass options for a specific engine.

[dougwilson]

Ah. Can you describe this feature a bit more so I can understand it? We will also need to understand it in order to write up the documentation. Is there a use case for having many view engines use the same options?

[CanisLupusXenonis]

Basically, this PR changes the following:

• Store engines in objects instead of just storing the function. Might be handy in case any other data ever needs to be stored with it.
• Add an options parameter to app.option that allows specifying options for the engine.
• Add 'view engine options' setting for default engine parameter options.
• Add the option "noFileSystem" to allow bypassing checks and calcs intended only for usage with filesystem engines.
• Tests

In short, all this really does right now is add the functionality to bypass the filesystem-specific logic associated with engines, so non-filesystem engines (like ones using databases as described in the linked issue) are possible.
This is stored in a general "options" object now associated with engine instances, which can be set when using app.engine or the 'view engine options' setting. More options can thus be added trivially.
The refactoring from storing just the callback to storing an object is just to store the options object with it right now, but it might come in handy at some other point.
The default value setting probably won't see much use while 'noFileSystem' is the only option, but it'll likely be very useful once there's other options. I mainly added it for consistency and maintainability reasons - I can remove it if you prefer though.

[chances]

@dougwilson What's the status of this PR?