From cfe108b2cb285bfe08de7ba83a7820a19844bb01 Mon Sep 17 00:00:00 2001 From: Aldo Mateli Date: Tue, 5 Sep 2023 17:00:53 +0100 Subject: [PATCH] Docs update --- docs/pages/automatic_registration.md | 7 ++----- docs/pages/interfaces.md | 8 ++++---- docs/pages/manual_configuration.md | 6 +++--- docs/pages/multiple_containers.md | 14 ++++++++++++++ 4 files changed, 23 insertions(+), 12 deletions(-) diff --git a/docs/pages/automatic_registration.md b/docs/pages/automatic_registration.md index e7dcc58..b66bc1e 100644 --- a/docs/pages/automatic_registration.md +++ b/docs/pages/automatic_registration.md @@ -1,10 +1,7 @@ # Automatic Registration -The examples show the use of `@container.register` to mark each service. -However, if all of them reside in a few select modules then it is possible to automatically register -all of them, eliminating the need for the decorator. - -To achieve that you can use `container.regiter_all_in_module(module, pattern = "*")` method. +In addition to using `@container.register` to register each service automatic registration is also possible by +calling the `container.regiter_all_in_module(module, pattern = "*")` method. Module represents the top level module containing all your services, optionally a `fnmatch` pattern can be specified to only register classes that match the pattern. This does not support registering interfaces. diff --git a/docs/pages/interfaces.md b/docs/pages/interfaces.md index 0fe1097..d5f3684 100644 --- a/docs/pages/interfaces.md +++ b/docs/pages/interfaces.md @@ -1,11 +1,11 @@ # Working with Interfaces -When you're autowiring services, you might want to inject an interface rather than directly -using the concrete implementation. Since Python doesn't have built-in interfaces, -you can leverage any class that's marked as abstract within the container. +When you're autowiring services, you might want to inject an interface rather than +the concrete implementation directly. Since Python doesn't have built-in interfaces, you can leverage any class +that's marked as abstract within the container. The following code registers `Engine` as an interface. This implies that `Engine` can't be directly injected. -Instead, you need another service that inherits from it, and that service must also be registered in the container. +Instead a service which will implement the interface must be present and also be registered in the container. ```python @container.abstract diff --git a/docs/pages/manual_configuration.md b/docs/pages/manual_configuration.md index 52ae418..4acb1be 100644 --- a/docs/pages/manual_configuration.md +++ b/docs/pages/manual_configuration.md @@ -7,12 +7,12 @@ If you want to avoid using decorators for registration, please refer to [Automat Given that parameters can't be resolved from type annotations alone, the `container.wire` method offers two shortcuts for parameter injection: `wire(name="")` and `wire(expr="")`. -To achieve the same outcome without relying on default values, you can actively employ the container's +To achieve the same outcome without relying on default values, you can use the container's initialization context. This allows you to manually provide data that the library would otherwise gather from the decorators. ```python -container.register_all_in_module(app.services) +container.register_all_in_module(app.services, "*Service") # Register parameters individually using add_param container.initialization_context.add_param( @@ -23,7 +23,7 @@ container.initialization_context.add_param( container.initialization_context.add_param( klass=DbService, argument_name="connection_str", - parameter_ref=TemplatedString("${cache_dir}/${USER}/db"), + parameter_ref=TemplatedString("${cache_dir}/${auth_user}/db"), ) # Alternatively, you can update the context in bulk using a dictionary of initializer parameter names as keys diff --git a/docs/pages/multiple_containers.md b/docs/pages/multiple_containers.md index e69de29..3b54182 100644 --- a/docs/pages/multiple_containers.md +++ b/docs/pages/multiple_containers.md @@ -0,0 +1,14 @@ +# Multiple Containers + +As each container has its own state and does not modify the underlying classes, use of multiple containers is possible. +A few things to keep in mind when using multiple containers. + +* The default `wireup.container` is simply an instance just like any other. +* If a service belongs to multiple containers you can use decorators on them, but it is preferable you manage +register services without the decorators. +* To wire parameters use initialization context or the `wire` method. The `wire` method is not bound to any single +container but merely provides hints as to what should be injected. These hints can be read by any container +when calling autowire. +* Use of `@autowire` decorator with multiple containers is unsupported. To bind parameters and services to a method +call `instance.autowire(fn)()`. The autowire method will return a function where all the arguments that the container +knows about are passed. \ No newline at end of file