Morph MORPH
SIGN IN SIGN UP
morphadmin / express-bench

Fast, unopinionated, minimalist web framework for node.

0 0 2663 JavaScript
Normal View History Raw
using connect.proto.use
2011-10-07 09:29:36 -07:00
/**
* Module dependencies.
*/
some code cleanup
2014-03-25 15:23:04 -07:00
var mixin = require('utils-merge');
var escapeHtml = require('escape-html');
var Router = require('./router');
var methods = require('methods');
var middleware = require('./middleware/init');
var query = require('./middleware/query');
var debug = require('debug')('express:application');
var View = require('./view');
var http = require('http');
Merge tag '3.7.0'
2014-05-18 11:17:37 -04:00
var compileTrust = require('./utils').compileTrust;
Merge tag '3.6.0'
2014-05-09 17:33:26 -04:00
var deprecate = require('./utils').deprecate;
using connect.proto.use
2011-10-07 09:29:36 -07:00
/**
typo
2011-12-09 14:32:35 -08:00
* Application prototype.
using connect.proto.use
2011-10-07 09:29:36 -07:00
*/
var app = exports = module.exports = {};
/**
* Initialize the server.
*
refactoring boot logic
2011-10-07 15:10:30 -07:00
* - setup default configuration
* - setup default middleware
* - setup route reflection methods
*
using connect.proto.use
2011-10-07 09:29:36 -07:00
* @api private
*/
refactoring boot logic
2011-10-07 15:10:30 -07:00
app.init = function(){
fix behavior of multiple app.VERB for the same path fixes #2116
2014-05-15 10:30:52 -04:00
this._baseRoutes = {};
app.lookup()
2011-10-07 14:11:08 -07:00
this.cache = {};
using connect.proto.use
2011-10-07 09:29:36 -07:00
this.settings = {};
added app.register()
2011-10-07 13:19:29 -07:00
this.engines = {};
refactoring boot logic
2011-10-07 15:10:30 -07:00
this.defaultConfiguration();
};
/**
* Initialize application configuration.
*
* @api private
*/
app.defaultConfiguration = function(){
req.query is always present
2011-10-07 14:04:59 -07:00
// default settings
add "x-powered-by" setting
2012-09-13 09:52:35 -07:00
this.enable('x-powered-by');
Add application setting to disable ETag completely
2012-11-19 02:15:20 +04:00
this.enable('etag');
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
var env = process.env.NODE_ENV || 'development';
this.set('env', env);
move "subdomain offset" defaulting to config
2013-01-23 20:10:29 -08:00
this.set('subdomain offset', 2);
improve proxy trust with ip address list closes #2099
2014-05-09 00:53:47 -04:00
this.set('trust proxy', false);
req.query is always present
2011-10-07 14:04:59 -07:00
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
debug('booting in %s mode', env);
using connect.proto.use
2011-10-07 09:29:36 -07:00
remove app.locals.use and res.locals.use there are a few reasons for this: a) less API, simpler implementation ... b) difficult to inherit cleanly from subapps c) effectively the same as parallelized middleware (use connect-parallel for example) lastly this api in a sense promotes some obscure uses since they may be scattered throughout rather than explicitly given to specific routes or used globally as middleware etc
2012-07-05 18:46:19 -07:00
// inherit protos
Added new mvc example
2012-04-26 03:53:49 -07:00
this.on('mount', function(parent){
Fixed req/res proto inheritance
2012-04-26 04:38:33 -07:00
this.request.__proto__ = parent.request;
this.response.__proto__ = parent.response;
Added new mvc example
2012-04-26 03:53:49 -07:00
this.engines.__proto__ = parent.engines;
inherit settings from parent application using [[Prototype]]
2013-02-08 12:58:07 +02:00
this.settings.__proto__ = parent.settings;
Added new mvc example
2012-04-26 03:53:49 -07:00
});
Added res.locals.use(). Closes #1120
2012-05-03 08:42:18 -07:00
// setup locals
change res.locals to a plain js object. Anyone who wants something fancier should use modules. - fixes annoyance with not being able to set 'name' property on locals
2014-01-24 19:49:45 -05:00
this.locals = Object.create(null);
Added res.locals.use(). Closes #1120
2012-05-03 08:42:18 -07:00
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
// top-most app is mounted at /
this.mountpath = '/';
using connect.proto.use
2011-10-07 09:29:36 -07:00
// default locals
this.locals.settings = this.settings;
Added "json replacer" and "json spaces" settings. Closes #996 [credit to jed]
2012-02-07 03:30:34 -08:00
// default configuration
add "view" constructor setting to override view behaviour
2013-04-13 09:53:50 -07:00
this.set('view', View);
move default of "views" out so multiple cwd() calls are not made
2012-10-06 09:58:17 -07:00
this.set('views', process.cwd() + '/views');
add "jsonp callback name" setting
2012-07-06 08:53:19 -07:00
this.set('jsonp callback name', 'callback');
Changed: enable "jsonp callback" as a default
2012-04-15 11:20:25 -07:00
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
if (env === 'production') {
using connect.proto.use
2011-10-07 09:29:36 -07:00
this.enable('view cache');
delete semicolon
2014-01-19 23:53:48 +08:00
}
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
Object.defineProperty(this, 'router', {
get: function() {
throw new Error('\'app.router\' is deprecated!\nPlease see the 3.x to 4.x migration guide for details on how to update your app.');
}
});
};
/**
* lazily adds the base router if it has not yet been added.
*
* We cannot add the base router in the defaultConfiguration because
* it reads app settings which might be set after that has run.
*
* @api private
*/
app.lazyrouter = function() {
if (!this._router) {
this._router = new Router({
caseSensitive: this.enabled('case sensitive routing'),
strict: this.enabled('strict routing')
});
remove last pieces of connect dependency - copy over patch.js to shim ServerResponse - bundle `static` middleware
2014-02-15 20:20:12 -05:00
this._router.use(query());
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
this._router.use(middleware.init(this));
}
using connect.proto.use
2011-10-07 09:29:36 -07:00
};
/**
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
* Dispatch a req, res pair into the application. Starts pipeline processing.
*
* If no _done_ callback is provided, then default error handlers will respond
* in the event of an error bubbling through the stack.
*
* @api private
*/
app.handle = function(req, res, done) {
var env = this.get('env');
this._router.handle(req, res, function(err) {
if (done) {
return done(err);
}
// unhandled error
if (err) {
// default to 500
if (res.statusCode < 400) res.statusCode = 500;
debug('default %s', res.statusCode);
// respect err.status
if (err.status) res.statusCode = err.status;
// production gets a basic error message
var msg = 'production' == env
? http.STATUS_CODES[res.statusCode]
: err.stack || err.toString();
msg = escapeHtml(msg);
// log to stderr in a non-test env
if ('test' != env) console.error(err.stack || err.toString());
remove ServerResonse.headerSent monkey patch node.js ServerResponse contains a headersSent field. Use that instead of our patched misnamed version.
2014-02-17 23:36:56 -05:00
if (res.headersSent) return req.socket.destroy();
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
res.setHeader('Content-Type', 'text/html');
res.setHeader('Content-Length', Buffer.byteLength(msg));
if ('HEAD' == req.method) return res.end();
res.end(msg);
return;
}
// 404
debug('default 404');
res.statusCode = 404;
res.setHeader('Content-Type', 'text/html');
if ('HEAD' == req.method) return res.end();
res.end('Cannot ' + escapeHtml(req.method) + ' ' + escapeHtml(req.originalUrl) + '\n');
});
};
/**
* Proxy `Router#use()` to add middleware to the app router.
* See Router#use() documentation for details.
*
* If the _fn_ parameter is an express app, then it will be
* mounted at the _route_ specified.
using connect.proto.use
2011-10-07 09:29:36 -07:00
*
* @param {String|Function|Server} route
misc refactoring
2011-11-24 12:50:19 -08:00
* @param {Function|Server} fn
Added app.listen() as a shortcut for http.createServer(app).listen()
2011-11-11 17:22:25 -08:00
* @return {app} for chaining
using connect.proto.use
2011-10-07 09:29:36 -07:00
* @api public
*/
misc refactoring
2011-11-24 12:50:19 -08:00
app.use = function(route, fn){
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
var mount_app;
using connect.proto.use
2011-10-07 09:29:36 -07:00
app.path()
2011-12-06 15:36:44 -08:00
// default route to '/'
misc refactoring
2011-11-24 12:50:19 -08:00
if ('string' != typeof route) fn = route, route = '/';
using connect.proto.use
2011-10-07 09:29:36 -07:00
// express app
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
if (fn.handle && fn.set) mount_app = fn;
using connect.proto.use
2011-10-07 09:29:36 -07:00
// restore .app property on req and res
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
if (mount_app) {
debug('.use app under %s', route);
mount_app.mountpath = route;
misc refactoring
2011-11-24 12:50:19 -08:00
fn = function(req, res, next) {
using connect.proto.use
2011-10-07 09:29:36 -07:00
var orig = req.app;
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
mount_app.handle(req, res, function(err) {
restore req/res proto
2012-04-26 03:22:44 -07:00
req.__proto__ = orig.request;
res.__proto__ = orig.response;
using connect.proto.use
2011-10-07 09:29:36 -07:00
next(err);
});
};
}
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
this.lazyrouter();
this._router.use(route, fn);
using connect.proto.use
2011-10-07 09:29:36 -07:00
removed "root" setting screw it, no one will understand anyway
2011-11-24 14:27:28 -08:00
// mounted an app
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
if (mount_app) {
mount_app.parent = this;
mount_app.emit('mount', this);
using connect.proto.use
2011-10-07 09:29:36 -07:00
}
return this;
};
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
/**
* Proxy to the app `Router#route()`
* Returns a new `Route` instance for the _path_.
*
* Routes are isolated middleware stacks for specific paths.
* See the Route api docs for details.
*
* @api public
*/
app.route = function(path){
implement app.route()
2014-02-23 11:31:43 -05:00
this.lazyrouter();
return this._router.route(path);
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
};
using connect.proto.use
2011-10-07 09:29:36 -07:00
/**
added app.register()
2011-10-07 13:19:29 -07:00
* Register the given template engine callback `fn`
app.engine() docs
2012-04-18 17:23:54 -07:00
* as `ext`.
*
* By default will `require()` the engine based on the
* file extension. For example if you try to render
* a "foo.jade" file Express will invoke the following internally:
*
* app.engine('jade', require('jade').__express);
*
* For engines that do not provide `.__express` out of the box,
* or if you wish to "map" a different extension to the template engine
* you may use this method. For example mapping the EJS template engine to
docs
2012-04-25 17:59:02 -07:00
* ".html" files:
using connect.proto.use
2011-10-07 09:29:36 -07:00
*
Added new dox API docs
2012-04-15 21:01:17 -07:00
* app.engine('html', require('ejs').renderFile);
added app.register()
2011-10-07 13:19:29 -07:00
*
Added new dox API docs
2012-04-15 21:01:17 -07:00
* In this case EJS provides a `.renderFile()` method with
app.engine() docs
2012-04-18 17:23:54 -07:00
* the same signature that Express expects: `(path, options, callback)`,
* though note that it aliases this method as `ejs.__express` internally
* so if you're using ".ejs" extensions you dont need to do anything.
added app.register()
2011-10-07 13:19:29 -07:00
*
Added new dox API docs
2012-04-15 21:01:17 -07:00
* Some template engines do not follow this convention, the
* [Consolidate.js](https://github.com/visionmedia/consolidate.js)
* library was created to map all of node's popular template
* engines to follow this convention, thus allowing them to
typo
2013-02-08 08:42:47 -08:00
* work seamlessly within Express.
added app.register()
2011-10-07 13:19:29 -07:00
*
* @param {String} ext
* @param {Function} fn
Added app.listen() as a shortcut for http.createServer(app).listen()
2011-11-11 17:22:25 -08:00
* @return {app} for chaining
using connect.proto.use
2011-10-07 09:29:36 -07:00
* @api public
*/
Added app.engine() tests
2011-11-08 20:14:53 -08:00
app.engine = function(ext, fn){
throw when callback is not given to app.engine()
2012-04-04 12:30:25 -07:00
if ('function' != typeof fn) throw new Error('callback function required');
added app.register()
2011-10-07 13:19:29 -07:00
if ('.' != ext[0]) ext = '.' + ext;
this.engines[ext] = fn;
using connect.proto.use
2011-10-07 09:29:36 -07:00
return this;
};
/**
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
* Proxy to `Router#param()` with one added api feature. The _name_ parameter
* can be an array of names.
*
* See the Router#param() docs for more details.
using connect.proto.use
2011-10-07 09:29:36 -07:00
*
Added new dox API docs
2012-04-15 21:01:17 -07:00
* @param {String|Array} name
using connect.proto.use
2011-10-07 09:29:36 -07:00
* @param {Function} fn
Added app.listen() as a shortcut for http.createServer(app).listen()
2011-11-11 17:22:25 -08:00
* @return {app} for chaining
using connect.proto.use
2011-10-07 09:29:36 -07:00
* @api public
*/
app.param = function(name, fn){
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
var self = this;
self.lazyrouter();
using connect.proto.use
2011-10-07 09:29:36 -07:00
if (Array.isArray(name)) {
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
name.forEach(function(key) {
self.param(key, fn);
using connect.proto.use
2011-10-07 09:29:36 -07:00
});
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
return this;
using connect.proto.use
2011-10-07 09:29:36 -07:00
}
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
self._router.param(name, fn);
using connect.proto.use
2011-10-07 09:29:36 -07:00
return this;
};
/**
* Assign `setting` to `val`, or return `setting`'s value.
Added new dox API docs
2012-04-15 21:01:17 -07:00
*
* app.set('foo', 'bar');
* app.get('foo');
* // => "bar"
*
using connect.proto.use
2011-10-07 09:29:36 -07:00
* Mounted servers inherit their parent server's settings.
*
* @param {String} setting
Value parameter of app.set() is now typed optional mixed
2014-01-04 22:05:19 +01:00
* @param {*} [val]
Added new dox API docs
2012-04-15 21:01:17 -07:00
* @return {Server} for chaining
using connect.proto.use
2011-10-07 09:29:36 -07:00
* @api public
*/
app.set = function(setting, val){
Fixed app.set() with undefined
2011-12-15 09:00:39 -08:00
if (1 == arguments.length) {
inherit settings from parent application using [[Prototype]]
2013-02-08 12:58:07 +02:00
return this.settings[setting];
using connect.proto.use
2011-10-07 09:29:36 -07:00
} else {
this.settings[setting] = val;
improve proxy trust with ip address list closes #2099
2014-05-09 00:53:47 -04:00
if (setting === 'trust proxy') {
debug('compile trust proxy %j', val);
this.set('trust proxy fn', compileTrust(val));
}
using connect.proto.use
2011-10-07 09:29:36 -07:00
return this;
}
};
app.path()
2011-12-06 15:36:44 -08:00
/**
* Return the app's absolute pathname
* based on the parent(s) that have
* mounted it.
*
Added new dox API docs
2012-04-15 21:01:17 -07:00
* For example if the application was
* mounted as "/admin", which itself
* was mounted as "/blog" then the
* return value would be "/blog/admin".
*
app.path()
2011-12-06 15:36:44 -08:00
* @return {String}
* @api private
*/
app.path = function(){
return this.parent
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
? this.parent.path() + this.mountpath
app.path()
2011-12-06 15:36:44 -08:00
: '';
};
using connect.proto.use
2011-10-07 09:29:36 -07:00
/**
Added new dox API docs
2012-04-15 21:01:17 -07:00
* Check if `setting` is enabled (truthy).
*
* app.enabled('foo')
* // => false
*
* app.enable('foo')
* app.enabled('foo')
* // => true
using connect.proto.use
2011-10-07 09:29:36 -07:00
*
* @param {String} setting
* @return {Boolean}
* @api public
*/
app.enabled = function(setting){
return !!this.set(setting);
};
/**
* Check if `setting` is disabled.
*
Added new dox API docs
2012-04-15 21:01:17 -07:00
* app.disabled('foo')
* // => true
*
* app.enable('foo')
* app.disabled('foo')
* // => false
*
using connect.proto.use
2011-10-07 09:29:36 -07:00
* @param {String} setting
* @return {Boolean}
* @api public
*/
app.disabled = function(setting){
return !this.set(setting);
};
/**
* Enable `setting`.
*
* @param {String} setting
Added app.listen() as a shortcut for http.createServer(app).listen()
2011-11-11 17:22:25 -08:00
* @return {app} for chaining
using connect.proto.use
2011-10-07 09:29:36 -07:00
* @api public
*/
app.enable = function(setting){
return this.set(setting, true);
};
/**
* Disable `setting`.
*
* @param {String} setting
Added app.listen() as a shortcut for http.createServer(app).listen()
2011-11-11 17:22:25 -08:00
* @return {app} for chaining
using connect.proto.use
2011-10-07 09:29:36 -07:00
* @api public
*/
app.disable = function(setting){
return this.set(setting, false);
};
/**
add http verbs methods to Router By having the method verbs available on the router, users can set up disjoint routers and organized paths easier. It is now possible to have a .js file export the router.middleware and attach these paths using an `app.use('/path', middleware)` call. This means that any routes written in the separate file do not need to have a full path hardcoded as they can be mounted by the application anywhere. This is already possible using `router.route(verb, args)` however is needlessly verbose without this patch.
2012-12-25 16:39:48 -05:00
* Delegate `.VERB(...)` calls to `router.VERB(...)`.
using connect.proto.use
2011-10-07 09:29:36 -07:00
*/
methods.forEach(function(method){
app[method] = function(path){
fix behavior of multiple app.VERB for the same path fixes #2116
2014-05-15 10:30:52 -04:00
if (method === 'get' && arguments.length === 1) {
return this.set(path);
}
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
fix behavior of multiple app.VERB for the same path fixes #2116
2014-05-15 10:30:52 -04:00
var route = this._baseRoute(path);
support arrays as middleware arguments to .VERB and .all Express 3.x supported passing in arrays for sets of common middleware. While there are better ways to do this, removing this feature causes headache in upgrading for no real gain. We can support it without much more code.
2014-03-23 21:29:59 -04:00
route[method].apply(route, [].slice.call(arguments, 1));
fix route chaining regression. Closes #1397
2012-11-04 12:28:35 -08:00
return this;
};
using connect.proto.use
2011-10-07 09:29:36 -07:00
});
/**
* Special-cased "all" method, applying the given route `path`,
* middleware, and callback to _every_ HTTP method.
*
* @param {String} path
* @param {Function} ...
Added app.listen() as a shortcut for http.createServer(app).listen()
2011-11-11 17:22:25 -08:00
* @return {app} for chaining
using connect.proto.use
2011-10-07 09:29:36 -07:00
* @api public
*/
app.all = function(path){
fix behavior of multiple app.VERB for the same path fixes #2116
2014-05-15 10:30:52 -04:00
var route = this._baseRoute(path);
support arrays as middleware arguments to .VERB and .all Express 3.x supported passing in arrays for sets of common middleware. While there are better ways to do this, removing this feature causes headache in upgrading for no real gain. We can support it without much more code.
2014-03-23 21:29:59 -04:00
var args = [].slice.call(arguments, 1);
using connect.proto.use
2011-10-07 09:29:36 -07:00
methods.forEach(function(method){
support arrays as middleware arguments to .VERB and .all Express 3.x supported passing in arrays for sets of common middleware. While there are better ways to do this, removing this feature causes headache in upgrading for no real gain. We can support it without much more code.
2014-03-23 21:29:59 -04:00
route[method].apply(route, args);
remove app.router and refactor middleware processing This is an overhaul of middleware processing, Router and Route. Connect is no longer used to process the middleware stack. This functionality has been split into two parts: middleware stack and default error response. The entry point for request processing is the `app.handle` method. It sets up the default error response handle (to run in the event of no other error handler) and then triggers the app router (instance of Router) to handle the request. The app router `handle` function contains the middleware dispatch layer previously in the connect codebase. This layer handle the logic for dispatching `.use` calls (stripping paths if needed). The app contains a base router `app._router`. New routes can be created and `.use`d on this router to organize routes into files. Routers now have the following methods `.use`, `.all`, `.param` which are all public. Additionally, Routers have a `.route(path)` method which returns a new instance of Route for the requested path. Route(s) are isolated middleware stacks and contain methods for the HTTP verbs as well as an `.all` method to act similar to middleware. These methods are chainable to easily describe requirements for a route. var route = Router.route('/foo'); // or 'app.route('/foo')' route .all(auth) .get(function(...) {}) .all(more_checks) .post(function(...) {}) Any Route and Router methods which accept handlers also accept error (arity 4) handlers which will also behave as expected. Finally, the `app.router` getter has been removed. Middleware and handlers are run IN THE ORDER they are seen in the file. This means that code which injected the `app.router` and then added error handlers (or other middleware) will need to be updated to move those handlers after any requests added on the app object. The examples have been updated accordingly. This is the largest breaking change to codebases in this commit.
2014-01-25 17:57:25 -05:00
});
using connect.proto.use
2011-10-07 09:29:36 -07:00
return this;
};
// del -> delete alias
deprecate app.del closes #2095
2014-05-08 19:16:15 -04:00
app.del = deprecate(app.delete, 'app.del: Use app.delete instead');
using connect.proto.use
2011-10-07 09:29:36 -07:00
re-working view system
2011-10-07 13:07:19 -07:00
/**
new View
2011-10-07 14:51:06 -07:00
* Render the given view `name` name with `options`
re-working view system
2011-10-07 13:07:19 -07:00
* and a callback accepting an error and the
* rendered template string.
*
Added new dox API docs
2012-04-15 21:01:17 -07:00
* Example:
*
* app.render('email', { name: 'Tobi' }, function(err, html){
* // ...
* })
*
new View
2011-10-07 14:51:06 -07:00
* @param {String} name
misc refactoring
2011-10-07 13:34:03 -07:00
* @param {String|Function} options or fn
re-working view system
2011-10-07 13:07:19 -07:00
* @param {Function} fn
* @api public
*/
new View
2011-10-07 14:51:06 -07:00
app.render = function(name, options, fn){
some code cleanup
2014-03-25 15:23:04 -07:00
var opts = {};
var cache = this.cache;
var engines = this.engines;
var view;
re-working view system
2011-10-07 13:07:19 -07:00
// support callback function as second arg
misc refactoring
2011-10-07 13:34:03 -07:00
if ('function' == typeof options) {
fn = options, options = {};
re-working view system
2011-10-07 13:07:19 -07:00
}
// merge app.locals
use utils-merge module to mixin object properties
2014-01-24 19:16:37 -05:00
mixin(opts, this.locals);
merging res.locals
2011-10-07 13:50:31 -07:00
refactor res.render() to prevent clobbering "locals"
2012-08-11 15:04:54 -07:00
// merge options._locals
use utils-merge module to mixin object properties
2014-01-24 19:16:37 -05:00
if (options._locals) mixin(opts, options._locals);
merging res.locals
2011-10-07 13:50:31 -07:00
// merge options
use utils-merge module to mixin object properties
2014-01-24 19:16:37 -05:00
mixin(opts, options);
re-working view system
2011-10-07 13:07:19 -07:00
new View
2011-10-07 14:51:06 -07:00
// set .cache unless explicitly provided
opts.cache = null == opts.cache
? this.enabled('view cache')
: opts.cache;
re-working view system
2011-10-07 13:07:19 -07:00
new View
2011-10-07 14:51:06 -07:00
// primed cache
if (opts.cache) view = cache[name];
re-working view system
2011-10-07 13:07:19 -07:00
new View
2011-10-07 14:51:06 -07:00
// view
if (!view) {
add "view" constructor setting to override view behaviour
2013-04-13 09:53:50 -07:00
view = new (this.get('view'))(name, {
move default of "views" out so multiple cwd() calls are not made
2012-10-06 09:58:17 -07:00
defaultEngine: this.get('view engine'),
root: this.get('views'),
engines: engines
new View
2011-10-07 14:51:06 -07:00
});
added nicer error messages for failed view lookup. Closes #1065
2012-04-02 15:47:10 -07:00
if (!view.path) {
Error message now describes where the view was not able to be found. Useful for debugging.
2013-12-20 11:39:31 +00:00
var err = new Error('Failed to lookup view "' + name + '" in views directory "' + view.root + '"');
add err.view property for view errors. Closes #1226
2012-07-11 08:45:37 -07:00
err.view = view;
return fn(err);
added nicer error messages for failed view lookup. Closes #1065
2012-04-02 15:47:10 -07:00
}
new View
2011-10-07 14:51:06 -07:00
// prime the cache
if (opts.cache) cache[name] = view;
}
re-working view system
2011-10-07 13:07:19 -07:00
// render
try {
new View
2011-10-07 14:51:06 -07:00
view.render(opts, fn);
re-working view system
2011-10-07 13:07:19 -07:00
} catch (err) {
fn(err);
}
};
Added new dox API docs
2012-04-15 21:01:17 -07:00
/**
* Listen for connections.
*
* A node `http.Server` is returned, with this
* application (which is a `Function`) as its
* callback. If you wish to create both an HTTP
* and HTTPS server you may do so with the "http"
docs
2012-04-25 17:59:02 -07:00
* and "https" modules as shown here:
Added new dox API docs
2012-04-15 21:01:17 -07:00
*
* var http = require('http')
* , https = require('https')
* , express = require('express')
* , app = express();
*
* http.createServer(app).listen(80);
Update lib/application.js typo: http -> https
2012-09-05 05:20:37 +10:00
* https.createServer({ ... }, app).listen(443);
Added new dox API docs
2012-04-15 21:01:17 -07:00
*
* @return {http.Server}
* @api public
*/
app.listen = function(){
var server = http.createServer(this);
return server.listen.apply(server, arguments);
};
fix behavior of multiple app.VERB for the same path fixes #2116
2014-05-15 10:30:52 -04:00
/**
* Get or create a new base route for path.
*
* @param {String} path
* @return {Route}
* @api private
*/
app._baseRoute = function(path){
this.lazyrouter();
var key = typeof path !== 'string'
? 'o:' + String(path)
: 's:' + path;
if (path.ignoreCase || !this._router.caseSensitive) {
key = 'i' + key.toLowerCase();
}
var route = this._baseRoutes[key];
if (!route) {
route = this._router.route(path);
this._baseRoutes[key] = route;
}
return route;
};
Reference in New Issue Copy Permalink