For the O’Reilly video series on Pyramid (and for the proposed PyCon talk with @mmerickel), I emphasized route factories. Move the location of the model instance out of the view and into the framework, namely, a context variable passed into the view.
I then moved more helper-style logic into the model class. I then made the model class into a “service" for operations that don’t yet have an instance, e.g. list all invoices, add an invoice, search for invoices. These became class methods on the SQLAlchemy model. My route factory then learned whether to return an instance or the class, as the context. After that, the views don’t do much. I reached the same point as Jonathan…views were just for view-y stuff (handling form data, massaging output formats, whatever.) Arranging to have a “context” is a pattern I’d love to see emphasized more. —Paul > On Jan 7, 2016, at 11:03 AM, Jonathan Vanasco <jonat...@findmeon.com> wrote: > > 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 > <mailto:pylons-devel+unsubscr...@googlegroups.com>. > To post to this group, send email to pylons-devel@googlegroups.com > <mailto:pylons-devel@googlegroups.com>. > Visit this group at https://groups.google.com/group/pylons-devel > <https://groups.google.com/group/pylons-devel>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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.
