diff --git a/doc/source/dev/handlers.rst b/doc/source/dev/handlers.rst index 3eb7d7aa..09f312d2 100644 --- a/doc/source/dev/handlers.rst +++ b/doc/source/dev/handlers.rst @@ -9,7 +9,7 @@ At application bootstrap, Cement defines the 'output' handler type, and then registers the default output handlers to that type (genshi, and json). As you can see, this is useful in that functions will return data to a genshi template, but if the '--json' option is passed it is rendered as Json. -Additionally, developers can add additional handlers via plugins such as the +Developers can add additional handlers via plugins such as the Rosendale YAML Plugin which adds an output handler called 'yaml', and is called when the user passes '--yaml'. @@ -34,7 +34,7 @@ and can be accessed as the following (from within a loaded cement app): handlers['output'] -Handlers should be defined within you bootstrap process, generally in the +Handlers should be defined within your bootstrap process, generally in the root bootstrap. To define a handler type, add something similar to the following: @@ -80,11 +80,11 @@ How a handler is accessed depends on how the handler is defined. Does it expect arguments? Does it return data? This is all for the developer of the application to determine, and document. As an example, lets say we have a database handler. We want to use handlers to setup and provide access to -two different databases. One for read operations, and one for write . +two different databases. One for read operations, and one for write operations. Please note, this is a psuedo example and will not have any real database interaction. -**helloworld/core/database.py** +helloworld/core/database.py .. code-block:: python @@ -101,7 +101,7 @@ database interaction. raise NotImplementedError, "Database.query() must be subclassed." -**helloworld/lib/database/mysql.py** +helloworld/lib/database/mysql.py .. code-block:: python @@ -117,7 +117,7 @@ database interaction. return query_results -**helloworld/bootstrap/root.py** +helloworld/bootstrap/root.py .. code-block:: python @@ -133,7 +133,9 @@ database interaction. register_handler('database', 'write_db', write_db) -**helloworld/controller/root.py** +helloworld/controller/root.py + +.. code-block:: python from cement.core.handler import get_handler @@ -147,6 +149,4 @@ database interaction. def update_something(self): # do some operation on the write database server db = get_handler('database', 'write_db') - db.query('some system to update something') - - \ No newline at end of file + db.query('some query to update something') diff --git a/doc/source/dev/hooks.rst b/doc/source/dev/hooks.rst index 306e3e84..fe524457 100644 --- a/doc/source/dev/hooks.rst +++ b/doc/source/dev/hooks.rst @@ -196,7 +196,7 @@ function. And the result? In example_hook number 1, weight = 99 -As you can see, it doesn’t matter what order we place register the hook, the +As you can see, it doesn’t matter what order we register the hook, the weight runs then in order from lowest to highest. Hooks are awesome and provide a little bit of magic to your application. Be sure to properly document any hooks you define, what their purpose is and where they will diff --git a/doc/source/dev/options_and_arguments.rst b/doc/source/dev/options_and_arguments.rst index 57381326..a3d5bdfd 100644 --- a/doc/source/dev/options_and_arguments.rst +++ b/doc/source/dev/options_and_arguments.rst @@ -198,7 +198,7 @@ is what is displayed in --help. example.options.add_option('-F', '--foo', action='store', dest='foo', help='pass value to foo', metavar='STR') -The above sets namespaces['example'].config['foot'] to the value passed at +The above sets namespaces['example'].config['foo'] to the value passed at command line (helloworld --foo=bar), and also sets self.cli_opts.foo the same. metavar is an extra option that alters the display in --help (-F STR, --foo=STR).