Views

Views
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
1
<html>
2
  <body>
3
    <h1> Hello {{ 'world' }}</h1>
4
  </body>
5
</html>
Copied!
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
1
$ python craft view hello
Copied!
This will create a template under resources/templates/hello.html.
Calling Views
The View class is loaded into the container so we can retrieve it in our controller methods like so:
app/http/controllers/YourController.py
1
from masonite.view import View
2
​
3
def show(self, view: View):
4
    return view.render('dashboard')
Copied!
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
1
$ pip install package-dashboard
Copied!
and then be directed or required to return one of their views:
app/http/controllers/YourController.py
1
def show(self, view: View):
2
    return view.render('/package/views/dashboard')
Copied!
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:
1
package/
2
  views/
3
    __init__.py
4
    index.html
5
    dashboard.html
6
setup.py
7
MANIFEST.in
8
...
Copied!
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
1
def show(self, view: View):
2
    return view.render('/package/dashboard')
Copied!
will perform an absolute import for your Masonite project. For example it will locate:
1
app/
2
config/
3
databases/
4
...
5
package/
6
  dashboard.html
Copied!
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
1
def show(self, view: View, request: Request):
2
    return view.render('dashboard', {'id': request.param('id')})
Copied!
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
1
<html>
2
  <body>
3
    <h1> {{ id }} </h1>
4
  </body>
5
</html>
Copied!
View Syntax
Views use Jinja2 for it's template rendering. You can read about Jinja2 at the official documentation here.
Masonite also enables Jinja2 Line Statements by default which allows you to write syntax the normal way:
1
{% extends 'nav/base.html' %}
2
​
3
{% block content %}
4
    {% for element in variables %}
5
        {{ element }}
6
    {% endfor %}
7
​
8
    {% if some_variable %}
9
        {{ some_variable }}
10
    {% endif %}
11
​
12
{% endblock %}
Copied!
Or using line statements with the @ character:
1
@extends 'nav/base.html'
2
​
3
@block content
4
    @for element in variables
5
        {{ element }}
6
    @endfor
7
​
8
    @if some_variable
9
        {{ some_variable }}
10
    @endif
11
​
12
@endblock
Copied!
The choice is yours on what you would like to use but keep in mind that line statements need to use only that line. Nothing can be after after or before the line.
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.
1
from masonite.view import View
2
​
3
wsgi = False
4
​
5
...
6
​
7
def boot(self, view: View):
8
    view.add_environment('dashboard/templates')
Copied!
By default the environment will be added using the PackageLoader Jinja2 loader but you can explicitly set which loader you want to use:
1
from jinja2 import FileSystemLoader
2
from masonite.view import View
3
...
4
wsgi = False
5
​
6
...
7
​
8
def boot(self, view: View):
9
    view.add_environment('dashboard/templates', loader=FileSystemLoader)
Copied!
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:
1
def show(self, view: View):
2
    view.render('dashboard.user.show')
Copied!
if you want to use a global view you still need to use the first /:
1
def show(self, view: View):
2
    view.render('/dashboard.user.show')
Copied!
Helpers
There are quite a few built in helpers in your views. Here is an extensive list of all view helpers:
Request
You can get the request class:
1
<p> Path: {{ request().path }} </p>
Copied!
Static
You can get the location of static assets:
If you have a configuration file like this:
config/storage.py
1
....
2
's3': {
3
  's3_client': 'sIS8shn...'
4
  ...
5
  'location': 'https://s3.us-east-2.amazonaws.com/bucket'
6
  },
7
....
Copied!
1
...
2
<img src="{{ static('s3', 'profile.jpg') }}" alt="profile">
3
...
Copied!
this will render:
1
<img src="https://s3.us-east-2.amazonaws.com/bucket/profile.jpg" alt="profile">
Copied!
CSRF Field
You can create a CSRF token hidden field to be used with forms:
1
<form action="/some/url" method="POST">
2
    {{ csrf_field }}
3
    <input ..>
4
</form>
Copied!
CSRF Token
You can get only the token that generates. This is useful for JS frontends where you need to pass a CSRF token to the backend for an AJAX call
1
<p> Token: {{ csrf_token }} </p>
Copied!
Current User
You can also get the current authenticated user. This is the same as doing request.user().
1
<p> User: {{ auth().email }} </p>
Copied!
Request Method
On forms you can typically only have either a GET or a POST because of the nature of html. With Masonite you can use a helper to submit forms with PUT or DELETE
1
<form action="/some/url" method="POST">
2
    {{ request_method('PUT') }}
3
    <input ..>
4
</form>
Copied!
This will now submit this form as a PUT request.
Route
You can get a route by it's name by using this method:
1
<form action="{{ route('route.name') }}" method="POST">
2
    ..
3
</form>
Copied!
If your route contains variables you need to pass then you can supply a dictionary as the second argument.
1
<form action="{{ route('route.name', {'id': 1}) }}" method="POST">
2
    ..
3
</form>
Copied!
or a list:
1
<form action="{{ route('route.name', [1]) }}" method="POST">
2
    ..
3
</form>
Copied!
Another cool feature is that if the current route already contains the correct dictionary then you do not have to pass a second parameter. For example if you have a 2 routes like:
1
Get('/dashboard/@id', '[email protected]').name('dashboard.show'),
2
Get('/dashhboard/@id/users', '[email protected]').name('dashhboard.users')
Copied!
If you are accessing these 2 routes then the @id parameter will be stored on the user object. So instead of doing this:
1
<form action="{{ route('dashboard.users', {'id': 1}) }}" method="POST">
2
    ..
3
</form>
Copied!
You can just leave it out completely since the id key is already stored on the request object:
1
<form action="{{ route('dashboard.users') }}" method="POST">
2
    ..
3
</form>
Copied!
Back
This is useful for redirecting back to the previous page. If you supply this helper then the request.back() method will go to this endpoint. It's typically good to use this to go back to a page after a form is submitted with errors:
1
<form action="/some/url" method="POST">
2
    {{ back(request().path) }}
3
</form>
Copied!
Now when a form is submitted and you want to send the user back then in your controller you just have to do:
1
def show(self, request: Request):
2
    # Some failed validation
3
    return request.back()
Copied!
Old
The request.back() method will also flash the current inputs to the session so you can get them when you land back on your template. You can get these values by using the old() method:
1
<form>
2
  <input type="text" name="email" value="{{ old('email') }}">
3
  ...
4
</form>
Copied!
Session
You can access the session here:
1
<p> Error: {{ session().get('error') }} </p>
Copied!
Learn more about session in the Session documentation.
Sign
You can sign things using your secret token:
1
<p> Signed: {{ sign('token') }} </p>
Copied!
Unsign
You can also unsign already signed string:
1
<p> Signed: {{ unsign('signed_token') }} </p>
Copied!
Encrypt
This is just an alias for sign
Decrypt
This is just an alias for unsign
Config
This allows you to easily fetch configuration values in your templates:
1
<h2> App Name: {{ config('application.name') }}</h2>
Copied!
Optional
Allows you to fetch values from objects that may or may not be None. Instead of doing something like:
1
{% if auth() and auth().name == 'Joe' %}
2
    <p>Hello!</p>
3
{% endif %}
Copied!
You can use this helper:
1
{% if optional(auth()).name == 'Joe' %}
2
    <p>Hello!</p>
3
{% endif %}
Copied!
DD
This is the normal dd helper you use in your controllers
Hidden
You can use this helper to quickly add a hidden field
1
<form action="/" method="POST">
2
    {{ hidden('secret' name='secret-value') }}
3
</form>
Copied!
Exists
Check if a template exists
1
{% if exists('auth/base') %}
2
    {% extends 'auth/base.html' %}
3
{% else %}
4
    {% extends 'base.html' %}
5
{% endif %}
Copied!
Cookie
Gets a cookie:
1
<h2> Token: {{ cookie('token') }}</h2>
Copied!
Url
Get the URL to a location:
1
<form action="{{ url('/about', full=True) }}" method="POST">
2
​
3
</form>
Copied!
Jinja2
Below are some examples of the Jinja2 syntax which Masonite uses to build views.
Line Statements
It's important to note that Jinja2 statements can be rewritten with line statements and line statements are preferred in Masonite. In comparison to Jinja2 line statements evaluate the whole line, thus the name line statement.
So Jinja2 syntax looks like this:
1
{% if expression %}
2
    <p>do something</p>
3
{% endif %}
Copied!
This can be rewritten like this with line statement syntax:
1
@if expression
2
    <p>do something</p>
3
@endif
Copied!
It's important to note though that these are line statements. Meaning nothing else can be on the line when doing these. For example you CANNOT do this:
1
<form action="@if expression: 'something' @endif">
2
​
3
</form>
Copied!
But you could achieve that with the regular formatting:
1
<form action="{% if expression %} 'something' {% endif %}">
2
​
3
</form>
Copied!
Whichever syntax you choose is up to you.
Variables
You can show variable text by using {{ }} characters:
1
<p>
2
    {{ variable }}
3
</p>
4
<p>
5
    {{ 'hello world' }}
6
</p>
Copied!
If statement
If statements are similar to python but require an endif!
Line Statements:
1
@if expression
2
    <p>do something</p>
3
@elif expression
4
    <p>do something else</p>
5
@else
6
    <p>above all are false</p>
7
@endif
Copied!
Using alternative Jinja2 syntax:
1
{% if expression %}
2
    <p>do something</p>
3
{% elif %}
4
    <p>do something else</p>
5
{% else %}
6
    <p>above all are false</p>
7
{% endif %}
Copied!
For Loops
For loop look similar to the regular python syntax.
Line Statements:
1
@for item in items
2
    <p>{{ item }}</p>
3
@endfor
Copied!
Using alternative Jinja2 syntax:
1
{% for item in items %}
2
    <p>{{ item }}</p>
3
{% endfor %}
Copied!
Include statement
An include statement is useful for including other templates.
Line Statements:
1
@include 'components/errors.html'
2
​
3
<form action="/">
4
​
5
</form>
Copied!
Using alternative Jinja2 syntax:
1
{% include 'components/errors.html' %}
2
​
3
<form action="/">
4
​
5
</form>
Copied!
Any place you have repeating code you can break out and put it into an include template. These templates will have access to all variables in the current template.
Extends
This is useful for having a child template extend a parent template. There can only be 1 extends per template:
Line Statements:
1
@extends 'components/base.html'
2
​
3
@block content
4
    <p> read below to find out what a block is </p>
5
@endblock
Copied!
Using alternative Jinja2 syntax:
1
{% extends 'components/base.html' %}
2
​
3
{% block content %}
4
    <p> read below to find out what a block is </p>
5
{% endblock %}
Copied!
Blocks
Blocks are sections of code that can be used as placeholders for a parent template. These are only useful when used with the extends above. The "base.html" template is the parent template and contains blocks, which are defined in the child template "blocks.html".
Line Statements:
1
<!-- components/base.html -->
2
<html>
3
    <head>
4
        @block css 
5
        <!-- block named "css" defined in child template will be inserted here -->
6
        @endblock
7
    </head>
8
​
9
<body>
10
    <div class="container">
11
        @block content
12
        <!-- block named "content" defined in child template will be inserted here -->
13
        @endblock
14
    </div>
15
​
16
@block js
17
<!-- block named "js" defined in child template will be inserted here -->
18
@endblock
19
​
20
</body>
21
</html>
Copied!
1
<!-- components/blocks.html -->
2
@extends 'components/base.html'
3
​
4
@block css
5
    <link rel=".." ..>
6
@endblock
7
​
8
@block content
9
    <p> This is content </p>
10
@endblock
11
​
12
@block js
13
    <script src=".." />
14
@endblock
Copied!
Using alternative Jinja2 syntax:
1
<!-- components/base.html -->
2
<html>
3
    <head>
4
        {% block css %} 
5
        <!-- block named "css" defined in child template will be inserted here -->
6
        {% endblock %}
7
    </head>
8
​
9
<body>
10
    <div class="container">
11
        {% block content %} 
12
        <!-- block named "content" defined in child template will be inserted here -->
13
        {% endblock %}
14
    </div>
15
​
16
{% block js %}
17
<!-- block named "js" defined in child template will be inserted here -->
18
{% endblock %}
19
​
20
</body>
21
</html>
Copied!
1
<!-- components/blocks.html -->
2
{% extends 'components/base.html' %}
3
​
4
{% block css %}
5
    <link rel=".." ..>
6
{% endblock %}
7
​
8
{% block content %}
9
    <p> This is content </p>
10
{% endblock %}
11
​
12
{% block js %}
13
    <script src=".." />
14
{% endblock %}
Copied!
As you see blocks are fundamental and can be defined with Jinja2 and line statements. It allows you to structure your templates and have less repeating code.
The blocks defined in the child template will be passed to the parent template.