Views in Masonite are a great way to return HTML in your controllers. Views have a hierarchy, lots of helpers and logical controls, and a great way to separate out your business logic from your presentation logic.
By default, all templates for your views are located in the templates
directory. To create a template, simply create a .html
file inside this directory which we will reference to later.
Then inside your controller file you can reference this template:
The first argument here is the name of your template and the second argument should be a dictionary of variables you reference inside your template.
If you have a template inside another directory you can use dot notation to reference those template names
View sharing is when you want a variable to be available in all templates that are rendered. This could be the authenticated user, a copyright year, or anything else you want shared between templates.
View sharing requires you to add a dictionary:
Then inside your template you can do:
You will typically do this inside your app Service Provider (if you don't have one, you should create one):
Similiar to view sharing, view composing allows you to share templates between specific templates
You may also pass a list of templates:
You will typically do this inside your app Service Provider (if you don't have one, you should create one):
There are quite a few built in helpers in your views. Here is an extensive list of all view helpers:
You can get the request class:
You can get the location of static assets:
You can create a path to an asset by using the asset
helper:
this will render a URL like this:
See your filesystems.py configuration for how how to set the paths up.
You can create a CSRF token hidden field to be used with forms:
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
You can also get the current authenticated user. This is the same as doing request.user()
.
This will now submit this form as a PUT request.
You can get a route by it's name by using this method:
If your route contains variables you need to pass then you can supply a dictionary as the second argument.
or a list:
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:
Now when a form is submitted and you want to send the user back then in your controller you just have to do:
You can access the session here:
Learn more about session in the Session documentation.
This allows you to easily fetch configuration values in your templates:
Gets a cookie:
Get the URL to a location:
To help in debugging, you can use the dd()
helper
Jinja2 allows adding filters to your views. Before we explain how to add filters to all of your templates, let's explain exactly what a view filter is.
Filters can be attached to view variables in order to change and modify them. For example you may have a variable that you want to turn into a slug and have something like:
In Masonite, this slug filter is simply a function that takes the variable as an argument and would look like a simple function like this:
That's it! It's important to note that the variable it is filtering is always passed as the first argument and all other parameters are passed in after so we could do something like:
and then our function would look like:
Adding filters is typically done inside your app Service Provider (if you don't have one, you should create one):
View tests are simply custom boolean expressions that can be used in your templates. We may want to run boolean tests on specific objects to assert that they pass a test. For example we may want to test if a user is an owner of a company like this:
In order to do this we need to add a test on the View
class. We can once again do this inside the app Service Provider
The code is simple and looks something like this:
That's it! Now we can use the a_company_owner
in our templates just like the first code snippet above!
Notice that we only supplied the function and we did not instantiate anything. The function or object we supply needs to have 1 parameter which is the object or string we are testing.
Environments in views are directories of templates. If you are development packages or building a modular based application, you may have to register different directories for templates. This will allow Masonite to locate your views when referencing them to render. A good place to do this is inside a service provider's register method.
There are 2 separate kinds of loaders.
The first loader is a "package" loader. This is used when registering a package. To do this you can simply register it with the package module path. This will work for most directories that are packages.
The other loader is a FileSystem
loader. This should be used when the directory path is NOT a module but rather just a file system path:
Below are some examples of the Jinja2 syntax which Masonite uses to build views.
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:
This can be rewritten like this with line statement syntax:
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:
But you could achieve that with the regular formatting:
Whichever syntax you choose is up to you.
Note that if you are using an
@
symbol that should not be rendered with Masonite then this will throw an error. An example being when you are using@media
tags in CSS. In this case you will need to wrap this statement inside `` and `
` blocks.
You can show variable or string text by using {{ }}
characters:
If statements are similar to python but require an endif!
Line Statements:
Using alternative Jinja2 syntax:
For loop look similar to the regular python syntax.
Line Statements:
Using alternative Jinja2 syntax:
An include statement is useful for including other templates.
Line Statements:
Using alternative Jinja2 syntax:
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.
This is useful for having a child template extend a parent template. There can only be 1 extends per template:
Line Statements:
Using alternative Jinja2 syntax:
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:
Using alternative Jinja2 syntax:
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.