Multiple registrations and best fit

[pauleveritt]

Hynek and I come from a system (Pyramid) with a registry that allows multiple registrations for an interface. Want to get the IView when the context is an Invoice and the request_method is POST? No problem. Got a custom criteria? Register with a lambda and it will affect the choice.

I have a DI system built around this. I’m eager to re-home it on svcs but that idea isn’t present. I could maybe fake it by registering a dispatcher factory with my registry of implementations but that seems to be fighting the framework.

Is it worth discussing?

[hynek]

Currently the way I do things like this is registering a new type for the same type.

But, not in this web terms (view=x, method=y) but semantically. In your case: what is the difference in the IView you want? I don't think it's a great idea to move these web concepts into the registry like get(IView, request.method).

I think separation of concerns makes sense to dispatch this in the view. So, something like get({"GET": IReadFoo, "POST": IWriteFoo}[request.method]). IReadFoo and IWriteFoo can be both just NewType("IReadFoo", IFoo).

My general gut feeling about Pyramid in hindsight is that it maybe got too many ideas from Zope and having fully-fledged application frameworks that also do some web.

That said, I think there's something somewhere about passing arguments to get().

edit here's the relevant docs: https://svcs.hynek.me/en/stable/core-concepts.html#multiple-factories-for-the-same-type

[pauleveritt]

Doing it in the view won’t really help as it is part of a component system. You can replace a sub component, on just part of the site, etc.

I could probably shoehorn part of the registration information into svcs but I’d be keeping other registration info on the side.

I don’t necessarily agree that these are web-only concepts. Faassen showed with Reg and Michael with wired that these can be general. But I accept the conclusion that that’s not a svcs direction.

[pauleveritt]

I came up with a clever idea (gross hack) that seems to work, and might be better than my system. Here's a gist.

Like Pyramid, my thing has a configuration step where it collects registrations. It uses Venusian. So I have all the data to register, before registering.

Some of these registrations don't depend on request "context" or "path". Those go into the svcs.Registry.

For each request/transaction, make a container, make a request object, put it in the container.

Then, scan the registrations for those that (a) depend context and/or path and (b) match the request context/path. The highest matching registration, gets added via container.register_local_factory to override site-wide registration.

This means I don't need a svcs facility to locate the best service. I move that work to container creation.