Both of these are common in larger Pyramid applications, although usually
you would group the views by application section rather than than making
every view separate.
The first thing to note is that functions and classes are not related to
modules at all. A .py file is a module. It can contain any number of
functions and classes.
For the routes, make a module, normally called 'routes.py' at the same
level as the top-level '__init__.py'. Put a 'def includeme(config):'
function in, it, containing all the config.add_route() calls. Then in the
main function, include it with 'config.include(".routes")' .
For the views, convert views.py to a package, meaning replace it with a
'views' directory with an empty '__init__.py' file, and put your view
modules in there. The view callables will still have the same structure and
imports as normal.
To connect the views to routes, use '@view_config' the normal way, with a
corresponding 'config.scan(".views")' call in the main function.
To use the same route with multiple views, using a match variable or some
other aspect of the request to determine which view to call, see the
'@view_config' optional arguments.
What you CAN"T do in Pyramid (unlike Pylons), is use a routing variable to
look up a view by name. Every view must be attached to a route at startup,
using the '@view_config' arguments as the link between them.
> *+ *How can I create a class .py which is not intended to be used as view
> callable but as an object *to be called by view callables*, again, *very
> importantly*, *on its own .py file. *
You can define any utility classes you want, and put them anywhere. If the
classes are more or less generic, and applicable to several views, you'd
normally create a 'lib' package and put your utility modules there.
I wrote some documentation which was intended for people with a Pylons
background, but it may be indirectly useful. See:
Pyramid for Pylons Users
Mike Orr <sluggos...@gmail.com>