proof read documentation stable
authorAlexandre Fayolle <alexandre.fayolle@logilab.fr>
Sat, 29 May 2010 10:33:57 +0200
branchstable
changeset 5608 f9ab62103ad4
parent 5607 38d43dc5ee57
child 5609 d247e2e06db2
proof read documentation some clarifications, some typo fixes, and a couple of other strings fixed on the way
cwctl.py
cwvreg.py
devtools/devctl.py
doc/book/en/devrepo/cubes/available-cubes.rst
doc/book/en/devrepo/cubes/cc-newcube.rst
doc/book/en/devrepo/cubes/layout.rst
doc/book/en/devrepo/vreg.rst
doc/book/en/intro/concepts.rst
doc/book/en/tutorials/advanced/index.rst
selectors.py
--- a/cwctl.py	Sat May 29 10:33:40 2010 +0200
+++ b/cwctl.py	Sat May 29 10:33:57 2010 +0200
@@ -201,7 +201,7 @@
     def run(self, args):
         """run the command with its specific arguments"""
         if args:
-            raise BadCommandUsage('Too much arguments')
+            raise BadCommandUsage('Too many arguments')
         from cubicweb.migration import ConfigurationProblem
         print 'CubicWeb %s (%s mode)' % (cwcfg.cubicweb_version(), cwcfg.mode)
         print
--- a/cwvreg.py	Sat May 29 10:33:40 2010 +0200
+++ b/cwvreg.py	Sat May 29 10:33:57 2010 +0200
@@ -20,7 +20,7 @@
 The `VRegistry`
 ---------------
 
-The `VRegistry` can be seen as a two levels dictionary. It contains
+The `VRegistry` can be seen as a two-level dictionary. It contains
 all dynamically loaded objects (subclasses of :ref:`appobject`) to
 build a |cubicweb| application. Basically:
 
@@ -49,12 +49,12 @@
 .. index::
    vregistry: registration_callback
 
-On startup |cubicweb| loads application objects defined in its library
+On startup, |cubicweb| loads application objects defined in its library
 and in cubes used by the instance. Application objects from the
 library are loaded first, then those provided by cubes are loaded in
 dependency order (e.g. if your cube depends on an other, objects from
-the dependency will be loaded first). Cube's modules or packages where
-appobject are looked for is explained in :ref:`cubelayout`.
+the dependency will be loaded first). The layout of the modules or packages
+in a cube  is explained in :ref:`cubelayout`.
 
 For each module:
 
@@ -144,20 +144,22 @@
 
   - else, the higher the score, the better the object suits the context
 
-* the object with the higher score is selected.
+* the object with the highest score is selected.
 
 .. Note::
 
-  When no score is higher than the others, an exception is raised in development
+  When no single object has the highest score, an exception is raised in development
   mode to let you know that the engine was not able to identify the view to
   apply. This error is silenced in production mode and one of the objects with
-  the higher score is picked.
+  the highest score is picked.
 
-  In such cases you would need to review your design and make sure your selectors
-  or appobjects are properly defined.
+  In such cases you would need to review your design and make sure
+  your selectors or appobjects are properly defined. Such an error is
+  typically caused by either forgetting to change the __regid__ in a
+  derived class, or by having copy-pasted some code.
 
-For instance, if you are selecting the primary (eg `__regid__ =
-'primary'`) view (eg `__registry__ = 'views'`) for a result set
+For instance, if you are selecting the primary (`__regid__ =
+'primary'`) view (`__registry__ = 'views'`) for a result set
 containing a `Card` entity, two objects will probably be selectable:
 
 * the default primary view (`__select__ = implements('Any')`), meaning
@@ -167,9 +169,8 @@
   meaning that the object is selectable for Card entities
 
 Other primary views specific to other entity types won't be selectable in this
-case. Among selectable objects, the implements selector will return a higher
-score than the second view since it's more specific, so it will be selected as
-expected.
+case. Among selectable objects, the `implements('Card')` selector will return a higher
+score since it's more specific, so the correct view will be selected as expected.
 
 .. _SelectionAPI:
 
@@ -179,7 +180,7 @@
 Here is the selection API you'll get on every registry. Some of them, as the
 'etypes' registry, containing entity classes, extend it. In those methods,
 `*args, **kwargs` is what we call the **context**. Those arguments are given to
-selectors that will inspect there content and return a score accordingly.
+selectors that will inspect their content and return a score accordingly.
 
 .. automethod:: cubicweb.vregistry.Registry.select
 
--- a/devtools/devctl.py	Sat May 29 10:33:40 2010 +0200
+++ b/devtools/devctl.py	Sat May 29 10:33:57 2010 +0200
@@ -274,7 +274,7 @@
     def run(self, args):
         """run the command with its specific arguments"""
         if args:
-            raise BadCommandUsage('Too much arguments')
+            raise BadCommandUsage('Too many arguments')
         import shutil
         import tempfile
         import yams
--- a/doc/book/en/devrepo/cubes/available-cubes.rst	Sat May 29 10:33:40 2010 +0200
+++ b/doc/book/en/devrepo/cubes/available-cubes.rst	Sat May 29 10:33:57 2010 +0200
@@ -2,8 +2,8 @@
 Available cubes
 ---------------
 
-An instance is based on several basic cubes. In the set of available
-basic cubes we can find for example :
+An instance is made of several basic cubes. In the set of available
+basic cubes we can find for example:
 
 Base entity types
 ~~~~~~~~~~~~~~~~~
@@ -22,14 +22,14 @@
 
 Classification
 ~~~~~~~~~~~~~~
-* folder_: Folder (to organize things but grouping them in folders)
+* folder_: Folder (to organize things by grouping them in folders)
 * keyword_: Keyword (to define classification schemes)
 * tag_: Tag (to tag anything)
 
 Other features
 ~~~~~~~~~~~~~~
 * basket_: Basket (like a shopping cart)
-* blog_: a blogging system uxing Blog and BlogEntry entity types
+* blog_: a blogging system using Blog and BlogEntry entity types
 * comment_: system to attach comment threads to entities)
 * email_: archiving management for emails (`Email`, `Emailpart`,
   `Emailthread`), trigger action in cubicweb through email
@@ -55,8 +55,9 @@
 .. _task: http://www.cubicweb.org/project/cubicweb-task
 .. _zone: http://www.cubicweb.org/project/cubicweb-zone
 
-To declare the use of a component, once installed, add the name of the component
-to the variable `__use__` in the file `__pkginfo__.py` of your own component.
+To declare the use of a cube, once installed, add the name of the cube
+and its dependency relation in the `__depends_cubes__` dictionary
+defined in the file `__pkginfo__.py` of your own component.
 
 .. note::
   The listed cubes above are available as debian-packages on `CubicWeb's forge`_.
--- a/doc/book/en/devrepo/cubes/cc-newcube.rst	Sat May 29 10:33:40 2010 +0200
+++ b/doc/book/en/devrepo/cubes/cc-newcube.rst	Sat May 29 10:33:57 2010 +0200
@@ -14,15 +14,15 @@
   hg ci
 
 If all went well, you should see the cube you just created in the list
-returned by ``cubicweb-ctl list`` in the section *Available cubes*,
-and if it is not the case please refer to :ref:`ConfigurationEnv`.
+returned by ``cubicweb-ctl list`` in the  *Available cubes* section. 
+If not, please refer to :ref:`ConfigurationEnv`.
 
 To reuse an existing cube, add it to the list named
-``__depends_cubes__`` and defined in :file:`__pkginfo__.py`.  This
-variable is used for the instance packaging (dependencies handled by
-system utility tools such as APT) and the usable cubes at the time the
-base is created (import_erschema('MyCube') will not properly work
-otherwise).
+``__depends_cubes__`` which is defined in :file:`__pkginfo__.py`.
+This variable is used for the instance packaging (dependencies handled
+by system utility tools such as APT) and to find used cubes when the
+database for the instance is created (import_erschema('MyCube') will
+not properly work otherwise).
 
 .. note::
 
--- a/doc/book/en/devrepo/cubes/layout.rst	Sat May 29 10:33:40 2010 +0200
+++ b/doc/book/en/devrepo/cubes/layout.rst	Sat May 29 10:33:57 2010 +0200
@@ -70,6 +70,7 @@
   |-- entities.py
   |-- hooks.py
   `-- views/
+      |-- __init__.py
       |-- forms.py
       |-- primary.py
       `-- widgets.py
@@ -78,14 +79,14 @@
 where :
 
 * ``schema`` contains the schema definition (server side only)
-* ``entities`` contains the entities definition (server side and web interface)
+* ``entities`` contains the entity definitions (server side and web interface)
 * ``hooks`` contains hooks and/or views notifications (server side only)
 * ``views`` contains the web interface components (web interface only)
 * ``test`` contains tests related to the cube (not installed)
 * ``i18n`` contains message catalogs for supported languages (server side and
   web interface)
-* ``data`` contains data files for static content (images, css, javascripts)
-  ...(web interface only)
+* ``data`` contains data files for static content (images, css,
+  javascript code)...(web interface only)
 * ``migration`` contains initialization files for new instances (``postcreate.py``)
   and a file containing dependencies of the component depending on the version
   (``depends.map``)
@@ -102,10 +103,12 @@
 The :file:`__init__.py` and :file:`site_cubicweb.py` files
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+.. XXX WRITEME
+
 The :file:`__pkginfo__.py` file
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-It contains metadata describing your cubes, mostly useful for
+It contains metadata describing your cube, mostly useful for
 packaging.
 
 
--- a/doc/book/en/devrepo/vreg.rst	Sat May 29 10:33:40 2010 +0200
+++ b/doc/book/en/devrepo/vreg.rst	Sat May 29 10:33:57 2010 +0200
@@ -1,8 +1,8 @@
 The VRegistry, selectors and application objects
 ================================================
 
-This chapter talks about core concepts of the |cubicweb| framework,
-that make it different from other frameworks (and maybe not easy to
+This chapter deals with some of the  core concepts of the |cubicweb| framework
+which make it different from other frameworks (and maybe not easy to
 grasp at a first glance). To be able to do advanced development with
 |cubicweb| you need a good understanding of what is explained below.
 
--- a/doc/book/en/intro/concepts.rst	Sat May 29 10:33:40 2010 +0200
+++ b/doc/book/en/intro/concepts.rst	Sat May 29 10:33:57 2010 +0200
@@ -173,15 +173,15 @@
 achieved by dynamic objects (`application objects` or `appobjects`) stored in a
 two-levels registry (the `vregistry`). Each object is affected to a registry with
 an identifier in this registry. You may have more than one object sharing an
-identifier in the same registry, At runtime, appobjects are selected in a
-registry according to the context. Selection is done by comparing *score*
+identifier in the same registry. At runtime, appobjects are selected in a
+registry according to the context. Selection is done by comparing the *score*
 returned by each appobject's *selector*.
 
 Application objects are stored in the vregistry using a two-level hierarchy :
 
   object's `__registry__` : object's `__regid__` : [list of app objects]
 
-E.g. the `vregistry` contains several (sub-)registries which hold a
+In other words, the `vregistry` contains several (sub-)registries which hold a
 list of appobjects associated to an identifier.
 
 The base class of appobjects is :class:`cubicweb.appobject.AppObject`.
@@ -189,15 +189,15 @@
 Selectors
 ~~~~~~~~~
 
-Each appobject has a selector, that is used to compute how well the object fits a
-given context. The better the object fits the context, the higher the score. They
-are the glue that tie appobjects to the data model. Using them appropriately is
+Each appobject has a selector that is used to compute how well the object fits a
+given context. The better the object fits the context, the higher the score. Scores
+are the glue that ties appobjects to the data model. Using them appropriately is
 an essential part of the construction of well behaved cubes.
 
 |cubicweb| provides a set of basic selectors that may be parametrized.  Also,
 selectors can be combined with the `~` unary operator (negation) and the binary
 operators `&` and `|` (respectivly 'and' and 'or') to build more complex
-selector. Of course complex selector may be combined too. Last but not least, you
+selectors. Of course complex selectors may be combined too. Last but not least, you
 can write your own selectors.
 
 The `vregistry`
@@ -339,5 +339,5 @@
 cubicweb application.
 
 .. note::
-   RQL queries executed in hooks and operations are *unsafe* by default, e.g. the
+   RQL queries executed in hooks and operations are *unsafe* by default, i.e. the
    read and write security is deactivated unless explicitly asked.
--- a/doc/book/en/tutorials/advanced/index.rst	Sat May 29 10:33:40 2010 +0200
+++ b/doc/book/en/tutorials/advanced/index.rst	Sat May 29 10:33:57 2010 +0200
@@ -8,12 +8,12 @@
 
 * basically a photo gallery
 
-* photo stored onto the fs and displayed dynamically through a web interface
+* photo stored on the file system and displayed dynamically through a web interface
 
 * navigation through folder (album), tags, geographical zone, people on the
   picture... using facets
 
-* advanced security (eg not everyone can see everything). More on this later.
+* advanced security (not everyone can see everything). More on this later.
 
 
 Cube creation and schema definition
@@ -24,7 +24,7 @@
 Step 1: creating a new cube for my web site
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-One note about my development environment: I wanted to use packaged
+One note about my development environment: I wanted to use the packaged
 version of CubicWeb and cubes while keeping my cube in my user
 directory, let's say `~src/cubes`.  I achieve this by setting the
 following environment variables::
@@ -43,10 +43,10 @@
 Step 2: pick building blocks into existing cubes
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Almost everything I want represent in my web-site is somewhat already modelized in
-some cube that I'll extend for my need. So I'll pick the following cubes:
+Almost everything I want to handle in my web-site is somehow already modelized in
+existing cubes that I'll extend for my need. So I'll pick the following cubes:
 
-* `folder`, containing `Folder` entity type, which will be used as
+* `folder`, containing the `Folder` entity type, which will be used as
   both 'album' and a way to map file system folders. Entities are
   added to a given folder using the `filed_under` relation.
 
@@ -62,7 +62,7 @@
 * `comment`, providing a full commenting system allowing one to comment entity types
   supporting the `comments` relation by adding a `Comment` entity.
 
-* `tag`, providing a full tagging system as a easy and powerful way to classify
+* `tag`, providing a full tagging system as an easy and powerful way to classify
   entities supporting the `tags` relation by linking the to `Tag` entities. This
   will allows navigation into a large number of picture.
 
@@ -131,20 +131,20 @@
   picture.
 
 This schema will probably have to evolve as time goes (for security handling at
-least), but since the possibility to make schema evolving is one of CubicWeb
-feature (and goal), we won't worry and see that later when needed.
+least), but since the possibility to let a schema evolve is one of CubicWeb's
+features (and goals), we won't worry about it for now and see that later when needed.
 
 
 Step 4: creating the instance
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Now that I've a schema, I want to create an instance so I can start To
-create an instance using this new 'sytweb' cube, I run::
+Now that I have a schema, I want to create an instance. To
+do so using this new 'sytweb' cube, I run::
 
   cubicweb-ctl create sytweb sytweb_instance
 
-hint : if you get an error while the database is initialized, you can
-avoid having to reanswer to questions by runing ::
+Hint: if you get an error while the database is initialized, you can
+avoid having to answer the questions again by running::
 
    cubicweb-ctl db-create sytweb_instance
 
@@ -161,7 +161,7 @@
 Security, testing and migration
 -------------------------------
 
-This post will cover various topics:
+This part will cover various topics:
 
 * configuring security
 * migrating existing instance
@@ -174,10 +174,10 @@
   - ``authenticated``, only authenticated users can see it
   - ``restricted``, only a subset of authenticated users can see it
 * managers (e.g. me) can see everything
-* only authenticated user can see people
-* everyone can  see classifier entities, eg tag and zone
+* only authenticated users can see people
+* everyone can see classifier entities, such as tag and zone
 
-Also, unless explicity specified, visibility of an image should be the same as
+Also, unless explicitly specified, the visibility of an image should be the same as
 its parent folder, as well as visibility of a comment should be the same as the
 commented entity. If there is no parent entity, the default visibility is
 ``authenticated``.
@@ -198,19 +198,19 @@
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In schema, you can grant access according to groups, or to some RQL expressions:
-users get access it the expression return some results. To implements the read
-security defined earlier, groups are not enough, we'll need RQL expression. Here
+users get access if the expression returns some results. To implement the read
+security defined earlier, groups are not enough, we'll need some RQL expression. Here
 is the idea:
 
-* add a `visibility` attribute on folder, image and comment, which may be one of
+* add a `visibility` attribute on Folder, Image and Comment, which may be one of
   the value explained above
 
-* add a `may_be_read_by` relation from folder, image and comment to users,
+* add a `may_be_read_by` relation from Folder, Image and Comment to users,
   which will define who can see the entity
 
 * security propagation will be done in hook.
 
-So the first thing to do is to modify my cube'schema.py to define those
+So the first thing to do is to modify my cube's schema.py to define those
 relations:
 
 .. sourcecode:: python
@@ -319,9 +319,9 @@
 system. Hooks are triggered on database event such as addition of new
 entity or relation.
 
-The trick part of the requirement is in *unless explicitly specified*, notably
-because when the entity addition hook is added, we don't know yet its 'parent'
-entity (eg folder of an image, image commented by a comment). To handle such things,
+The tricky part of the requirement is in *unless explicitly specified*, notably
+because when the entity is added, we don't know yet its 'parent'
+entity (e.g. Folder of an Image, Image commented by a Comment). To handle such things,
 CubicWeb provides `Operation`, which allow to schedule things to do at commit time.
 
 In our case we will:
@@ -554,7 +554,7 @@
 Step 4: writing the migration script and migrating the instance
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Prior to those changes, Iv'e created an instance, feeded it with some data, so I
+Prior to those changes, I  created an instance, feeded it with some data, so I
 don't want to create a new one, but to migrate the existing one. Let's see how to
 do that.
 
@@ -576,7 +576,7 @@
 * update the instance's schema by adding our two new relations and update the
   underlying database tables accordingly (the two first instructions)
 
-* update schema's permissions definition (the later instruction)
+* update schema's permissions definition (the last instruction)
 
 
 To migrate my instance I simply type::
--- a/selectors.py	Sat May 29 10:33:40 2010 +0200
+++ b/selectors.py	Sat May 29 10:33:57 2010 +0200
@@ -111,7 +111,7 @@
 
     class UserLink(component.Component):
 	'''if the user is the anonymous user, build a link to login else a link
-	to the connected user object with a loggout link
+	to the connected user object with a logout link
 	'''
 	__regid__ = 'loggeduserlink'