typo fixes

lib/Dancer2.pm

@@ -57,7 +57,7 @@ language.
 
 There are some situations that are common to a lot of users. For
 example, application deployment. On L<Dancer2::Cookbook> you will find
-reciped for common tasks, from defining routes, storing data as
+recipes for common tasks, from defining routes, storing data as
 sessions or cookies, using templates, configuring and logging, writing
 REST services and deploying your dancer application using different
 technologies.

lib/Dancer2/Config.pod

@@ -264,7 +264,7 @@ L<Dancer2::Config::Object> for more information.
 =head3 startup_info (boolean)
 
 If set to true, prints a banner at the server start with information such as
-versions and the environment (or "dancerfloor").
+versions and the environment (or "dancefloor").
 
 Conforms to the environment variable C<DANCER_STARTUP_INFO>.
 

lib/Dancer2/Cookbook.pod

@@ -645,7 +645,7 @@ variables.
 =head2 Configuration and environments
 
 Configuring a Dancer2 application can be done in many ways. The easiest one (and
-maybe the the dirtiest) is to put all your settings statements at the top of
+maybe the dirtiest) is to put all your settings statements at the top of
 your script, before calling the dance() method.
 
 Other ways are possible, you can define all your settings in the file

lib/Dancer2/Core/App.pm

@@ -119,7 +119,7 @@ around add_hook => sub {
     # if that hook belongs to the app, register it now and return
     return $self->$orig(@_) if $self->has_hook($name);
 
-    # at this point the hook name must be formated like:
+    # at this point the hook name must be formatted like:
     # '$type.$candidate.$name', eg: 'engine.template.before_render' or
     # 'plugin.database.before_dbi_connect'
     my ( $hookable_type, $hookable_name, $hook_name ) = split( /\./, $name );

lib/Dancer2/Core/Context.pm

@@ -261,7 +261,7 @@ has destroyed_session => (
 
 =method destroy_session
 
-Destroys the current session and ensures any subsquent session is created
+Destroys the current session and ensures any subsequent session is created
 from scratch and not from the request session cookie
 
 =cut

lib/Dancer2/Core/Dispatcher.pm

@@ -30,7 +30,7 @@ sub dispatch {
 #       . " with ".join(", ", map { $_->name } @{$self->apps });
 
     # Initialize a context for the current request
-    # Once per didspatching! We should not create one context for each app or
+    # Once per dispatching! We should not create one context for each app or
     # we're going to parse the request body multiple times
     my $context = Dancer2::Core::Context->new(
         env => $env,
@@ -155,7 +155,7 @@ sub _dispatch_route {
 # In the case of a HEAD request, we need to drop the body, but we also
 # need to keep the value of the Content-Length header.
 # Because there's a trigger on the content field to change the value of
-# the C-L header everytime we change the value, we need to modify a around
+# the C-L header every time we change the value, we need to modify a around
 # modifier to change the value of content and restore the length.
 around 'dispatch' => sub {
     my ( $orig, $self, $env, $request, $curr_context ) = @_;

lib/Dancer2/Core/Error.pm

@@ -342,7 +342,7 @@ Create a backtrace of the code where the error is caused.
 This method tries to find out where the error appeared according to the actual
 error message (using the C<message> attribute) and tries to parse it (supporting
 the regular/default Perl warning or error pattern and the L<Devel::SimpleTrace>
-output) and then returns an error-higlighted C<message>.
+output) and then returns an error-highlighted C<message>.
 
 =cut
 
@@ -485,7 +485,7 @@ sub environment {
 
 =method get_caller
 
-Creates a strack trace of callers.
+Creates a stack trace of callers.
 
 =cut
 

lib/Dancer2/Core/Request.pm

@@ -874,7 +874,7 @@ table provided by C<uploads()>. It looks at the calling context and returns a
 corresponding value.
 
 If you have many file uploads under the same name, and call C<upload('name')> in
-an array context, the accesor will unroll the ARRAY ref for you:
+an array context, the accessor will unroll the ARRAY ref for you:
 
     my @uploads = request->upload('many_uploads'); # OK
 
@@ -905,7 +905,7 @@ sub _build_params {
     # _before_ we get there, so we have to save it first
     my $previous = $self->_has_params ? $self->_params : {};
 
-    # now parse environement params...
+    # now parse environment params...
     $self->_parse_get_params();
     if ( $self->body_is_parsed ) {
         $self->{_body_params} ||= {};

lib/Dancer2/Core/Response.pm

@@ -264,7 +264,7 @@ sub error {
 
     $response->serialize( $content );
 
-Serialize and return $content with the respone's serializer.
+Serialize and return $content with the response's serializer.
 set content-type accordingly.
 
 =cut

lib/Dancer2/Core/Role/Logger.pm

@@ -210,7 +210,7 @@ Log messages as B<error>.
 
 =method format_message
 
-Provides a common message formating.
+Provides a common message formatting.
 
 =attr auto_encoding_charset
 

lib/Dancer2/Core/Role/SessionFactory.pm

@@ -290,7 +290,7 @@ destroyed session if succeeded, triggers an exception otherwise.
     MySessionFactory->destroy(id => $id);
 
 The C<_destroy> method must be implemented. It must take C<$id> as a single
-argumenet and destroy the underlying data.
+argument and destroy the underlying data.
 
 =cut
 

lib/Dancer2/Manual.pod

@@ -1221,7 +1221,7 @@ You can also force Dancer to return a specific 300-ish HTTP response code:
 
 Returns a L<Dancer2::Core::Request> object representing the current request.
 
-See the L<Dancer2::Core::Request> documention for the methods you can call, for
+See the L<Dancer2::Core::Request> documentation for the methods you can call, for
 example:
 
     request->referer;         # value of the HTTP referer header
@@ -1382,7 +1382,7 @@ Note that Dancer is unable to guess the content type from the data
 contents. Therefore you might need to set the C<content_type>
 properly. For this kind of usage an attribute named C<filename> can be
 useful.  It is used as the Content-Disposition header, to hint the
-brower about the filename it should use.
+browser about the filename it should use.
 
    return send_file( \$data, content_type => 'image/png'
                              filename     => 'onion.png' );
@@ -1524,7 +1524,7 @@ build a response with the current template engine:
     };
 
 Note that C<template> simply returns the content, so when you use it in a route
-handler, if execution of the the route handler should stop at that point, make
+handler, if execution of the route handler should stop at that point, make
 sure you use 'return' to ensure your route handler returns the content.
 
 Since template just returns the result of rendering the template, you can also

lib/Dancer2/Template/Tiny.pm

@@ -49,7 +49,7 @@ This template engine allows you to use L<Template::Tiny> in L<Dancer2>.
 L<Template::Tiny> is an implementation of a subset of L<Template::Toolkit> (the
 major parts) which takes much less memory and is faster. If you're only using
 the main functions of Template::Toolkit, you could use Template::Tiny. You can
-also seemlessly move back to Template::Toolkit whenever you want.
+also seamlessly move back to Template::Toolkit whenever you want.
 
 However, Dancer2 uses a modified version of L<Template::Tiny>, which is L<Dancer2::Template::Implementation::ForkedTiny>. It adds 2 features :
 

lib/Dancer2/Test.pm

@@ -682,7 +682,7 @@ Asserts that your apps have pods for all routes
 
     is_pod_covered 'is pod covered'
 
-to avoid test failures, you shoud document all your routes with one of the following:
+to avoid test failures, you should document all your routes with one of the following:
 head1, head2,head3,head4, item.
 
     ex:

lib/Dancer2/Tutorial.pod

@@ -188,7 +188,7 @@ In addition, the C<PATCH> verb was defined in
 L<RFC5789|http://tools.ietf.org/html/rfc5789>, and is intended as a
 "partial PUT" - sending just the changes required to the entity in question.
 How this would be handled is down to your app, it will vary depending on the
-type of entity in question and the serialisation in use.
+type of entity in question and the serialization in use.
 
 Dancer2 currently supports GET, PUT/PATCH, POST, DELETE, OPTIONS which map to
 Retrieve, Update, Create, Delete respectively.  Let's take a look now at the
@@ -575,7 +575,7 @@ I hope this effort has been helpful and interesting enough to get you exploring
 Dancer2 on your own. The framework is still under heavy development but it's
 definitely mature enough to use in a production project.  Additionally, there
 are now a lot of great Dancer2 plugins which extend and enhance the capabilities
-of the the platform.
+of the platform.
 
 Happy dancing!