fix service container links

Author: girardinsamuel

architecture/service-providers.md

@@ -1,4 +1,4 @@
-Service Providers are the key building blocks to Masonite. The only thing they do is register things into the Service Container, or run logic on requests. If you look inside the `config/providers.py` file, you will find a `PROVIDERS` list which contains all the Service Providers involved in building the framework.
+Service Providers are the key building blocks to Masonite. The only thing they do is register things into the [Service Container](service-container.md), or run logic on requests. If you look inside the `config/providers.py` file, you will find a `PROVIDERS` list which contains all the Service Providers involved in building the framework.
 
 Although uncommon, You may create your own service provider and add it to your providers list to extend Masonite, or even remove some providers if you don't need their functionality. If you do create your own Service Provider, consider making it available on PyPi so others can install it into their framework.
 

features/commands.md

@@ -38,11 +38,11 @@ class KeyCommand(Command):
         pass
 ```
 
-Once created you can register the command to Masonite's [Service Container](architectural-concepts/service-container.md) so it will show up in show up when you run `python craft`
+Once created you can register the command to Masonite's [Service Container](../architecture/service-container.md) so it will show up in show up when you run `python craft`
 
 # Registering Commands
 
-To register command you will need to register them against Masonite's [Service Container](architectural-concepts/service-container.md). You can do so in a service provider
+To register command you will need to register them against Masonite's [Service Container](../architecture/service-container.md). You can do so in a service provider
 
 ```python
 from some.place.YourCommand import YourCommand

features/controllers.md

@@ -36,7 +36,7 @@ You may start building your controller out and adding the responses you need.
 
 ## Dependency Injection
 
-Your controller's constructor and controller methods are resolved by Masonite's [Service Container](architectural-concepts/service-container.md). Because of this, you can simply typehint most of Masonite's classes in either the constructor or the methods:
+Your controller's constructor and controller methods are resolved by Masonite's [Service Container](../architecture/service-container.md). Because of this, you can simply typehint most of Masonite's classes in either the constructor or the methods:
 
 ```python
 def __init__(self, request: Request):
@@ -48,7 +48,7 @@ def show(self, request: Request):
   return request.param('1')
 ```
 
-Read more about the benefits of the [Service Container](architectural-concepts/service-container.md).
+Read more about the benefits of the [Service Container](../architecture/service-container.md).
 
 ## Responses
 

prologue/create-a-blog.md

@@ -1,4 +1,4 @@
-This section of the documentation will contain various tutorials. These are guides that are designed to take you from beginning to end on building various types of projects with Masonite. We may not explain things in much detail for each section as this part of the documentation is designed to just get you familiar with the inner workings of Masonite. 
+This section of the documentation will contain various tutorials. These are guides that are designed to take you from beginning to end on building various types of projects with Masonite. We may not explain things in much detail for each section as this part of the documentation is designed to just get you familiar with the inner workings of Masonite.
 
 Since this section of the documentation is designed to just get you up and coding with Masonite, any further explanations that should be presented are inside various "hint blocks." Once you are done with the tutorial or simply want to learn more about a topic it is advised that you go through each hint block and follow the links to dive deeper into the reference documentation which does significantly more explaining.
 
@@ -478,7 +478,7 @@ Now we need to make sure the user is logged in before creating this so let's cha
 {% tab title="templates/blog.html" %}
 
 ```html
-@if auth() 
+@if auth()
     <form action="/blog/create" method="POST">
         {{ csrf_field }}
 
@@ -635,7 +635,7 @@ def store(self, request: Request):
 {% endtab %}
 {% endtabs %}
 
-Notice that we now used `request: Request` here. This is the `Request` object. Where did this come from? This is the power and beauty of Masonite and your first introduction to the [Service Container](architectural-concepts/service-container.md). The [Service Container](architectural-concepts/service-container.md) is an extremely powerful implementation as allows you to ask Masonite for an object \(in this case `Request`\) and get that object. This is an important concept to grasp so be sure to read the documentation further.
+Notice that we now used `request: Request` here. This is the `Request` object. Where did this come from? This is the power and beauty of Masonite and your first introduction to the [Service Container](../architecture/service-container.md). The [Service Container](../architecture/service-container.md) is an extremely powerful implementation as allows you to ask Masonite for an object \(in this case `Request`\) and get that object. This is an important concept to grasp so be sure to read the documentation further.
 
 Also notice we used an `input()` method. Masonite does not discriminate against different request methods so getting input on a `GET` or a `POST` request are done exactly the same way by using this `input` method.
 

prologue/how-to-contribute.md

@@ -8,7 +8,7 @@ This is not an exhaustive list and not the only ways to contribute but they are
 
 ## Contributing to Development
 
-Of course the project requires contributions to the main development aspects but it's not the only way. But if you would like to contribute to development then a great way to get started is to simply read through this documentation. Get acquainted with how the framework works, how [Controllers](broken-reference) and [Routing](../features/routing.md) work and read the [Architectural Concepts](architectural-concepts) documentation starting with the [Request Lifecycle](broken-reference), then the [Service Providers](architectural-concepts/service-providers.md) and finally the [Service Container](architectural-concepts/service-container.md).
+Of course the project requires contributions to the main development aspects but it's not the only way. But if you would like to contribute to development then a great way to get started is to simply read through this documentation. Get acquainted with how the framework works, how [Controllers](broken-reference) and [Routing](../features/routing.md) work and read the [Architectural Concepts](architectural-concepts) documentation starting with the [Request Lifecycle](broken-reference), then the [Service Providers](architectural-concepts/service-providers.md) and finally the [Service Container](../architecture/service-container.md).
 
 It would also be good to read about the [Release Cycle](release-cycle.md) to get familiar with how Masonite does releases (SemVer and RomVer).
 

upgrade-guide/masonite-1.6-to-2.0.md

@@ -74,8 +74,8 @@ Then change the code logic of bootstrapping service providers from:
 ```python
 for provider in container.make('Application').PROVIDERS:
     locate(provider)().load_app(container).register()
-    
-for provider in container.make('Application').PROVIDERS: 
+
+for provider in container.make('Application').PROVIDERS:
     located_provider = locate(provider)().load_app(container)
     if located_provider.wsgi is False:
         container.resolve(locate(provider)().load_app(container).boot)
@@ -86,7 +86,7 @@ to:
 
 {% code title="wsgi.py" %}
 ```python
- for provider in container.make('ProvidersConfig').PROVIDERS: 
+ for provider in container.make('ProvidersConfig').PROVIDERS:
     located_provider = provider()
     located_provder.load_app(container).register()
     if located_provider.wsgi:
@@ -101,7 +101,7 @@ and change the logic in `bootstrap/start.py` to:
 
 {% code title="bootstrap/start.py" %}
 ```python
-for provider in container.make('WSGIProviders'): 
+for provider in container.make('WSGIProviders'):
     container.resolve(located_provider.boot)
 ```
 {% endcode %}
@@ -179,7 +179,7 @@ Simply add a new `AUTOLOAD` constant in your `config/application.py` file. This
 | Autoload Directories
 |--------------------------------------------------------------------------
 |
-| List of directories that are used to find classes and autoload them into 
+| List of directories that are used to find classes and autoload them into
 | the Service Container. This is initially used to find models and load
 | them in but feel free to autoload any directories
 |
@@ -224,10 +224,10 @@ PROVIDERS = [
     ...
     'masonite.providers.RouteProvider',
     'masonite.providers.RedirectionProvider',
-    
+
     # New provider here above StartResponseProvider
     'masonite.providers.StatusCodeProvider',
-    
+
     'masonite.providers.StartResponseProvider',
     'masonite.providers.WhitenoiseProvider',
     ...

whats-new/masonite-4.0.md

@@ -10,7 +10,7 @@ We will attempt here to go through everything new in Masonite 4. This documentat
 
 The foundation of Masonite has changed a lot. The IOC container, service providers and features are all the same but how they are registered and how features work together has changed.
 
-As many of you are familiar, when you maintain any application for several years and you go through requirement changes and scope creap it leads to technical debt. 
+As many of you are familiar, when you maintain any application for several years and you go through requirement changes and scope creap it leads to technical debt.
 
 With Masonite, there were times where I would come into contact with a very large company that wanted to use Masonite that maybe didn't have a feature they needed and I would have to build the feature over the weekend or even during the night. I did this to try to capture the company to use Masonite. Many of those companies did go along with using Masonite but creating features this rapidly tends to lead to poor feature structure. Rapid development of features naturally tends to lead to high coupling of code. High coupling of code tends to lead to more difficult maintanance.
 
@@ -20,9 +20,9 @@ One of the goals of the Masonite 4 release is to have very very low coupled code
 
 One of the downsides to Masonite development was that in the beginning, I had no clue what I was doing. Masonite 1 and Masonite 2 were completely different frameworks but they were built on the same foundation. See the issue?
 
-One of the problems with this is that I thought it would be a great idea to simply make a project inside the Masonite core's code so I can more easily test certain features. The problem with this is that you can't use one of the PIP's most powerful features. Development mode. This is because the Masonite config directory would override the import inheritance. So the alternative with Masonite was to have to uninstall and install it everytime we made a change. This made developing with Masonite a lot longer and harder. 
+One of the problems with this is that I thought it would be a great idea to simply make a project inside the Masonite core's code so I can more easily test certain features. The problem with this is that you can't use one of the PIP's most powerful features. Development mode. This is because the Masonite config directory would override the import inheritance. So the alternative with Masonite was to have to uninstall and install it everytime we made a change. This made developing with Masonite a lot longer and harder.
 
-The tricky part is the only way to solve this issue is making everything in the project configurable. This is where the new Kernel file comes in. So previously we had controllers inside `app/http/controllers`, middleware inside `app/middleware`, etc. 
+The tricky part is the only way to solve this issue is making everything in the project configurable. This is where the new Kernel file comes in. So previously we had controllers inside `app/http/controllers`, middleware inside `app/middleware`, etc.
 
 Now with the Kernel file we register all of our paths in this file. We can then use those registrations to do what we need to do.
 
@@ -34,15 +34,15 @@ The `resources/templates` directory has been removed. This has been replaced wit
 
 # Features
 
-Surpringly, the features in Masonite 4 look almost identical to Masonite 3. There are some new or improved features such as: 
+Surpringly, the features in Masonite 4 look almost identical to Masonite 3. There are some new or improved features such as:
 * A new Notifications feature
 * Improved broadcasting feature to include a new features like private and presence channels as well as easy authentication support.
 * More powerful email support based around Mailable classes.
 * Several packages like Validation and task scheduling have been moved into the core repository from being separate packages.
 
 # Facades
 
-Masonite 4 brings a new concept called facades. Facades are a simple proxy class that call a deeper implementation through Masonite's service container.
+Masonite 4 brings a new concept called facades. Facades are a simple proxy class that call a deeper implementation through Masonite's [Service Container](../architecture/service-container.md).
 
 Here would be the same code, one using auto resolving and one using facades: