Merge pull request #31 from tamias/master

Fix errors in the manual

lib/HTML/FormHandler/Manual/Catalyst.pod

@@ -94,7 +94,7 @@ or set them in a base Chained method.
 
 Then you could just pass in the item_id when the form is processed.
 
-   return unless $c->stash->{form}->process($id);
+   return unless $c->stash->{form}->process( item_id => $id );
 
 =head2 Putting a form in a Moose attribute
 
@@ -113,7 +113,7 @@ C<< my $result = $self->edit_form->run( params => $c->req->body_parameters ); >>
 
 =head2 Using  HTML::FillInForm
 
-If you want to use L<HTML::FillInForm> to fill in values instead of the
+If you want to use L<HTML::FillInForm> to fill in values instead of
 doing it in directly in a template using either the field or the form 'fif'
 methods, you can use L<Catalyst::View::FillInForm> on your view class:
 
@@ -130,7 +130,7 @@ and set the 'fif' hash in the 'fillinform' stash variable:
     return unless $form->validated;
 
 When the 'fillinform' stash variable is set, HTML::FillInForm will automatically
-be used by your view to fill in the the form values. This can be very helpful
+be used by your view to fill in the form values. This can be very helpful
 when you want to build your forms by hand, or when you have legacy forms that
 you're just trying to hook up to FormHandler.
 

lib/HTML/FormHandler/Manual/Cookbook.pod

@@ -11,7 +11,7 @@ Collection of use recipes for L<HTML::FormHandler>
 
 I had to create a tiny little form this week for admins to enter a comment, and
 it seemed silly to have to create a form file and a template file. I remembered
-that you can set the TT 'template' to a a string reference and not use a template
+that you can set the TT 'template' to a string reference and not use a template
 at all, which is nice when FormHandler will create the form HTML for you anyway.
 
     sub comment : Chained('base_sub') PathPart('comment') Args(0) {
@@ -147,7 +147,7 @@ Or you can do in a template:
      [% END %]
    </select>
 
-You can create a customi the select list in an 'options_' method:
+You can create a custom select list in an 'options_' method:
 
    sub options_country {
       my $self = shift;
@@ -348,7 +348,7 @@ Then just use an additional parameter when you create/process your form:
     $form->process( item => $item, params => $params, hostname => $c->req->host );
 
 Some kinds of DB relationships need to have primary keys which might be more easily
-set in the update model method;
+set in the update_model method;
 
     sub update_model {
         my $self = shift;
@@ -639,7 +639,7 @@ For updating a Repeatable field that is filled from a Resultset, and not a
 relationship on a single row. Creates a 'resultset' attribute to pass in
 a resultset. Massages the data into an array that's pointed to by an
 'employers' hash key, and does the reverse in the 'update_model' method.
-Yes, it's a kludge, but it could be worse. If you want to impement a more
+Yes, it's a kludge, but it could be worse. If you want to implement a more
 general solution, patches welcome.
 
     package Test::Resultset;
@@ -700,7 +700,7 @@ You can use 'update_field_list' or 'defaults' on the 'process' call:
 
     $form->process( update_field_list => { foo => { default => $foo_value } } );
     -- or --
-    $form->proces( defaults => { foo => $foo_value } );
+    $form->process( defaults => { foo => $foo_value } );
 
 You can set a Moose attribute in the form class, and set the default in a
 default_<field_name> method:
@@ -728,7 +728,7 @@ method:
 
 =head2 Static form, dynamic field IDs
 
-The problem: you have a form that will be used in multiple places on a page, but you don't
+The problem: you have a form that will be used in multiple places on a page, but you
 want to use a static form instead of doing 'new' for each. You can pass a form name in
 on the process call and use 'html_prefix' in the form:
 
@@ -782,7 +782,7 @@ Use 'build_id_method' to give your fields a different format 'id':
         return $full_name;
     }
 
-The above method provides an IDs of "foo_two" and "foo_three" instead of
+The above method provides IDs of "foo_two" and "foo_three" instead of
 "foo.two" and "foo.three".
 
 =cut

lib/HTML/FormHandler/Manual/Database.pod

@@ -24,10 +24,10 @@ selection lists, and validate input. A 'single' relationship is processed
 by L<HTML::FormHandler::Field::Compound>. A 'has_many' relationship is
 processed by L<HTML::FormHandler::Field::Repeatable>.
 
-You can pass in either the primary key and or a row object to the form. If a
+You can pass in either the primary key or a row object to the form. If a
 primary key (item_id) is passed in, you must also provide the schema.
 The model will use the item_class (DBIC source name) to fetch the row from the
-database. If you pass in a row object (item), the schema, source_class, and
+database. If you pass in a row object (item), the schema, item_class, and
 item_id will be set from the row.
 
 Executing C<< $form->process( item => $row, params => $params ); >> will validate

lib/HTML/FormHandler/Manual/Errors.pod

@@ -87,7 +87,7 @@ use in the validation process.
 
 =item errors
 
-Returns an array of error strings;
+Returns an array of error strings.
 
 =item has_errors
 
@@ -107,7 +107,7 @@ Add an error without localization.
 
 =item error_fields
 
-In a compound field (and it's subclasses, like 'Repeatable'), the list
+In a compound field (and its subclasses, like 'Repeatable'), the list
 of fields with errors.
 
 =back

lib/HTML/FormHandler/Manual/Fields.pod

@@ -103,9 +103,9 @@ before processing by HFH, and will be added back in 'fif'. The field's
 
 If you want the FormHandler field name to be different than the
 database accessor, set 'accessor' on your fields. (It defaults to the field
-name). You could then use any name that you want for your field.
+name.) You could then use any name that you want for your field.
 
-There are a number of name related field attributes. The 'name' is
+There are a number of name-related field attributes. The 'name' is
 the name used to identify this particular field in this fields array.
 The 'full_name' includes the names of all parents of this field,
 like 'address.street.streetname'. The 'html_name' is the same as the
@@ -128,7 +128,7 @@ which is called by the base Field class from 'process'. Look at
 L<HTML::FormHandler::Field::Email>, for example.
 
 If the field's value will be an object instead of a simple scalar, such
-as a DateTime and you want to use the transformed value to fill in the
+as a DateTime, and you want to use the transformed value to fill in the
 form, then you will also need a deflation or field class 'deflate' method
 to reformat the object into a form suitable for an HTML form field.
 See L<HTML::FormHandler::Manual::InflationDeflation> for more info.
@@ -178,7 +178,7 @@ L<HTML::FormHandler::Field::Text>
 
 =head3 Select
 
-A field formatted as a select elememnt.
+A field formatted as a select element.
 
 L<HTML::FormHandler::Field::Select>
 
@@ -275,7 +275,7 @@ this name, C<< $field->html_name >>.
 A compound field can be used for a database relation that will have only
 one row (belongs_to or has_one). If the relation has a compound primary
 key, you may need to provide the primary key columns, either through
-hidden fields or by setting them in the C<< $form->value >> has before
+hidden fields or by setting them in the C<< $form->value >> hash before
 'update_model' is called.
 
 See also L<HTML::FormHandler::Field::Compound>.
@@ -392,13 +392,13 @@ L<HTML::FormHandler::Field::Checkbox>
 
 =head3 Boolean
 
-Checkbox that return 1 or 0;
+Checkbox that return 1 or 0.
 
 L<HTML::FormHandler::Field::Boolean>
 
 =head2 Select Fields
 
-Field that inherit from 'Select'.
+Fields that inherit from 'Select'.
 
 =head3 Select
 
@@ -493,7 +493,7 @@ L<HTML::FormHandler::Field::Reset>
 
 =head3 Button
 
-Button field that rendered by the Button widget.
+Button field that is rendered by the Button widget.
 
 L<HTML::FormHandler::Field::Button>
 
@@ -506,23 +506,23 @@ L<HTML::FormHandler::Field::Display>
 
 =head2 TextArea fields
 
-Fields that inherit from textarea.
+Fields that inherit from 'TextArea'.
 
 =head3 TextArea
 
 L<HTML::FormHandler::Field::TextArea>
 
 =head3 HtmlArea
 
-A textarea that attempt to validate the textarea with html tidy.
+A textarea that attempt to validate the value with L<HTML::Tidy>.
 
 L<HTML::FormHandler::Field::HtmlArea>
 
 =head2 Password fields
 
 =head3 Password
 
-Password field. Sets 'noupdate' flage if empty and not required.
+Password field. Sets 'noupdate' flag if empty and not required.
 
 L<HTML::FormHandler::Field::Password>
 

lib/HTML/FormHandler/Manual/FromDFV.pod

@@ -18,7 +18,7 @@ checks as Data::FormValidator. It would be possible to implement many
 of them, but there hasn't been much demand for them. So far FormHandler
 users seem to be satisfed with the "do your own checks in a Perl method"
 solution. Because of the greater complexity of FormHandler's data model -
-with Repeatable arrays and nested compounds, etc, it's somewhat harder
+with Repeatable arrays and nested compounds, etc - it's somewhat harder
 to do some of them automatically.
 
 =head1 Differences/conversions

lib/HTML/FormHandler/Manual/FromFF.pod

@@ -14,7 +14,7 @@ FormFu.
 
 =head2 Inside/Outside
 
-FormFu forms look to me like "inside-out" object. The attributes and
+FormFu forms look to me like "inside-out" objects. The attributes and
 code are all set outside of the object. FormHandler forms are the
 opposite. Almost all attributes and settings are set *inside* the
 form class, although settings can be passed in on 'new' and 'process',

lib/HTML/FormHandler/Manual/InflationDeflation.pod

@@ -10,7 +10,7 @@ How to inflate and deflate field values.
 =head2 DESCRIPTION
 
 When working with the various ways that data can be transformed, in and out,
-the meaning of the terms 'inflate' and 'deflate' start to feel kind of slippery.
+the meaning of the terms 'inflate' and 'deflate' starts to feel kind of slippery.
 The one constant is that values presented in an HTML form must be in a string
 format, or presented with select elements or checkboxes.
 

lib/HTML/FormHandler/Manual/Intro.pod

@@ -40,7 +40,7 @@ must 'use' "HTML::FormHandler::Moose" and 'extend' FormHandler:
     extends 'HTML::FormHandler';
 
 Then you add some fields with 'has_field', and a field 'type' (the short
-name of the field package. (Fields with no type have type 'Text'.)
+name of the field package). (Fields with no type have type 'Text'.)
 
     has_field 'foo';
     has_field 'bar' => ( type => 'Select' );
@@ -130,7 +130,7 @@ If the validation succeeded, you may want to redirect:
 
 =head2 Rendering the form
 
-At it's simplest, all you need to do is C<< $form->render >> in a
+At its simplest, all you need to do is C<< $form->render >> in a
 template.
 
     [% form.render %]
@@ -140,7 +140,7 @@ anything with the right settings. Or you can render the form with a
 template.
 
 The form object will give you a hashref of values suitable for
-for filling in the form with C<< $form->fif >>.
+filling in the form with C<< $form->fif >>.
 
 By default FormHandler structures fields (and renders thems) in a way
 that matches the database. If you want to organize the rendering output
@@ -259,11 +259,11 @@ information.
 
 FormHandler's built-in errors are added to the form fields with
 C<< $field->add_error >>, and to the form with C<< $form->add_form_error >>.
-These methods call a C<< $self->_localize method >> which is a coderef set from
+These methods call a C<< $self->_localize >> method which is a coderef set from
 the field's default_localize sub, the field's 'localize_meth' attribute with
 C<< localize_meth => sub {} >>, or a form's sub localize_meth. The default localize
 uses Locale::Maketext.  You can also use duck_type classes for localization.
-See the documentation in L< HTML::FormHandler::TraitFor::I18N > and the tests in xt/locale.t.
+See the documentation in L<HTML::FormHandler::TraitFor::I18N> and the tests in xt/locale.t.
 
 If you wish to skip localization for a particular message (such as for system errors)
 you can use C<< $field->push_errors >> or C<< $form->push_form_errors >>.

lib/HTML/FormHandler/Manual/Reference.pod

@@ -51,7 +51,7 @@ L<HTML::FormHandler::Render::Simple>, and in the individual field classes.
 
 =head2 Form processing
 
-   process           Sets up form, validated, updates model
+   process           Sets up form, validates, updates model
    run               Returns a result object and clears form
    update_field_list Updates to fields on process
    posted            Flag to say whether or not to validate, instead of
@@ -77,7 +77,7 @@ L<HTML::FormHandler::Render::Simple>, and in the individual field classes.
 
 =head3 Form Methods and process hooks
 
-   update_model      To perform additional database actions update
+   update_model      To perform additional database actions on update
    update_fields     Sub providing convenient place to update fields on 'process'
    update_subfields  Sub providing place to update fields on Build (useful for
                        roles and compound field classes)
@@ -138,7 +138,7 @@ L<HTML::FormHandler::Render::Simple>, and in the individual field classes.
 
 =head2 Select fields
 
-   options       Sorted array of hashes, keys: "value", "label"
+   options       Sorted array of hashes; keys: "value", "label"
    options_method
    label_column  Column to use for labels (default: name)
    active_column Which values to list in options

lib/HTML/FormHandler/Manual/Rendering.pod

@@ -24,14 +24,14 @@ Another situation in which FormHandler rendering may be useful is when
 the form is complex enough that working in Perl is a better idea than
 putting lots of logic into templates.
 
-All of the rendering is designd to be easily replaced with elements of your
+All of the rendering is designed to be easily replaced with elements of your
 own, or to be replaced entirely. You can create your own rendering 'widgets'
 and load them into the fields by designating the directory in the
 'widget_name_space'. You could also create a completely separate renderer
 that's a separate object or class that takes a form object,
 or a role that is applied to your form.
 
-Note that Unless you set 'no_widgets' in the form, the rendering roles are
+Note that unless you set 'no_widgets' in the form, the rendering roles are
 automatically applied. You don't need to include anything else, unless you
 want to use a different renderer.
 
@@ -136,7 +136,7 @@ Default widget roles are found in the HTML::FormHandler::Widget directory.
 The name space used to look for the widget roles can be specified on a form or
 field basis by setting 'widget_name_space' to an arrayref of name spaces:
 
-   has '+widget_name_space' => ( default => sub { ['MyApp::Form::Widget' ]);
+   has '+widget_name_space' => ( default => sub { ['MyApp::Form::Widget' ] } );
 
 For the above widget ('MyWidget') and widget_name_space, you need to have a package named
 'MyApp::Form::Widget::Field::MyWidget'.
@@ -152,7 +152,7 @@ L<HTML::FormHandler::Render::Simple> as a basis. It used the method name
 instead of the 'render' method on the field.
 
 In addition to the 'Simple' wrapper, there is a 'Bootstrap' wrapper which
-creates html formatted to use the Twitter Bootstrap 2.0 CSS. There's also a sample
+creates HTML formatted to use the Twitter Bootstrap 2.0 CSS. There's also a sample
 "theme", L<HTML::FormHandler::Widget::Theme::Bootstrap>, which is a role that sets
 the widget_wrapper to 'Bootstrap', and provides Bootstrap-type formatting of the
 form error message.
@@ -165,7 +165,7 @@ You can make your own copy of an existing wrapper and add features to it.
 However, there are so many different ways to render the HTML around a field, that it's
 very difficult to handle more than a short list of standard presentations in
 one 'wrapper'. It may be better to make a number of more atomic widget wrappers and
-use those rather than complicate that already fairly complicated "Simple" and
+use those rather than complicate the already fairly complicated "Simple" and
 "Bootstrap" wrappers more.
 
 =head2 HTML attributes
@@ -178,7 +178,7 @@ label_class):
 
     has_field 'foo' => ( wrapper_class => ['form', 'special' ] );
 
-See the documentation in L<HTML::FormHandler::Field#Attributes_for_creating_HTML>.
+See the documentation on L<HTML::FormHandler::Field/Attributes_for_creating_HTML>.
 
 =head2 Form settings
 
@@ -601,7 +601,7 @@ Here's an example of a form rendering 'theme', taken from the t/bootstrap/basic.
     }}
 
 Note that the value 'all' key in the update_subfields hashref will be merged
-into the attributes used when building the all of the fields.
+into the attributes used when building all of the fields.
 
 =head2 Rendering fields
 
@@ -661,7 +661,7 @@ The base field class has a 'render_filter' attribute which is a coderef used to
 clean the values used to fill in the form for Render::Simple and the Widgets,
 and for some of the labels..
 The default filter changes quote, ampersand, <, and > to the equivalent html
-entities. If you wish to use some other sort of filtering, you can set use
+entities. If you wish to use some other sort of filtering, you can use the
 'render_filter' method in your form, or set a coderef on individual field
 objects. A 'render_filter' function in your form will be used by all fields.
 Setting it for a field will just be for that field.
@@ -675,7 +675,7 @@ Setting it for a field will just be for that field.
     has_field 'foo' => ( render_filter => sub { ... } );
 
 The filter is called in Render::Simple and in the widgets with
-C<< $self->html_filter( $fif ) or $field->html_filter( $fif ) >>.
+C<< $self->html_filter( $fif ) >> or C<< $field->html_filter( $fif ) >>.
 
 If you want to turn off the filter for a particular field, you can set it
 to a sub that just returns the value:
@@ -706,7 +706,7 @@ L<HTML::FormHandler::Field::Display>
 
 You can supply an HTML string to this field, to be displayed directly. There is no
 'value' associated with this field; it's a field for rendering only. The HTML
-string can be build with a form or field method.
+string can be built with a form or field method.
 
 Blocks or tags will often be a better solution.