Skip to content
This repository

Minor typos fixed in guide.md #848

Closed
wants to merge 1 commit into from

2 participants

tshinnic Jonathan Ong
tshinnic

Very minor. My playing with different markdown apps got me to read the spec enough to know how to fix "req.body._method" to "req.body._method" in order to get the embedded '_' to work with discount.

Check the mime 'type' <--> 'subtype' reversal. I'm pretty sure I've got it right. (section req.is() approx. line 685)

I'll have to check some stuff before next pull request and consult with you whether I'm right / wrong / other ...

Jonathan Ong
Collaborator

sorry for the delay. the express docs have moved from the gh-pages branch to https://github.com/visionmedia/expressjs.com

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Showing 1 unique commit by 1 author.

Sep 28, 2011
tshinnic tshinnic Minor typos fixed in guide.md 1914722
This page is out of date. Refresh to see the latest.

Showing 1 changed file with 19 additions and 19 deletions. Show diff stats Hide diff stats

  1. +19 19 docs/guide.md
38 docs/guide.md
Source Rendered
@@ -124,13 +124,13 @@ are available as `req.params`.
124 124 res.send('user ' + req.params.id);
125 125 });
126 126
127   -A route is simple a string which is compiled to a _RegExp_ internally. For example
  127 +A route is simply a string which is compiled to a _RegExp_ internally. For example
128 128 when _/user/:id_ is compiled, a simplified version of the regexp may look similar to:
129 129
130 130 \/user\/([^\/]+)\/?
131 131
132 132 Regular expression literals may also be passed for complex uses. Since capture
133   -groups with literal _RegExp_'s are anonymous we can access them directly `req.params`. So our first capture group would be _req.params[0]_ and the second would follow as _req.params[1]_.
  133 +groups with literal _RegExp_'s are anonymous we can access them directly via `req.params`. So our first capture group would be _req.params[0]_ and the second would follow as _req.params[1]_.
134 134
135 135 app.get(/^\/users?(?:\/(\d+)(?:\.\.(\d+))?)?/, function(req, res){
136 136 res.send(req.params);
@@ -277,7 +277,7 @@ This is somewhat annoying, so express re-exports these middleware properties, ho
277 277 app.use(express.logger());
278 278 app.use(express.bodyParser());
279 279
280   -Middleware ordering is important, when Connect receives a request the _first_ middleware we pass to _createServer()_ or _use()_ is executed with three parameters, _request_, _response_, and a callback function usually named _next_. When _next()_ is invoked the second middleware will then have it's turn and so on. This is important to note because many middleware depend on each other, for example _methodOverride()_ checks _req.body._method_ for the HTTP method override, however _bodyParser()_ parses the request body and populates _req.body_. Another example of this is cookie parsing and session support, we must first _use()_ _cookieParser()_ followed by _session()_.
  280 +Middleware ordering is important, when Connect receives a request the _first_ middleware we pass to _createServer()_ or _use()_ is executed with three parameters, _request_, _response_, and a callback function usually named _next_. When _next()_ is invoked the second middleware will then have its turn and so on. This is important to note because many middleware depend on each other, for example _methodOverride()_ checks _req.body.\_method_ for the HTTP method override, however _bodyParser()_ parses the request body and populates _req.body_. Another example of this is cookie parsing and session support, we must first _use()_ _cookieParser()_ followed by _session()_.
281 281
282 282 Many Express applications may contain the line _app.use(app.router)_, while this may appear strange, it's simply the middleware function that contains all defined routes, and performs route lookup based on the current request url and HTTP method. Express allows you to position this middleware, though by default it will be added to the bottom. By positioning the router, we can alter middleware precedence, for example we may want to add error reporting as the _last_ middleware so that any exception passed to _next()_ will be handled by it, or perhaps we want static file serving to have low precedence, allowing our routes to intercept requests to a static file to count downloads etc. This may look a little like below
283 283
@@ -346,7 +346,7 @@ Multiple route middleware can be applied, and will be executed sequentially to a
346 346 res.send('Editing user ' + req.user.name);
347 347 });
348 348
349   -Keeping in mind that middleware are simply functions, we can define function that _returns_ the middleware in order to create a more expressive and flexible solution as shown below.
  349 +Keeping in mind that middleware are simply functions, we can define a function that _returns_ the middleware in order to create a more expressive and flexible solution as shown below.
350 350
351 351 function andRestrictTo(role) {
352 352 return function(req, res, next) {
@@ -375,13 +375,13 @@ Commonly used "stacks" of middleware can be passed as an array (_applied recursi
375 375
376 376 For this example in full, view the [route middleware example](http://github.com/visionmedia/express/blob/master/examples/route-middleware/app.js) in the repository.
377 377
378   -There are times when we may want to "skip" passed remaining route middleware, but continue matching subsequent routes. To do this we invoke `next()` with the string "route" `next('route')`. If no remaining routes match the request url then Express will respond with 404 Not Found.
  378 +There are times when we may want to "skip" past remaining route middleware, but continue matching subsequent routes. To do this we invoke `next()` with the string "route" `next('route')`. If no remaining routes match the request url then Express will respond with 404 Not Found.
379 379
380 380 ### HTTP Methods
381 381
382 382 We have seen _app.get()_ a few times, however Express also exposes other familiar HTTP verbs in the same manner, such as _app.post()_, _app.del()_, etc.
383 383
384   - A common example for _POST_ usage, is when "submitting" a form. Below we simply set our form method to "post" in our html, and control will be given to the route we have defined below it.
  384 + A common example for _POST_ usage is when "submitting" a form. Below we simply set our form method to "post" in our html, and control will be given to the route we have defined below it.
385 385
386 386 <form method="post" action="/">
387 387 <input type="text" name="user[name]" />
@@ -400,12 +400,12 @@ Our route below will now have access to the _req.body.user_ object which will co
400 400 res.redirect('back');
401 401 });
402 402
403   -When using methods such as _PUT_ with a form, we can utilize a hidden input named _\_method_, which can be used to alter the HTTP method. To do so we first need the _methodOverride_ middleware, which should be placed below _bodyParser_ so that it can utilize it's _req.body_ containing the form values.
  403 +When using methods such as _PUT_ with a form, we can utilize a hidden input named _\_method_, which can be used to alter the HTTP method. To do so we first need the _methodOverride_ middleware, which should be placed below _bodyParser_ so that it can utilize its _req.body_ containing the form values.
404 404
405 405 app.use(express.bodyParser());
406 406 app.use(express.methodOverride());
407 407
408   -The reason that these are not always defaults, is simply because these are not required for Express to be fully functional. Depending on the needs of your application, you may not need these at all, your methods such as _PUT_ and _DELETE_ can still be accessed by clients which can use them directly, although _methodOverride_ provides a great solution for forms. Below shows what the usage of _PUT_ might look like:
  408 +The reason that these are not always added by default is simply because these are not required for Express to be fully functional. Depending on the needs of your application, you may not need these at all, your methods such as _PUT_ and _DELETE_ can still be accessed by clients which can use them directly, although _methodOverride_ provides a great solution for forms. Below shows what the usage of _PUT_ might look like:
409 409
410 410 <form method="post" action="/">
411 411 <input type="hidden" name="_method" value="put" />
@@ -443,7 +443,7 @@ Route param pre-conditions can drastically improve the readability of your appli
443 443 });
444 444 });
445 445
446   -With preconditions our params can be mapped to callbacks which may perform validation, coercion, or even loading data from a database. Below we invoke _app.param()_ with the parameter name we wish to map to some middleware, as you can see we receive the _id_ argument which contains the placeholder value. Using this we load the user and perform error handling as usual, and simple call _next()_ to pass control to the next precondition or route handler.
  446 +With preconditions our params can be mapped to callbacks which may perform validation, coercion, or even loading data from a database. Below we invoke _app.param()_ with the parameter name we wish to map to some middleware, as you can see we receive the _id_ argument which contains the placeholder value. Using this we load the user and perform error handling as usual, and simply call _next()_ to pass control to the next precondition or route handler.
447 447
448 448 app.param('userId', function(req, res, next, id){
449 449 User.get(id, function(err, user){
@@ -569,7 +569,7 @@ By default the _session_ middleware uses the memory store bundled with Connect,
569 569 app.use(express.cookieParser());
570 570 app.use(express.session({ secret: "keyboard cat", store: new RedisStore }));
571 571
572   -Now the _req.session_ and _req.sessionStore_ properties will be accessible to all routes and subsequent middleware. Properties on _req.session_ are automatically saved on a response, so for example if we wish to shopping cart data:
  572 +Now the _req.session_ and _req.sessionStore_ properties will be accessible to all routes and subsequent middleware. Properties on _req.session_ are automatically saved on a response, so for example if we wish to have shopping cart data:
573 573
574 574 var RedisStore = require('connect-redis')(express);
575 575 app.use(express.bodyParser());
@@ -608,7 +608,7 @@ Get the case-insensitive request header _key_, with optional _defaultValue_:
608 608 req.header('host');
609 609 req.header('Accept', '*/*');
610 610
611   -The _Referrer_ and _Referer_ header fields are special-cased, either will work:
  611 +The _Referrer_ and _Referer_ header fields are special-cased aliases, either will work:
612 612
613 613 // sent Referrer: http://google.com
614 614
@@ -623,7 +623,7 @@ The _Referrer_ and _Referer_ header fields are special-cased, either will work:
623 623 Check if the _Accept_ header is present, and includes the given _type_.
624 624
625 625 When the _Accept_ header is not present _true_ is returned. Otherwise
626   -the given _type_ is matched by an exact match, and then subtypes. You
  626 +the given _type_ is matched by an exact match, and then using subtypes. You
627 627 may pass the subtype such as "html" which is then converted internally
628 628 to "text/html" using the mime lookup table.
629 629
@@ -661,7 +661,7 @@ header field, and it contains the give mime _type_.
661 661 // => false
662 662
663 663 Ad-hoc callbacks can also be registered with Express, to perform
664   -assertions again the request, for example if we need an expressive
  664 +assertions against the request, for example if we need an expressive
665 665 way to check if our incoming request is an image, we can register _"an image"_
666 666 callback:
667 667
@@ -669,7 +669,7 @@ callback:
669 669 return 0 == req.headers['content-type'].indexOf('image');
670 670 });
671 671
672   -Now within our route callbacks, we can use to to assert content types
  672 +Now within our route callbacks, we can use it to assert content types
673 673 such as _"image/jpeg"_, _"image/png"_, etc.
674 674
675 675 app.post('/image/upload', function(req, res, next){
@@ -683,11 +683,11 @@ such as _"image/jpeg"_, _"image/png"_, etc.
683 683 Keep in mind this method is _not_ limited to checking _Content-Type_, you
684 684 can perform any request assertion you wish.
685 685
686   -Wildcard matches can also be made, simplifying our example above for _"an image"_, by asserting the _subtype_ only:
  686 +Wildcard matches can also be made, simplifying our example above for _"an image"_, by asserting the _type_ only:
687 687
688 688 req.is('image/*');
689 689
690   -We may also assert the _type_ as shown below, which would return true for _"application/json"_, and _"text/json"_.
  690 +We may also assert the _subtype_ as shown below, which would return true for _"application/json"_, and _"text/json"_.
691 691
692 692 req.is('*/json');
693 693
@@ -701,7 +701,7 @@ Return the value of param _name_ when present or _default_.
701 701
702 702 To utilize urlencoded request bodies, _req.body_
703 703 should be an object. This can be done by using
704   -the _express.bodyParser middleware.
  704 +the _express.bodyParser_ middleware.
705 705
706 706 ### req.get(field, param)
707 707
@@ -1317,7 +1317,7 @@ files to jade:
1317 1317
1318 1318 app.register('.html', require('jade'));
1319 1319
1320   -This is also useful for libraries that may not
  1320 +This is also useful for library names that may not
1321 1321 match extensions correctly. For example my haml.js
1322 1322 library is installed from npm as "hamljs" so instead
1323 1323 of layout.hamljs, we can register the engine as ".haml":
@@ -1363,4 +1363,4 @@ Then try it out:
1363 1363 Content-Type: text/plain
1364 1364 Content-Length: 11
1365 1365
1366   - Hello World
  1366 + Hello World

Tip: You can add notes to lines in a file. Hover to the left of a line to make a note

Something went wrong with that request. Please try again.