[Zope-CVS] CVS: Packages/JobBoardEx - Tutorial.html:1.9

[Ken Manheimer]

Update of /cvs-repository/Packages/JobBoardEx
In directory cvs.zope.org:/tmp/cvs-serv26918

Modified Files:
	Tutorial.html 
Log Message:
Various small typo and grammar tweaks.

Also, it may be that the following text may be incorrect, due to the
institution of name-based security.  If so, it should not be removed
without either changing the related code or proving an alternate
explanation for using methods to wrap the attributes.  -

> <p><i>Note: the methods that wrap the attributes are necessary to
> allow access control for those attributes, until this issue is fixed
> in Zope3.</i>



=== Packages/JobBoardEx/Tutorial.html 1.8 => 1.9 ===
 interface are Zope attributes, defined by the Attribute() function in
 Zope's Interface module.  Attribute() is a way to define attributes in
-an interface. After all the attributes, there is a method, approve(),
+an interface.  Following all the attributes is a method, approve(),
 which is used to take the job from the PendingApproval to the Approved
 state. These states are defined in the class JobState.
 
@@ -134,12 +134,12 @@
 to report an error if it is used incorrectly.
 
 <p>An instance of a view class is only ever associated with a single
-object to be viewed. In this case, it's a Job object so the __init__()
+object to be viewed. In this case, it's a Job object, so the __init__()
 stores the associated Job object and getContext() produces
 it. (getContext() is called when ...).
 
 <p>Although the <b>index</b> assignment initially appears to be
-creating a simple attribute to the JobView class, it's actually
+creating a simple attribute in the JobView class, it's actually
 creating a method. The PageTemplateFile() function takes a Zope Page
 Template description and compiles it to produce a callable (in this
 situation) object which thus behaves as a method. So you can treat
@@ -159,9 +159,11 @@
 
 <h3>Editing a Job with JobEditView</h3>
 
-<p>The JobEditView class in association with the JobEditView.pt and
-JobPreviewView.pt page templates define the process of editing a
-Job. This starts on the page produced by JobEditView.pt. If you look
+<p>The JobEditView class, in association with the JobEditView.pt and
+JobPreviewView.pt page templates, defines the process of editing a
+Job. This starts on the page produced by JobEditView.pt.
+
+<p>If you look
 at this code, you'll see relatively normal HTML with some extra "tal"
 information buried in the tag fields. Leaving that aside for the time
 being, we're primarily interested in the form's "action" and the
@@ -169,7 +171,9 @@
 (to the browser) "back to the object that created the page." In this case,
 that means the JobEditView object. When you combine this fact with the
 "submit" inputs, for "Preview" and "Cancel," we produce the desired
-results. The name for the preview button is "preview:method". This
+results.
+
+<p>The name for the preview button is "preview:method". This
 tells Zope that when that button is pressed it should call a method
 named "preview," and since "action" is "", that indicates that Zope
 should call the preview method on the page's current object, a
@@ -193,7 +197,7 @@
 application), and the goal is to just tell Zope how to do the
 controlling for you. But it's inevitable that you must put <i>some</i>
 control code in your system, and it turns out that control code is
-typically highly coupled with view code, and so it's cleaner to
+typically highly coupled with view code - so it's cleaner to
 include the control code, such as the cancel() and submit() methods,
 in the view class. Thus we end up with more of a view/controller. The
 trick is not to give into the temptation to put all your logic in the