Hello
I'm a turbogears newbie and I volunteered to fix some
of the tg1 docs but I needed to learn a bit to get myself
started. So I've been staring at the tg2 docs a while.
There are a few typos in them, and I'm attaching output of an
svn diff docs/main/*.rst
of mostly spelling/repeated word corrections.
(ispell and good old awk)
Hope it's ok to attach the file here - it seemed a bit long to try
and copy/paste into pastebin.
Anita
ps - the long lines are as I found the docs, but they make it
hard spotting the changes.
Index: SimpleWidgetForm.rst
===================================================================
--- SimpleWidgetForm.rst (revision 6277)
+++ SimpleWidgetForm.rst (working copy)
@@ -60,7 +60,7 @@
Simple form field widgets generally correspond to the default browser inputs
but some, like the date picker, have extra smarts to make your user's lives
easier. You can get an overview of which widgets are available on your install
-by checking out paster tg-info, and you can find more detaills about
particular widgets by using the the toscawidgets widget browser:
+by checking out paster tg-info, and you can find more details about particular
widgets by using the toscawidgets widget browser:
http://toscawidgets.org/documentation/WidgetBrowser/
@@ -85,7 +85,7 @@
"""The WidgetsList defines the fields of the form."""
name = forms.TextField(validator=validators.NotEmpty())
- email = fomss.TextField(validator=validators.Email(not_empty=True),
+ email = forms.TextField(validator=validators.Email(not_empty=True),
attrs={'size':30})
comment = forms.TextArea(validator=validators.NotEmpty())
notify = forms.CheckBox(label="Notify me")
@@ -224,7 +224,7 @@
Validation ensures that the values you're getting are the values your method
is expecting. Sometimes this is critically important, other times it's
convenient, but quite a bit of time in web programming is traditionally tied
-up in displaying a form, processing the form, validating it's values, and --
+up in displaying a form, processing the form, validating its values, and --
in the event of errors-- redisplaying the form with the errors marked.
TurboGears widgets were created explicitly to solve this problem.
@@ -243,7 +243,7 @@
"""The WidgetsList defines the fields of the form."""
name = forms.TextField(validator=validators.NotEmpty())
- email = fomss.TextField(validator=validators.Email(not_empty=True),
+ email = forms.TextField(validator=validators.Email(not_empty=True),
attrs={'size':30})
comment = forms.TextArea(validator=validators.NotEmpty())
notify = forms.CheckBox(label="Notify me")
Index: License.rst
===================================================================
--- License.rst (revision 6277)
+++ License.rst (working copy)
@@ -5,7 +5,7 @@
:Status: Official
-**Summary: There's no GPL incompatible provisos sneaked into any of these
licenses, and all of TG2 and it's underlying components are not copy_left
licensed, so you can include them in your projects -- even if they are
propritary**
+**Summary: There's no GPL incompatible provisos sneaked into any of these
licenses, and all of TG2 and its underlying components are not copy_left
licensed, so you can include them in your projects -- even if they are
proprietary**
Note that the following paragraphs are **not legal advice**. They are one
person's interpretations of the software licenses involved. If you have any
questions or concerns about the licenses, you should consult a lawyer.
Index: DevStatus.rst
===================================================================
--- DevStatus.rst (revision 6277)
+++ DevStatus.rst (working copy)
@@ -3,7 +3,7 @@
TurboGears 2 arose out of some discussions about how similar the TurboGears 1
and Pylons frameworks were to each other. We shared similar philosophies, and
some similar implementation choices (we both used SQLObject and switched to
SQLAlchemy for example).
-TurboGears is currently based on the as yet unreleased Pylons 0.9.7. We plan
to do a preview release of TG2 (version 1.9.7a1) shortly after the Pylons
release. We will will then track Pylons as they approach 1.0, with the
intention of releasing TurboGears 2 at essentially the same time as Pylons 1.0.
+TurboGears is currently based on the as yet unreleased Pylons 0.9.7. We plan
to do a preview release of TG2 (version 1.9.7a1) shortly after the Pylons
release. We will then track Pylons as they approach 1.0, with the intention of
releasing TurboGears 2 at essentially the same time as Pylons 1.0.
Current plans are to have the first official release 1.9.7a1 sometime early in
April, and to have a full 2.0 release by the end of the year. But open source
projects are notoriously difficult to schedule, and it's possible that 2.0 will
come out significantly before then, or that it will take longer.
Index: FormBasics.rst
===================================================================
--- FormBasics.rst (revision 6277)
+++ FormBasics.rst (working copy)
@@ -26,7 +26,7 @@
#. Make it easy to re-display form results with associated error messages.
Rather than re-invent the wheel for these three things TurboGears has brought
-together and integrated a some tools that specialize these things.
+together and integrated some tools that specialize these things.
Validation is handled by FormEncode, form generation by ToscaWidgets, and model
introspection+automatic form and validator generation can be provided by
DBSprockets.
@@ -42,7 +42,7 @@
login_form = make_form(User, identifier='myLoginForm', action='/login',
limitFields=['user_name', 'password'])
-This form is actually a ToscaWidgets CompoundWidget object, with member
widgets for each of the form fields, and with some code to wrap them up in a
form and display them to the user. DBSprockets takes the User object
introspects it's table information, and makes a form for you. In this case,
we're limiting the fields that show up on the form to those needed for the
user_name and password columns.
+This form is actually a ToscaWidgets CompoundWidget object, with member
widgets for each of the form fields, and with some code to wrap them up in a
form and display them to the user. DBSprockets takes the User object
introspects its table information, and makes a form for you. In this case,
we're limiting the fields that show up on the form to those needed for the
user_name and password columns.
We can then add that widget to the list of widgets available in the template
by adding it to tmpl_context in your controller::
@@ -61,13 +61,13 @@
def login(self, user_name, password):
return dict()
-If there are errors, they will be saved in ``tmpl_context.form_errors`` which
is automatically available in your template. And the widget is designed to
look trough tmpl_context.form_errors for error messages and display them along
side the form when it's displayed. That way you can use the same template, and
the same widget to redisplay the form along with the errors whenever there are
form validation errors.
+If there are errors, they will be saved in ``tmpl_context.form_errors`` which
is automatically available in your template. And the widget is designed to
look through tmpl_context.form_errors for error messages and display them along
side the form when it's displayed. That way you can use the same template, and
the same widget to redisplay the form along with the errors whenever there are
form validation errors.
-To take advantage of this we can assign our original ``display_login`` page as
the ``error_handler`` for this form. like this::
+To take advantage of this we can assign our original ``display_login`` page as
the ``error_handler`` for this form, like this::
@validate(form=login_form, error_handler=display_login)
def login(self, user_name, password):
return dict()
-If there's a validation error, control will be passed to display_login, but
this time there will be some data in tmpl_context so that when the form widget
is rendered, it will get those validation error messages and display them for
you:
+If there's a validation error, control will be passed to display_login, but
this time there will be some data in tmpl_context so that when the form widget
is rendered, it will get those validation error messages and display them for
you.
Index: Validation.rst
===================================================================
--- Validation.rst (revision 6277)
+++ Validation.rst (working copy)
@@ -37,7 +37,7 @@
@expose('json')
@validate(validators={"a":validators.Int(), "b":validators.Email})
def two_validators(self, a=None, b=None, *args):
- errors = [{key, value} in pylons.c.form_errors.itteritems()]
+ errors = [{key, value} in pylons.c.form_errors.iteritems()]
values = pylons.c.form_values
return dict(a=a, b=b, errors=str(errors), values=str(values))
@@ -152,7 +152,7 @@
@validate(forms.myform, error_handler=process_form_errors)
-The method in question will be called, with the unvalidated data as it's
params.
+The method in question will be called, with the unvalidated data as its
params.
And error validation messages will be stored in pylons.tmpl_context.
Here's a quick example of how this all works:
@@ -208,9 +208,9 @@
fields.
Again, for information about ``Invalid`` exception objects, creating your own
-validators, schema and FormEncode in general, a refer to the `FormEncode
+validators, schema and FormEncode in general, refer to the `FormEncode
Validator`_ documentation and don't be afraid to check the
-``Formencode.validators`` source. It's often more clear than the docs.
+``Formencode.validators`` source. It's often clearer than the docs.
.. _`FormEncode Validator`: http://formencode.org/docs/Validator.html
@@ -239,4 +239,4 @@
users. In the end, it's usually far simpler to use the
validation framework.
-.. _FormEncode: http://formencode.org/
\ No newline at end of file
+.. _FormEncode: http://formencode.org/
Index: QuickStart.rst
===================================================================
--- QuickStart.rst (revision 6277)
+++ QuickStart.rst (working copy)
@@ -44,7 +44,7 @@
$ paster setup-app development.ini
-As soon as that's done. Point your browser at http://localhost:8080/, and
you'll see a nice welcome page with the inform(flash) message and current time.
+As soon as that's done, point your browser at http://localhost:8080/, and
you'll see a nice welcome page with the inform(flash) message and current time.
If you're exploring TurboGears 2 after using TurboGears 1, you may notice that
the old config file `dev.cfg` file is now `development.ini`.
And by default the 'paster serve' is not in auto-reload mode.
@@ -61,7 +61,7 @@
* development.ini : The system configuration is laid on development.ini for
development configuration
* helloworld/controllers/root.py gets called to handle URL, and do whatever
needs doing to create the data for the welcome page.
- * helloworld/templates/index.html is the template turbogears uses to render
the the welcome page from the dictionary returned by the root controller. It's
an standard XHTML with some simple namespaced attributes.
+ * helloworld/templates/index.html is the template turbogears uses to render
the welcome page from the dictionary returned by the root controller. It's
standard XHTML with some simple namespaced attributes.
* helloworld/public/ is the place to hold static files, such as pictures,
javascript, or css files.
You can easily edit development.ini to change the default server port used by
the built-in web server::
Index: BasicMoves.rst
===================================================================
--- BasicMoves.rst (revision 6277)
+++ BasicMoves.rst (working copy)
@@ -83,7 +83,7 @@
So far we're getting somewhere, we've been returning plain text for every
incoming request. But you might have noticed how the default welcome page work.
-We can edit index template, use controllers to define new url's. But let's
take it one step further and create yet another new URL, plug plug real
templates into the controllers, and this time rather than returning a string,
we'll return a dictionary:
+We can edit index template, use controllers to define new urls. But let's take
it one step further and create yet another new URL, plug real templates into
the controllers, and this time rather than returning a string, we'll return a
dictionary:
.. code-block:: python
@@ -112,7 +112,7 @@
Browse http://localhost:8080 to see the change.
-TurboGears 2 uses the Genshi templating system by deault for controlling
dynamic content in your markup.
+TurboGears 2 uses the Genshi templating system by default for controlling
dynamic content in your markup.
Template arguments are used to pass variables and other dynamic content to the
template.
To create more skeletons for your templates, just copy the default index.html
template that was generated when your project was created.
Index: WhatsNew.rst
===================================================================
--- WhatsNew.rst (revision 6277)
+++ WhatsNew.rst (working copy)
@@ -20,7 +20,7 @@
Well, Pylons is committed to being officially template engine agnostic, ORM
agnostic, etc. On the other hand TurboGears is committed to providing a
"Full-Stack" for web development. So, the two communities have different, but
compatible priorities. If you think about it Pylons provides a great set of
tools for building a full stack framework, and people had been asking for a
full-stack Pylons implementation for a long time. And TurboGears 2 will
provide that.
-There are a lot of benefits to having a full-stack. You can build form
helpers which do all sorts of interesting things (introspect model objects to
make web-based forms, automatically display form errors, etc) because you can
make some assumptions about what tools will be available and what will be used.
In particular, you can start building plugable website components much more
easily, because you are building on a known set of tools.
+There are a lot of benefits to having a full-stack. You can build form
helpers which do all sorts of interesting things (introspect model objects to
make web-based forms, automatically display form errors, etc) because you can
make some assumptions about what tools will be available and what will be used.
In particular, you can start building pluggable website components much more
easily, because you are building on a known set of tools.
Why not use CherryPy 3?
~~~~~~~~~~~~~~~~~~~~~~~
@@ -69,7 +69,7 @@
* All template engines now have search paths to find the templates.
The default template directory is on the search path so using dotted
notation in @expose decorators has been deprecated.
- * Object dispatch does not support dots in URL's the way TurboGears 1 did.
+ * Object dispatch does not support dots in URLs the way TurboGears 1 did.
* CherryPy request and response objects replaces with WebOb request and
response objects.
Command changes
Index: SQLAlchemy.rst
===================================================================
--- SQLAlchemy.rst (revision 6277)
+++ SQLAlchemy.rst (working copy)
@@ -20,10 +20,10 @@
Your quickstarted project will have a subpackage called `model`, made up of
the following files:
-* `__init__.py`: This is where the database access is setup. Your tables
should be imported into this module, and you're highly encouaged to define them
in a separate module - `entities`, for example.
+* `__init__.py`: This is where the database access is set up. Your tables
should be imported into this module, and you're highly encouraged to define
them in a separate module - `entities`, for example.
* `auth.py`: This file will be created if you enabled authentication and
authorization in the quickstart. It defines the three tables
:mod:`repoze.what.quickstart` relies on: `User` (for the registered members in
your website), `Group` (for the teams a member may belong to, and to which you
can assign permissions) and `Permission` (a permission granted to one or more
groups); it also defines two intermediary tables: One for the many-to-many
relationship between the groups and the permissions, and another one for the
many-to-many relationship between the users and the groups.
-Auto-reflection of tables has to happen after all the configuration is read,
and the app is setup, so we provide simple init_model method (defined in
`model/__init__.py`) that is not called until after everything is setup for you.
+Auto-reflection of tables has to happen after all the configuration is read,
and the app is set up, so we provide simple init_model method (defined in
`model/__init__.py`) that is not called until after everything is set up for
you.
Defining your own tables
@@ -50,9 +50,9 @@
Choosing data Types
---------------------
-When you're setting up the column types for your tables, you don't have to
think about your target database and it's type system. SQLAlchemy provides a
flexible underlying type system that, along with the table definition syntax
above, allows you to database independent table objects.
+When you're setting up the column types for your tables, you don't have to
think about your target database and its type system. SQLAlchemy provides a
flexible underlying type system that, along with the table definition syntax
above, allows you to define database-independent table objects.
-SQLAlchemy provides a number of built-in types which it automatically maps to
underling database types. If you want the latest and greatest listing just
type:
+SQLAlchemy provides a number of built-in types which it automatically maps to
underlying database types. If you want the latest and greatest listing just
type:
.. code-block:: python
@@ -81,7 +81,7 @@
Properties
~~~~~~~~~~~
-While you define the Columns, you could specify several properties to control
the column's behaviors.
+As you define a column, you can specify several properties to control the
column's behavior.
============ ==========
property value
@@ -109,7 +109,7 @@
If you don't define the __init__ method. You will need to update the
properties of a movie object after it's been created. like this::
>>> entry = Movie()
- >>> entry.title = 'Dragula'
+ >>> entry.title = 'Dracula'
>>> entry.year = '1931'
>>> entry.description = 'vampire movie'
@@ -144,7 +144,7 @@
Pylons (the TurboGears 2 underground framework) defines a setup-app function
that paster will connect to the database and create all the tables we've
defined.
-The default database setup configurations are defined in development.ini. So
if you just run the script without modification of development.ini, the script
will create a single-file database, which called 'devdata.db', in your project
directory. If you change your data model and want to apply the new database, go
delete 'devdata.db' and run the 'paster setup-app' command again.
+The default database setup configurations are defined in development.ini. So
if you just run the script without modification of development.ini, the script
will create a single-file database called 'devdata.db' in your project
directory. If you change your data model and want to apply the new database,
delete 'devdata.db' and run the 'paster setup-app' command again.
TurboGears 2 does support database migrations. But that's another tutorial.
Index: OfflineInstall.rst
===================================================================
--- OfflineInstall.rst (revision 6277)
+++ OfflineInstall.rst (working copy)
@@ -14,7 +14,7 @@
$ cd eggs
$ easy_install tg.devtools
-To get the latest versions from SVN and install offline you can do a a SVN
+To get the latest versions from SVN and install offline you can do an SVN
checkout of the TG2 sources, and a mercurial checkout of Pylons, and install
those on top of the above eggs.
Index: Genshi.rst
===================================================================
--- Genshi.rst (revision 6277)
+++ Genshi.rst (working copy)
@@ -7,7 +7,7 @@
Simple genshi example
--------------------------
-Genshi is an XML template language based on Kid, which in turn was inspired by
zope's TAL. Genshi is the default template language of TurboGears2, and it
provides a very similar API to it's predecessor.
+Genshi is an XML template language based on Kid, which in turn was inspired by
zope's TAL. Genshi is the default template language of TurboGears2, and it
provides a very similar API to its predecessor.
Genshi Templates look like XHTML. Here's a sample genshi template:
@@ -34,7 +34,7 @@
</body>
</html>
-This particular template does a couple of things, but it's main function is to
take each variable that's been made available in the template namespace and
display it's name and it's value.
+This particular template does a couple of things, but its main function is to
take each variable that's been made available in the template namespace and
display its name and its value.
Every template language in the world needs to provide a variable substitution
syntax, and the standard way in python seems to be ``${item}``, and that's
exactly what you do in Genshi. Take a variable wrap it in curly braces and
throw a $ in front, and the value of the variable will be substituted in when
the template is rendered. Genshi is nice in that it allows you to use full
python expressions in the substitution.
@@ -44,11 +44,11 @@
it evaluates the python expression ``repr(locals()['data'][item])`` and
provides the string representation of the proper item.
-And if you look a line up, you'll see where item is defined as one of the list
of keys in the dictionary representing the local variables. The way this works
is that py:for acts just like a standard python for loop, repeating the <div>
that it's (and it's children if there were any) once for each item in the
dictionary.
+And if you look a line up, you'll see where item is defined as one of the list
of keys in the dictionary representing the local variables. The way this works
is that py:for acts just like a standard python for loop, repeating the <div>
that it's in (and its children if there were any) once for each item in the
dictionary.
-In TurboGears 2 the template namespace is going to be populated with the items
you return in your controller's return dictionary, along with a few extras.
This particular template can be very helpful when debugging a controller's
return values, and is included in the default quickstarted project for you.
+In TurboGears 2 the template namespace is going to be populated with the items
you return in your controller's return dictionary, along with a few extras.
This particular template can be very helpful when debugging a controller's
return values, and is included in default quickstarted projects for you as
`project_name/templates/debug.html`.
-The general way that Genshi works it that it allows you to add special
attributes to your xml elements, called *Template Directives*. Each of these
template directives should be given a value, which can be ANY python
expression. So, learning Genshi is pretty much about leanring how those
directives work, since the rest is just python. And like py:for, most of the
directives are very "python like".
+The general way that Genshi works it that it allows you to add special
attributes to your xml elements, called *Template Directives*. Each of these
template directives should be given a value, which can be ANY python
expression. So, learning Genshi is pretty much about leaning how those
directives work, since the rest is just python. And like py:for, most of the
directives are very "python like".
Available Processing Directives:
------------------------------------------
@@ -56,13 +56,13 @@
Here's a list of all the Template Directives in Genshi, along with a brief
description.
======================= ======================
-Gensh Directive Definition
+Genshi Directive Definition
======================= ======================
-``py:if`` Displays the element and it's children if the
condition is true.
+``py:if`` Displays the element and its children if the condition
is true.
``py:choose`` Used with py:when and py:otherwise to select one of
several options to be rendered.
-``py:when`` Used with py:choose -- displays an element and it's
children when the condition is true.
+``py:when`` Used with py:choose -- displays an element and its
children when the condition is true.
``py:otherwise`` Used with py:when and py:choose, displays if non of
the when clauses are true.
-``py:for`` Repeats the element (and it's children) for each item
in some iterable
+``py:for`` Repeats the element (and its children) for each item
in some iterable
``py:with`` Lets you assign expressions to variables
``py:replace`` Replaces the element with the contents of the
expression, stripping out the element itself.
``py:def`` Creates a re-usable "template function" that can be
used to render template
@@ -70,11 +70,11 @@
``py:match`` given an XPath expression, it finds and replaces every
element in the
template that matches the expression -- with the
content of the element
containing the py:match.
-``py:strip`` Removes just the containing element (not it's
children) if the condition is true.
+``py:strip`` Removes just the containing element (not its children)
if the condition is true.
======================= ======================
-There are examples of how each of these template directives work on the Genshi
web site.
+There are examples of how each of these template directives works on the
Genshi web site.
http://genshi.edgewall.org/wiki/Documentation/xml-templates.html
Index: DatabaseMigration.rst
===================================================================
--- DatabaseMigration.rst (revision 6277)
+++ DatabaseMigration.rst (working copy)
@@ -83,7 +83,7 @@
Our repository is ready. Now we must create a table
for maintaining revision state in our managed database. The ``migrate``
-script providesnd for this step as well:
+script provides for this step as well:
$ migrate version_control sqlite:///devdata.db migration
Index: Session.rst
===================================================================
--- Session.rst (revision 6277)
+++ Session.rst (working copy)
@@ -36,7 +36,7 @@
from tg import session
-What you get is a Session instance that is always request-local, in other
words, it's the session for this particular user. The session can be
manipulated in much the same way as a standard python dictionnary.
+What you get is a Session instance that is always request-local, in other
words, it's the session for this particular user. The session can be
manipulated in much the same way as a standard python dictionary.
Here is how you search for a key in the session::
Index: RoutesIntegration.rst
===================================================================
--- RoutesIntegration.rst (revision 6277)
+++ RoutesIntegration.rst (working copy)
@@ -14,7 +14,7 @@
RootController, which sees that the action is route, and does object
dispatch in the same way that TurboGears 1 did.
-But if you want to create special routes that overide Object Dispatch,
+But if you want to create special routes that override Object Dispatch,
you can easily do that, just by providing your own function to setup the
routes map. You can update the routes defaults by overriding the setup_routes
method of the base_config object in app_cfg.py.
@@ -24,7 +24,7 @@
def setup_routes(self):
"""Setup the default TG2 routes
- Overide this and setup your own routes maps if you want to use routes.
+ Override this and setup your own routes maps if you want to use routes.
"""
map = Mapper(directory=config['pylons.paths']['controllers'],
always_scan=config['debug'])
Index: CommandLine.rst
===================================================================
--- CommandLine.rst (revision 6277)
+++ CommandLine.rst (working copy)
@@ -1,6 +1,6 @@
.. _commandline-reference:
-TurboGears2 delegates it's command line tasks to Paste, in TG1.x this was a
build in command which was drop in favor of the more robust Paste
infraestructure.
+TurboGears2 delegates its command line tasks to Paste, in TG1.x this was a
build in command which was drop in favor of the more robust Paste
infrastructure.
What is PasteScript?
====================
Index: DownloadInstall.rst
===================================================================
--- DownloadInstall.rst (revision 6277)
+++ DownloadInstall.rst (working copy)
@@ -28,8 +28,7 @@
* Python 2.4, 2.5, or 2.6
* Appropriate python development package (python*-devel python*-dev)
-.. hint::
- Python 2.4 users will also need to install pysqlite themselves in
+.. hint:: Python 2.4 users will also need to install pysqlite themselves in
order to use the sqlite database setup in the default development.ini
but you're also free to just install and use your database of choice.
@@ -68,7 +67,7 @@
On Unix:
-You will likely need root permissions to install virtualenv in you your
system's
+You will likely need root permissions to install virtualenv in your system's
site-packages directory:
.. code-block:: bash
@@ -147,11 +146,11 @@
$ easy_install -U -i http://www.turbogears.org/2.0/downloads/current/index
tg.devtools
-All of turbogears, and all of its dependencies should download and install
themselves.
+All of turbogears and all of its dependencies should download and install
themselves.
(This may take a several min.)
Validate the installation:
-~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~
To check if you installed TurboGears 2 correctly, type
@@ -195,7 +194,7 @@
to get a picture of what's changed in TurboGears2 so far.
Special Considerations:
-~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~
**Cygwin** does not include the necessary binary file **sqlite3.dll**;
if you want to run Cygwin you'll need to install a different database.
@@ -205,7 +204,7 @@
Installing the development version of Turbogears 2 (from source)
---------------------------------------------------------------
+----------------------------------------------------------------
See `Contributing to Turbogears 2`_
Index: movie_tutorial.rst
===================================================================
--- movie_tutorial.rst (revision 6277)
+++ movie_tutorial.rst (working copy)
@@ -135,18 +135,18 @@
of a movie object after it's been created like this::
>>> entry = Movie()
- >>> entry.title = 'Dragula'
+ >>> entry.title = 'Dracula'
>>> entry.year = '1931'
>>> entry.description = 'vampire movie'
But if the __init__ method we defined allows you to initialize the properties
at the same time you create the object::
- >>> entry = Movie(title='Drakula', year='1931', description='vampire movie')
+ >>> entry = Movie(title='Dracula', year='1931', description='vampire movie')
or ::
- >>> entry = Movie('Drakula', '1931', 'vampire movie')
+ >>> entry = Movie('Dracula', '1931', 'vampire movie')
Bootstrapping the application with CRUD
========================================
Index: Internationalization.rst
===================================================================
--- Internationalization.rst (revision 6277)
+++ Internationalization.rst (working copy)
@@ -45,7 +45,7 @@
('public/**', 'ignore', None)]},
This is an extraction method mapping that indicates to distutils which files
-should be search for strings to be translated.
+should be searched for strings to be translated.
TurboGears2 uses Babel to extract messages to a .pot file in your project's
i18n directory.
Don't forget to add it to your revision control system if you use one.
@@ -67,7 +67,7 @@
3. Edit your language in il8n/[country code]/LC_MESSAGES/[project-name].po
If you're not an expert in i18n or if you would like to give the files to
-someone else so that he helps you we recommand that you use the really nice
+someone else so that he helps you we recommend that you use the really nice
poedit program. This program works nicely on GNU/Linux and Windows
and provides a nice user-interface to edit po files.
@@ -95,7 +95,7 @@
---------
-To fresh start a translation, you could use following command to handle your
+To fresh start a translation, you could use the following command to handle
your
locales:
init_catalog
Index: Config.rst
===================================================================
--- Config.rst (revision 6277)
+++ Config.rst (working copy)
@@ -9,7 +9,7 @@
Like TurboGears 1, the application configuration is separated from the
deployment specific information. In TG2 there is a config module, containing
several configuration specific python files -- these are done in python not
-as INI files, because they actually setup the TG2 application and it's
associated WSGI middleware. And these files are intended to be edited only by
application developers, not by those deploying the application.
+as INI files, because they actually setup the TG2 application and its
associated WSGI middleware. And these files are intended to be edited only by
application developers, not by those deploying the application.
At the same time the deployment level configuration is done in simple .ini
files.
@@ -45,7 +45,7 @@
app_cfg.py exists primarily so that middleware.py and environment.py can
import and use the ``base_config`` object.
The ``base_config`` object is an ``AppConfig()`` instance which allows you to
-access it's attributes like a normal object, or like a standard python
dictionary. One of the reasons for this is that ``AppConfig()`` provides some
defaults in it's ``__init__``. But equally important it provides us with
several methods that work on the config values to produce the two functions
that setup your TurboGears app. Since this is all done in your code, you can
subclass or overide ``AppConfig`` to get exactly the setup you want.
+access its attributes like a normal object, or like a standard python
dictionary. One of the reasons for this is that ``AppConfig()`` provides some
defaults in its ``__init__``. But equally important it provides us with
several methods that work on the config values to produce the two functions
that set up your TurboGears app. Since this is all done in your code, you can
subclass or override ``AppConfig`` to get exactly the setup you want.
The ``base_config`` object that is created in ``app_cfg.py`` should be used to
set whatever configuration values that belong to the application itself and are
required for all instances of this app, as distinct from the configuration
values that you set in the ``development.ini`` or ``deployment.ini`` files that
are intended to be editable by those who deploy the app.
Index: Controllers.rst
===================================================================
--- Controllers.rst (revision 6277)
+++ Controllers.rst (working copy)
@@ -280,7 +280,7 @@
about the way WSGI works. But it's also the right thing to do from the
perspective of URL joins. Because you didn't have a trailing slash, there's no
way to know you meant to be in the movie directory, so redirection to relative
-URL's will be based on the last / in the URL. In this case the root of the
site.
+URLs will be based on the last / in the URL. In this case the root of the
site.
It's easy enough to get around this, all you have to do is write your redirect
like this::
@@ -377,7 +377,7 @@
del users[id]
redirect('./')
-For the "edit" method the template might contatin something like this:
+For the "edit" method the template might contain something like this:
.. code-block:: html
@@ -394,7 +394,7 @@
<input type="text" name="name" value="$value"/>
</form>
-And finally a "delete" template containting this:
+And finally a "delete" template containing this:
.. code-block:: html
@@ -405,7 +405,7 @@
Rest methods work just like any other controller method in TurboGears,
which means you can validate, or expose them in any method of your choosing.
-It is very common to use content-type dispatch allong with get_all to return
+It is very common to use content-type dispatch along with get_all to return
both a page containing a table and some JavaScript links along with
You may have noticed the "_method" hidden field within the forms. This is
needed because
browsers do not yet support all of the HTTP verbs required to provide a
@@ -432,7 +432,7 @@
So if you visit jsonexample/users you will get the results of a rendered
template, but if you visit
-jsonexaple/users.json, you get a json stream containing the users data.
Notice that we don't return
+jsonexample/users.json, you get a json stream containing the users data.
Notice that we don't return
the list of users. Most of the time, json streams are comprised of
dictionaries for security reasons.
It is important to note that the mime-type associated with the request's
response type are stored at
pylons.request.response_type, and the extension used to generate that
mime-type is stored at
Index: Contributing.rst
===================================================================
--- Contributing.rst (revision 6277)
+++ Contributing.rst (working copy)
@@ -78,7 +78,7 @@
TurboGears 2 is composed of 2 packages. You also need 2 more package with are
the authorization framework
-Check out the latest code from the subversion respositories:
+Check out the latest code from the subversion repositories:
.. code-block:: bash
@@ -253,8 +253,8 @@
`(tg2dev)` will be prefixed to your prompt to indicate that the
`tg2dev` virtualenv is activated.
-Check out the latest version of the docs soruces from the subversion
-respositories:
+Check out the latest version of the docs sources from the subversion
+repositories:
.. code-block:: bash
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Docs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/turbogears-docs?hl=en
-~----------~----~----~----~------~----~------~--~---
