[Jifty-commit] r2310 - jifty/trunk/lib/Jifty/Manual

[jifty-commit at lists.jifty.org]

Author: agentz
Date: Sun Dec  3 21:35:17 2006
New Revision: 2310

Modified:
   jifty/trunk/lib/Jifty/Manual/PageRegions.pm

Log:
[Jifty::Manual::PageRegions]
- typo fixes.

Modified: jifty/trunk/lib/Jifty/Manual/PageRegions.pm
==============================================================================
--- jifty/trunk/lib/Jifty/Manual/PageRegions.pm	(original)
+++ jifty/trunk/lib/Jifty/Manual/PageRegions.pm	Sun Dec  3 21:35:17 2006
@@ -8,7 +8,7 @@
 Page regions are a way of doing the new trend of automatic in-page
 replacement with JavaScript -- while at the same time providing the
 same user experience for non-JavaScript enabled browsers.  Sections
-are chunked into nestable "page regions," which can be refreshed
+are chunked into nestable "page regions", which can be refreshed
 independently.
 
 =head1 USING PAGE REGIONS
@@ -31,22 +31,22 @@
 =item name
 
 The mandatory region's name given here is used to embed the region's
-content into a C<< <div> >> Tag which is marked with a fully qualified
+content into a C<< <div> >> tag which is marked with a fully qualified
 name for that region. The qualified name represents the nesting
-structure of regions inside a page and is automatically build inside.
+structure of regions inside a page and is automatically built inside.
 
 =item path (optional)
 
 If a path is given, the component's rendered result under this path is
 embedded inside the region. If no path is given, C</__jifty/empty>
-will be used resulting in an empty region's inside.
+will be used resulting in an empty region inside.
 
 =item defaults (optional)
 
 Every argument given here (as a hash-ref) will be transported to the
-component that displays the region's inside. The values are accessable
-by building a C<< <%args> >> block in the component specifying the
-arguments.
+component that displays the region inside. The values are accessible
+by building a C<< <%args> >> block in the component (Mason template)
+specifying the arguments.
 
 =back
 
@@ -66,7 +66,7 @@
                        ) %>
 
     %# insert a new region in front of a given region
-    %# use a HTML-entity as the link-text and a CSS class
+    %# use an HTML-entity as the link-text and a CSS class
     <% Jifty->web->link( label        => '%#9997;',
                          escape_label => 0,
                          class        => 'blue_button',
@@ -86,7 +86,7 @@
                                     },
                        ) %>
 
-    %# a Button to replace the current region with empty content
+    %# a button to replace the current region with empty content
     <% Jifty->web->link( label   => 'clear',
                          onclick => {
                              refresh_self => 1,
@@ -95,7 +95,7 @@
                          as_button => 1,
                        ) %>
 
-    %# a Button to delete some region with JavaScript confirmation alert
+    %# a button to delete some region with JavaScript confirmation alert
     <% Jifty->web->link( label   => 'delete',
                          onclick => {
                              delete  => 'regionname',
@@ -114,18 +114,18 @@
 Regions, when they are created, have a default path and a default set
 of arguments.  These are "defaults" because they can be overridden by
 the browser -- this is what enables the browser to say "and that
-region has this other path, in reality."  The same is true of
+region has this other path, in reality."  The same is true for
 arguments; for example, a paging widget could have a default C<page>
 argument of 1, but could be actually being rendered with a C<page> of
 2.
 
 These overrides are kept track of using state variables.  When a
-region is entered, it peers at the currenst state variables, and
+region is entered, it peers at the current state variables, and
 overrides the default path and arguments before rendering the region.
 
 When a L<Jifty::Web::Form::Clickable> with an C<onclick> is
 L<generated|Jifty::Web::Form::Clickable/generate>, it examines the
-onclick and determines how to emulate it without JavaScript.  It
+C<onclick> and determines how to emulate it without JavaScript.  It
 determines which actions need to be run, as well as how to manipulate
 the future state variables to change the display of the appropriate
 regions.  It encodes all of this in the button or link; since the
@@ -136,7 +136,7 @@
 which serves two purposes: to inform the JavaScript of the existance
 of the page region and its default path and variables, and to create a
 unique C<< <div> >> for the fragment to reside in.  The browser reads
-the JavaScript and creates, client-side, a model of the nested
+the JavaScript and creates, on client-side, a model of the nested
 PageRegions.  This allows the JavaScript to model the state variable
 changes correctly.
 
@@ -145,13 +145,13 @@
 need to be run.  As it does so, it builds up an up-to-date list of
 state variables, to more closely imitate the state of a non-javascript
 enabled client.  It constructs a JSON request based on that
-information, and passes it off to the XML webservice endpoint on the
+information, and passes it off to the XML web-service endpoint on the
 server.
 
 When the request comes back, it parses the XML.  For each fragment
 that was requested, it finds the correct bit of the response, and
 replaces the content of the DOM with the response.  As it does so, it
-re-updates the clientside view of the fragments with the server's
+re-updates the client-side view of the fragments with the server's
 information -- this is particularly key for dealing with parameters
 which were mapped by the request mapper.  Finally, it displays
 any messages and errors from actions.