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 pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at https://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/d/optout.
