Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

typo fixes #507

Closed
wants to merge 15 commits into from
Commits on Nov 17, 2013
  1. @dsteinbrunner

    typo fix

    dsteinbrunner authored
  2. @dsteinbrunner

    typo fixes

    dsteinbrunner authored
  3. @dsteinbrunner

    typo fix

    dsteinbrunner authored
  4. @dsteinbrunner

    typo fix

    dsteinbrunner authored
  5. @dsteinbrunner

    typo fix

    dsteinbrunner authored
  6. @dsteinbrunner

    typo fix

    dsteinbrunner authored
  7. @dsteinbrunner

    typo fixes

    dsteinbrunner authored
  8. @dsteinbrunner

    typo fixes

    dsteinbrunner authored
  9. @dsteinbrunner

    typo fixes

    dsteinbrunner authored
  10. @dsteinbrunner

    typo fix

    dsteinbrunner authored
  11. @dsteinbrunner

    typo fix

    dsteinbrunner authored
  12. @dsteinbrunner

    typo fix

    dsteinbrunner authored
  13. @dsteinbrunner

    typo fixes

    dsteinbrunner authored
  14. @dsteinbrunner

    typo fix

    dsteinbrunner authored
  15. @dsteinbrunner

    typo fix

    dsteinbrunner authored
This page is out of date. Refresh to see the latest.
View
2  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.
View
2  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>.
View
2  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
View
2  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 );
View
2  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
View
4 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 ) = @_;
View
4 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
View
4 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} ||= {};
View
2  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
View
2  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
View
2  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
View
6 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
View
2  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 :
View
2  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:
View
4 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!
Something went wrong with that request. Please try again.