Views

Last updated 4 months ago
Introduction
Views contain all the HTML that you’re application will use to render to the user. Unlike Django, views in Masonite are your HTML templates. All views are located inside the resources/templates directory.
All views are rendered with Jinja2 so we can use all the Jinja2 code you are used to. An example view looks like:
resources/templates/helloworld.html
<html>
  <body>
    <h1> Hello {{ 'world' }}</h1>
  </body>
</html>
Creating Views
Since all views are located in resources/templates, we can use simply create all of our views manually here or use our craft command tool. To make a view just run:
terminal
$ craft view hello
This will create a template under resources/templates/hello.html.
Calling Views
Helper Function
There are several ways we can call views in our controllers. The first way is using the view() function. Masonite ships with a HelpersProvider Service Provider. This provider will add several new built in functions to your project. These helper functions can be used as shorthand for several commonly used classes such as the View and Request class. 
See the Helper Functions documentation for more information.
One of the helper functions is the view() function which is accessible like any other built in Python function.
We can call views in our controllers like so:
app/http/controllers/YourController.py
def show(self):
    return view('dashboard')
This will return the view located at resources/templates/dashboard.html. We can also specify a deeper folder structure like so:
app/http/controllers/YourController.py
def show(self):
    return view('profiles/dashboard')
This will look for the view at resources/templates/profiles/dashboard.html
From The Container
The View class is loaded into the container so we can retrieve it in our controller methods like so:
app/http/controllers/YourController.py
from masonite.view import View
​
def show(self, view: View):
    return view.render('dashboard')
This is exactly the same as using the helper function above. So if you choose to code more explicitly, the option is there for you.
If this looks weird to you or you are not sure how the container integrates with Masonite, make sure you read the Service Container documentation
Global Views
Some views may not reside in the resources/templates directory and may even reside in third party packages such as a dashboard package. We can locate these views by passing a / in front of our view.
For example as a use case we might pip install a package:
terminal
$ pip install package-dashboard
and then be directed or required to return one of their views:
app/http/controllers/YourController.py
def show(self):
    return view('/package/views/dashboard')
This will look inside the dashboard.views package for a dashboard.html file and return that. You can obviously pass in data as usual.
Caveats
It's important to note that if you are building a third party package that integrates with Masonite that you place any .html files inside a Python package instead of directly inside a module. For example, you should place .html files inside a file structure that looks like:
package/
  views/
    __init__.py
    index.html
    dashboard.html
setup.py
MANIFEST.in
...
ensuring there is a __init__.py file. This is a Jinja2 limitation that says that all templates should be located in packages.
Accessing a global view such as:
app/http/controllers/YourController.py
def show(self):
    return view('/package/dashboard')
will perform an absolute import for your Masonite project. For example it will locate:
app/
config/
databases/
...
package/
  dashboard.html
Or find the package in a completely separate third part module. So if you are making a package for Masonite then keep this in mind of where you should put your templates.
Passing Data to Views
Most of the time we’ll need to pass in data to our views. This data is passed in with a dictionary that contains a key which is the variable with the corresponding value. We can pass data to the function like so:
app/http/controllers/YourController.py
def show(self, request: Request):
    return view('dashboard', {'id': request.param('id')})
Remember that by passing in parameters like Request to the controller method, we can retrieve objects from the IOC container. Read more about the IOC container in the Service Container documentation.
This will send a variable named id to the view which can then be rendered like:
resources/templates/dashboard.html
<html>
  <body>
    <h1> {{ id }} </h1>
  </body>
</html>
Adding Environments
This section requires knowledge of Service Providers and how the Service Container works. Be sure to read those documentation articles.
You can also add Jinja2 environments to the container which will be available for use in your views. This is typically done for third party packages such as Masonite Dashboard. You can extend views in a Service Provider in the boot method. Make sure the Service Provider has the wsgi attribute set to False. This way the specific Service Provider will not keep adding the environment on every request.
from masonite.view import View
​
wsgi = False
​
...
​
def boot(self, view: View):
    view.add_environment('dashboard/templates')
By default the environment will be added using the PackageLoader Jinja2 loader but you can explicitly set which loader you want to use:
from jinja2 import FileSystemLoader
from masonite.view import View
...
wsgi = False
​
...
​
def boot(self, view: View):
    view.add_environment('dashboard/templates', loader=FileSystemLoader)
The default loader of PackageLoader will work for most cases but if it doesn't work for your use case, you may need to change the Jinja2 loader type.
Using Dot Notation
If using a / doesn't seem as clean to you, you can also optionally use dots:
def show(self, view: View):
    view.render('dashboard.user.show')
if you want to use a global view you still need to use the first /:
def show(self, view: View):
    view.render('/dashboard.user.show')
The Basics - Previous
Static Files
Next - The Craft Command
Introduction