bindmethod on our
appcontainer. In a service provider, that will look like:
providersdictionary in the container. The dictionary after this call will look like:
Requestobject and can be retrieved by:
Markdownclass into the container but really don't care what the key binding is called. This is a great reason to use simple binding which will set the key as the object class:
Requestclass and put it into our controller. All controller methods are resolved by the container. Masonite 2.1 only supports annotations resolving by default:
Requestclass and will actually retrieve that class from the container. Masonite will search the container for a
Requestclass regardless of what the key is in the container, retrieve it, and inject it into the controller method. Effectively creating an IOC container with dependency injection. capabilities Think of this as a get by value instead of a get by key like the earlier example.
Uploaddrivers inherit from the
UploadContractwhich simply acts as an interface for all
Uploaddrivers. Many programming paradigms say that developers should code to an interface instead of an implementation so Masonite allows instances of classes to be returned for this specific use case.
randomFunctionand retrieve them from the service container. There probably won't be many times you'll have to resolve your own code but the option is there.
swapmethod which will be returned instead of the object being resolved. For example this is used currently when resolving the
on_resolve. All we need for the first option is the key or object we want to bind the hook to, and the second option will be a function that takes two arguments. The first argument is the object in question and the second argument is the whole container.
on_make, the function is ran.
Requestobject itself is made from the container. Notice everything is the same except line 6 where we are using an object instead of a string.