| Subject: | documentation typos |
--- CallbackHandle.pm.orig 2003-04-28 19:04:25.000000000 +0200
+++ CallbackHandle.pm 2003-04-28 19:13:03.000000000 +0200
@@ -106,7 +106,7 @@
=head1 NAME
-MasonX::CallbackHandle - Callback Requst Data and Utility Methods
+MasonX::CallbackHandle - Callback Request Data and Utility Methods
=head1 SYNOPSIS
@@ -199,7 +199,7 @@
Returns the value of the callback trigger field. If there is more than one
value for the callback trigger field, then C<value()> will return an array
-reference. For examle, for this callback field:
+reference. For example, for this callback field:
<input type="hidden" value="foo" name="DEFAULT|save_cb" />
@@ -240,7 +240,7 @@
B<Note:> Most browers will submit "image" input fields with two arguments, one
with ".x" appended to its name, and the other with ".y" appended to its
-name. MasonX:::ApacheHandler::WithCallbacks will ignore these fields and
+name. MasonX::ApacheHandler::WithCallbacks will ignore these fields and
either use the field named without the ".x" or ".y", or create a field with
that name and give it a value of "1". The reasoning behind this approach is
that the names of the callback-triggering fields should be the same as the
@@ -250,8 +250,8 @@
$cbh->redirect($url) unless $cbh->redirected;
-If the request has been redirected, this method returns the rediretion
-URL. Otherwise, it eturns false. This method is useful for conditions in which
+If the request has been redirected, this method returns the redirection
+URL. Otherwise, it returns false. This method is useful for conditions in which
one callback has called C<< $cbh->redirect >> with the optional C<$wait>
argument set to a true value, thus allowing subsequent callbacks to continue
to execute. If any of those subsequent callbacks want to call
@@ -277,7 +277,7 @@
default, the status code used is "302", but this can be overridden via the
C<$status> argument. If the optional C<$wait> argument is true, any callbacks
scheduled to be executed after the call to C<redirect> will continue to be
-executed. In that clase, C<< $cbh->abort >> will not be called; rather,
+executed. In that case, C<< $cbh->abort >> will not be called; rather,
MasonX::ApacheHandler::WithCallbacks will finish executing all remaining
callbacks and then check the status and abort before Mason creates and
executes a component stack. If the C<$wait> argument is unspecified or false,
--- ApacheHandler/WithCallbacks.pm.orig 2003-04-28 19:04:31.000000000 +0200
+++ ApacheHandler/WithCallbacks.pm 2003-04-28 19:36:39.000000000 +0200
@@ -367,7 +367,7 @@
directing Mason to execute those subroutines as callbacks, you obviously
benefit from a cleaner separation of application logic and presentation.
-=item Wigitization
+=item Widgitization
Thanks to their ability to preprocess arguments, callbacks enable developers
to develop easier-to-use, more dynamic widgets that can then be used in any
@@ -405,8 +405,8 @@
=back
-And if those are enough reasons, then just consider this: Callbacks just I<way
-cool.>
+And if those aren't enough reasons, then just consider this: Callbacks are
+just I<way cool.>
=head1 USAGE
@@ -539,7 +539,7 @@
default_priority => 2 );
Will cause the "save" callback to always execute before the "setup" callback,
-since it's priority level will default to "2".
+since its priority level will default to "2".
Conversely, the priority level can be overridden via the form submission field
itself by appending a priority level to the end of the callback field
@@ -574,16 +574,16 @@
Although they may be used for different purposes, the C<pre_callbacks> and
C<post_callbacks> callback code references expect the same argument as
-argument-triggered callbacks: a MasonX::CallbackHandleObject:
+argument-triggered callbacks: a MasonX::CallbackHandle object:
sub foo {
my $cbh = shift;
# Do your business here.
}
-Of course, the attributes of the MasonX::CallbackHandleObject object will be
+Of course, the attributes of the MasonX::CallbackHandle object object will be
different than in argument-triggered callbacks. For example, the C<priority>,
-C<pkg_key>, and C<cb_key> attributes will naturaly be undefined.
+C<pkg_key>, and C<cb_key> attributes will naturally be undefined.
Like the argument-triggered callbacks, however, like the argument-triggered
callbacks, request callbacks are executed in a C<eval {}> block, so if any of
@@ -644,7 +644,7 @@
executed for I<every> request I<before> any other callbacks. Each code
reference should expect a single MasonX::CallbackHandle argument. Use
pre-argument-triggered request callbacks when you want to do something with
-the arguments sumitted for every request, such as convert character sets.
+the arguments submitted for every request, such as convert character sets.
=item C<post_callbacks>
@@ -652,7 +652,7 @@
executed for I<every> request I<after> all other callbacks have been
called. Each code reference should expect a single MasonX::CallbackHandle
argument. Use post-argument-triggered request callbacks when you want to do
-something with the arguments sumitted for every request, such as HTML-escape
+something with the arguments submitted for every request, such as HTML-escape
their values.
=item C<default_priority>