In my experience, the standard scaffold way is perfect for most uses.

If your codebase grows very large, or you start needed to run non-pyramid 
services, you may need to rethink things.

One of my projects outgrew the typical 'views' approach.  Now, we prototype 
the functionality onto the views but then create functions that do all the 
real work in a `lib.api` namespace.  The views just format data for the 
internal api and pass in the right arguments.  The main reason why migrated 
to this approach, is that a lot of shell scripts / celery functions / 
twisted functions (and some microservices tested out in flask) were all 
needing to do the same things.  Now we just import a core library that has 
the models and api into whatever application.

Just to be a bit more clear, in our approach:

* pyramid + view = validate form data, handle form responses, decide what 
to query/insert/update/etc
* model + api = accepts formatted args and connections to database + 
request/caching layer for routine tasks.

You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
Visit this group at
For more options, visit

Reply via email to