Am Donnerstag, 7. Januar 2016 17:39:56 UTC+1 schrieb Paul Everitt: > 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 <jona...@findmeon.com > <javascript:>> 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...@googlegroups.com <javascript:>. > To post to this group, send email to pylons...@googlegroups.com > <javascript:>. > Visit this group at https://groups.google.com/group/pylons-devel. > For more options, visit https://groups.google.com/d/optout. > > > :) Nice to see that Michael proposed a talk for PyCon on this topic. I am also using this pattern in Ringo[0] and like the fact that this really makes views more general and life more easy as developer. But I wasn't aware of that this could be a topic for a talk. Actually I thought this is kind of a hack but is seems to be not bad :D.
However in my case I am using this pattern to implement typical CRUD operations on the given context. There are some base views for each operation in CRUD which still does the main logic on the given context but the logic is general and the same for all resources. Specific logic is then put in the model. Thanks to the flexibility of Pyramid its also possible to overwrite the view config and add custom pre or post logic into the view which doesn't fit well into the logic. In my case +1 for that. I am also using route factories a lot and they really tend to make life easier. Have a nice day! [0] http://www.ringo-framework.org -- 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.
