Probably one of the nicest thing that I have seen in a while.
I really like your approach. I'm not familiar with registry so I was
mainly using dependency injection to help my testing by substituting with
stub objects/services when I was testing view directly.
Eg:
def view(context, request,
_service=services.something,
_serializer=serializer.something):
#...
result = _service.biz_method()
#...
return _serializer(result)
Your approach with service is very nice, it offer me all the same
flexibility of being able to inject Stub for testing with the benefit of
designing my code by contract .. with your approach I can define some dummy
service for some dev environment.
Thanks for sharing it, now I want to go through my code and move it to
pyramid_services.
I really need to learn more about extending pyramid.
On Thu, Feb 19, 2015 at 9:49 AM, Michael Merickel <[email protected]>
wrote:
> On Thu, Feb 19, 2015 at 5:59 AM, Oliver Berger <[email protected]> wrote:
> > What would be the difference except a more or less unified API to
> retrieve
> > the services?
> > May be I am missing the point....
>
> My apps tend to have more factories than utilities, and they need to
> share things like database connections across them. Even the database
> connection is a factory. pyramid_services caches the result objects on
> the request so that they are only created once per request and shared
> so that database connection is only created once and then fed into
> each factory that needs it. The demo in the docs illustrates this
> happening.
>
> So to address your comments I'd say that first, your examples are
> basically all I'm doing under the hood aside from caching so don't
> stop if it works for you! Most people I've encountered don't know
> anything about multi-adapters though and don't want to. The four
> advantages I'd lay out are
>
> 1) a more unified API
> 2) a more strict coupling of services to the request lifecycle
> 3) all wiring/dependencies between services are setup at config time
> instead of in your views
> 4) and building off of that abstracted wiring, there's less zopey
> things going on in views allowing you to just focus on using the
> services as they were configured.
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/pylons-discuss.
> For more options, visit https://groups.google.com/d/optout.
>
--
Rach Belaid
Flat 9 240B Amhurst Road, London N16 7UL
Phone : +44 75 008 660 84
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.
