Spelling and grammar fixes

Author: boxed

docs/test_doc_abstraction_levels.py

@@ -56,7 +56,7 @@ def index(request):
 
     # language=rst
     """
-    The iommi middleware will handle if you return an iommi type and render it properly.
+    The iommi middleware will detect when you return an iommi type and render it properly.
     
     At this point you might think "Hold on! Where is the template?". There isn't one. We don't need a template. iommi works at a higher level of abstraction. Don't worry, you can drop down to templates if you need to though. This will be covered later.
     

docs/test_doc_access_control.py

@@ -4,11 +4,11 @@
 Access control
 ~~~~~~~~~~~~~~
 
-The iommi admin only allows access to users with the `is_staff` flag. Other than that iommi doesn't enforce any access control on its own. If you need any you have to implement it yourself for your specific use case. That being said here are a few ideas:
+The iommi admin only allows access to users with the `is_staff` flag. Other than that iommi doesn't enforce any access control on its own. If you need any you have to implement it yourself for your specific use case. That being said, here are a few ideas:
 
 - Middleware that checks URL of requests coming in, limiting certain paths (or all paths) to logged in users, users belonging to certain groups, etc. This is the easiest to get right as it's in one place and is easy to reason about. It can't handle many common cases, but it can be a good base to stand on.
 - Path decoders in iommi can be used for access control if the object being decoded has access semantics. For example `/company/1/` could validate that the user is a member of the company with pk 1.
-- You can generalize path decoder logic to call an `has_access` method on the model you decode.
+- You can generalize path decoder logic to call a `has_access` method on the model you decode.
 - The `LoginRequiredMiddleware <https://docs.djangoproject.com/en/5.1/ref/middleware/#django.contrib.auth.middleware.LoginRequiredMiddleware>`_ can be used to default URLs to denied, where you have to mark allowed URLs with the `@login_not_required` decorator.
 
 """

docs/test_doc_admin.py

@@ -101,7 +101,7 @@ class MyAdmin(Admin):
 
     # language=rst
     """
-    Now you have the iommi admin gui for your app!
+    Now you have the iommi admin GUI for your app!
     """
 
 
@@ -130,9 +130,9 @@ class Meta:
 
     # language=rst
     """
-    This is especially useful for adding config to a third party app that doesn't have built in iommi admin configuration.
+    This is especially useful for adding config to a third party app that doesn't have built-in iommi admin configuration.
 
-    You can also add the config in the app, by creating a `iommi_admin.py` file in your app, and putting the configuration there:
+    You can also add the config in the app, by creating an `iommi_admin.py` file in your app, and putting the configuration there:
 
 
     """

docs/test_doc_after.py

@@ -5,7 +5,7 @@
 `after`
 -------
 
-Ordering of fields and columns is based on the declared order, the order in the model (when using :ref:`auto`), and the `after` configuration. The last takes precedent over the others.
+Ordering of fields and columns is based on the declared order, the order in the model (when using :ref:`auto`), and the `after` configuration. The last takes precedence over the others.
 
 To order fields, set `after` to:
 

docs/test_doc_architecture.py

@@ -59,7 +59,7 @@ def test_refine_done():
     you call `bind()` on an object that hasn't had `refine_done()` called yet),
     or you can do it explicitly yourself.
 
-    The refine done step does a lot of of the work that is needed for the final
+    The refine done step does a lot of the work that is needed for the final
     traversal step, so if possible you want to make sure this is done before.
     If this step is done on an object that is then kept around, all this work
     doesn't need to be redone. Examples of work that is done in this step include
@@ -128,7 +128,7 @@ def test_bind():
     1. Copy of the part. (We set a member `_declared` to point to the original definition if you need to refer to it for debugging purposes.)
     2. Set the `parent` and set `_is_bound` to `True`
     3. Style application
-    4. Call the parts `on_bind` method
+    4. Call the part's `on_bind` method
 
     The parts are responsible for calling `bind(parent=self)` on all their children in `on_bind`.
 
@@ -203,7 +203,7 @@ def another_function(y=None, z=None):
     # language=rst
     """
     This is really useful for the `Table` class as it means we can expose the full
-    feature set of the underling `Query` and `Form` classes by just
+    feature set of the underlying `Query` and `Form` classes by just
     dispatching keyword arguments downstream. It also enables us to bundle
     commonly used features in what we call "shortcuts", which are pre-packaged sets of defaults.
     """

docs/test_doc_common_config.py

@@ -5,7 +5,7 @@
 
 Many configuration options are common across iommi, forming part of the cohesive structure which makes it easy to transfer your skills from one part of iommi to another. The most important is `include` which is the command you use to include or exclude a part from an iommi component, for example removing a field from a form or including a field that by default would be hidden (like the primary key for forms and tables).
 
-`attr` and `attrs` are important to understand the difference between.
+`attr` and `attrs` are easy to confuse, so it's important to understand the difference between them.
 
 `auto` is used to generate forms, tables, etc from models.
 

docs/test_doc_cookbook_forms.py

@@ -66,12 +66,12 @@ def test_how_do_i_specify_which_fields_to_show():
     """
     This will show the field `name` only if the GET parameter `some_parameter` is set to `hello!`.
 
-    To be more precise, `include` turns off the entire field. See  :ref:`field-non-editable` and :ref:`field-hidden`  
+    To be more precise, `include` turns off the entire field. See :ref:`field-non-editable` and :ref:`field-hidden`  
     """
 
     # language=rst
     """
-    Use `auto__include`, to specify the complete list of fields you want:
+    Use `auto__include` to specify the complete list of fields you want:
     """
 
     form = Form.create(
@@ -433,7 +433,7 @@ def test_how_do_i_set_if_a_field_is_required():
 
     # language=rst
     """
-    ...and this CSS added to your sites custom style sheet:
+    ...and this CSS added to your site's custom style sheet:
 
     .. code-block:: css
 
@@ -502,8 +502,8 @@ def test_how_do_i_specify_which_model_fields_the_search_of_a_choice_queryset_use
 
     .. _field-search-fields:
 
-    How do I specify which model fields the search of a choice_queryset use?
-    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    How do I specify which model fields the search of a choice_queryset uses?
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     .. uses Field.search_fields
 
     `Form.choice_queryset` uses the registered search fields for filtering and ordering.
@@ -639,7 +639,7 @@ def test_how_do_i_change_how_fields_are_rendered_everywhere_in_my_project():
     When you do that you will get English language relative date parsing
     (e.g. "yesterday", "3 days ago") for free, because iommi used to use a
     text based input control and the parser is applied no matter what
-    (its just that when using the default date picker control it will
+    (it's just that when using the default date picker control it will
     always only see ISO-8601 dates).
     """
 
@@ -859,7 +859,7 @@ def test_non_rendered(black_sabbath):
 
     # language=rst
     """
-    Accessing this create form with `?year=1999` in the title will create this object on submit:
+    Accessing this create form with `?year=1999` in the URL will create this object on submit:
     """
 
     # @test
@@ -895,7 +895,7 @@ def test_grouped_fields():
 
     .. uses Field.group
 
-    Use the `group` field:
+    Use the `group` parameter:
     """
 
     form = Form(
@@ -1113,7 +1113,7 @@ def test_how_do_i_make_a_form_to_create_or_edit(black_sabbath, album):
     .. uses Form.create_or_edit
 
     If you don't know until runtime if you want `Form.create` or `Form.edit`,
-    you can use the `Form.create_or_edit` shortcut. Ff the `instance` is `None`
+    you can use the `Form.create_or_edit` shortcut. If the `instance` is `None`
     it will become a create form, otherwise an edit form:
     """
 
@@ -1238,7 +1238,7 @@ def post_validation(**_):
 
     # language=rst
     """
-    You can get the errors on a given `Field` like this (not that you get a `set`!):
+    You can get the errors on a given `Field` like this (note that you get a `set`!):
     """
 
     # @test

docs/test_doc_cookbook_main_menu.py

@@ -175,7 +175,7 @@ def test_nesting():
     .. uses M.items
     .. uses M.open
 
-    You can create a menu hierarchy with the `items` argument, which produces expandable sections. iommi will open the menu items that matches the current URL by default. You can also force a submenu to be open with the `open` argument:
+    You can create a menu hierarchy with the `items` argument, which produces expandable sections. iommi will open the menu items that match the current URL by default. You can also force a submenu to be open with the `open` argument:
     """
 
     menu = MainMenu(

docs/test_doc_cookbook_parts_pages.py

@@ -118,14 +118,14 @@ def test_how_do_i_set_the_title_of_my_page():
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     .. uses Page.title
 
-    As in the text shown in the browser status bar?
+    The title of a the page is text shown in the browser tab.
 
     """
     Page(title='The title in the browser')
 
     # language=rst
     """
-    Note that this is different from
+    Note that this is different from:
     """
 
     class MyPage(Page):

docs/test_doc_cookbook_queries.py

@@ -103,8 +103,8 @@ def test_how_do_I_set_the_name_for_a_filter(big_discography):
 
     .. uses Filter.query_name
 
-    By default the name of filters are derived from the name you specify or from the model field name
-    For deeply nested names double underscores are replaced with single underscores, and those names
+    By default the names of filters are derived from the name you specify or from the model field name.
+    For deeply nested names, double underscores are replaced with single underscores, and those names
     can become a bit unwieldy. You can then override this with `query_name`:
     """