[Catalyst-commits] r8433 - trunk/Catalyst-Authentication-Store-DBIx-Class/lib/Catalyst/Authentication/Store/DBIx

[jester at dev.catalyst.perl.org]

Author: jester
Date: 2008-09-18 14:11:29 +0100 (Thu, 18 Sep 2008)
New Revision: 8433

Modified:
   trunk/Catalyst-Authentication-Store-DBIx-Class/lib/Catalyst/Authentication/Store/DBIx/Class.pm
Log:
very minor punctuation fixes

Modified: trunk/Catalyst-Authentication-Store-DBIx-Class/lib/Catalyst/Authentication/Store/DBIx/Class.pm
===================================================================
--- trunk/Catalyst-Authentication-Store-DBIx-Class/lib/Catalyst/Authentication/Store/DBIx/Class.pm	2008-09-17 21:03:04 UTC (rev 8432)
+++ trunk/Catalyst-Authentication-Store-DBIx-Class/lib/Catalyst/Authentication/Store/DBIx/Class.pm	2008-09-18 13:11:29 UTC (rev 8433)
@@ -36,7 +36,7 @@
 }
 
 ## --jk note to self:
-## let's use DBICs get_columns method to return a hash and save / restore that
+## let's use DBIC's get_columns method to return a hash and save / restore that
 ## from the session.  Then we can respond to get() calls, etc. in most cases without
 ## resorting to a DB call.  If user_object is called, THEN we can hit the DB and
 ## return a real object.  
@@ -177,7 +177,7 @@
 
 =item class
 
-Class is part of the core Catalyst::Plugin::Authentication module, it
+Class is part of the core Catalyst::Plugin::Authentication module; it
 contains the class name of the store to be used.
 
 =item user_class
@@ -191,13 +191,13 @@
 information, this item tells the module which field contains your role
 information.  The DBIx::Class authentication store expects the data in this
 field to be a series of role names separated by some combination of spaces, 
-commas or pipe characters.  
+commas, or pipe characters.  
 
 =item role_relation
 
 If your role information is stored in a separate table, this is the name of
 the relation that will lead to the roles the user is in.  If this is 
-specified then a role_field is also required.  Also when using this method
+specified, then a role_field is also required.  Also when using this method
 it is expected that your role table will return one row for each role 
 the user is in.
 
@@ -246,7 +246,7 @@
 
 In most cases, this config variable does not need to be set, as
 Catalyst::Authentication::Store::DBIx::Class will determine the primary
-key of the user table on it's own.  If you need to override the default, 
+key of the user table on its own.  If you need to override the default, 
 or your user table has multiple primary keys, then id_field
 should contain the column name that should be used to restore the user.
 A given value in this column should correspond to a single user in the database.
@@ -286,7 +286,7 @@
 The above example would attempt to retrieve a user whose username column (here, 
 screen_name) matched the username provided, and whose status column matched one of the
 values provided. These name => value pairs are used more or less directly in
-the DBIx::Class' search() routine, so in most cases, you can use DBIx::Class
+the DBIx::Class search() routine, so in most cases, you can use DBIx::Class
 syntax to retrieve the user according to whatever rules you have.
 
 NOTE: Because the password in most cases is encrypted - it is not used
@@ -296,7 +296,7 @@
 storage module. See L<Catalyst::Authentication::Credential::Password>.
 
 One thing you need to know about this retrieval method is that the name
-portion of the pair is checked against the user class' column list. Pairs are
+portion of the pair is checked against the user class's column list. Pairs are
 only used if a matching column is found. Other pairs will be ignored. This
 means that you can only provide simple name-value pairs, and that some more
 advanced DBIx::Class constructs, such as '-or', '-and', etc. are in most cases
@@ -356,7 +356,7 @@
     }
 
 The above would allow authentication based on any of the three items -
-username, email or clientid and would prefetch the data related to that user
+username, email, or clientid - and would prefetch the data related to that user
 from the preferences table. The searchargs array is passed directly to the
 search() method associated with the user_class.
 
@@ -371,7 +371,7 @@
        
     if ($c->authenticate({ 
                            password => $password,
-                           'dbix_class' => {  resultset => $rs }
+                           'dbix_class' => { resultset => $rs }
                          })) {
        # do successful authentication actions here.
     } 
@@ -403,7 +403,7 @@
 =head1 METHODS
 
 There are no publicly exported routines in the DBIx::Class authentication 
-store (or indeed in most authentication stores)  However, below is a 
+store (or indeed in most authentication stores). However, below is a 
 description of the routines required by L<Catalyst::Plugin::Authentication> 
 for all authentication stores.  Please see the documentation for 
 L<Catalyst::Plugin::Authentication::Internals> for more information.
@@ -416,14 +416,14 @@
 =head2 find_user ( $authinfo, $c ) 
 
 Finds a user using the information provided in the $authinfo hashref and
-returns the user, or undef on failure; This is usually called from the
+returns the user, or undef on failure. This is usually called from the
 Credential. This translates directly to a call to
 L<Catalyst::Authentication::Store::DBIx::Class::User>'s load() method.
 
 =head2 for_session ( $c, $user )
 
 Prepares a user to be stored in the session. Currently returns the value of
-the user's id field - (as indicated by the 'id_field' config element)
+the user's id field (as indicated by the 'id_field' config element)
 
 =head2 from_session ( $c, $frozenuser)
 
@@ -442,18 +442,18 @@
 =head2 auto_create_user( $authinfo, $c )
 
 This method is called if the realm's auto_create_user setting is true. It
-will delegate to the user class' (resultset) C<auto_create> method.
+will delegate to the user class's (resultset) C<auto_create> method.
 
 =head1 NOTES
 
 As of the current release, session storage consists of simply storing the user's
-id in the session, and then using that same id to re-retrieve the users information
+id in the session, and then using that same id to re-retrieve the user's information
 from the database upon restoration from the session.  More dynamic storage of
 user information in the session is intended for a future release.
 
 =head1 BUGS AND LIMITATIONS
 
-None known currently, please email the author if you find any.
+None known currently; please email the author if you find any.
 
 =head1 SEE ALSO