Masonite Documentation
v1.6
v1.6
  • Introduction
  • Prologue
    • Introduction and Installaton
    • Contributing Guide
    • How To Contribute
    • Release Cycle
    • Known Installation Issues
  • What's New
    • Masonite 1.3
    • Masonite 1.4
    • Masonite 1.5
    • Masonite 1.6
  • Upgrade Guide
    • Masonite 1.3 to 1.4
    • Masonite 1.4 to 1.5
    • Masonite 1.5 to 1.6
  • The Basics
    • Routing
    • Controllers
    • Views
    • Requests
    • Static Files
    • Helper Functions
  • The Craft Command
    • Introduction
    • Creating Commands
    • Authentication System
  • Architectural Concepts
    • Request Lifecycle
    • Service Providers
    • Service Container
  • Advanced
    • Middleware
    • Validation
    • Creating Packages
    • Extending Classes
    • Creating a Mail Driver
    • Sessions
  • Useful Features
    • Template Caching
    • Mail
    • Uploading
    • View Composers and Sharing
    • Caching
    • Broadcasting
    • Queues and Jobs
    • Compiling Assets
    • Framework Hooks
  • Security
    • Authentication
    • Encryption
    • CSRF Protection
  • Orator ORM
    • Basic Usage
    • Query Builder
    • ORM
    • Pagination
    • Schema Builder
    • Database Migrations
    • Collections
  • Managers and Drivers
    • About Managers
    • About Drivers
    • Contracts
  • Official Packages
    • Masonite Entry
    • Masonite Billing
  • Creating Your First Blog
    • Introduction
    • Part 1 - Creating Our First Route
    • Part 2 - Creating Our First Controller
    • Part 3 - Authentication
    • Part 4 - Migrations
    • Part 5 - Models
    • Part 6 - Designing Our Blog
    • Part 7 - Showing Our Posts
    • Part 8 - Updating and Deleting Posts
Powered by GitBook
On this page
  • Introduction
  • Creating Views
  • Calling Views
  • Helper Function
  • From The Container
  • Global Views
  • Global View Caveats
  • Template Location
  • Extending Views
  • Passing Data to Views
Edit on Git
Export as PDF
  1. The Basics

Views

PreviousControllersNextRequests

Last updated 7 years 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 resources/templatesdirectory.

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 recommended 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 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
def show(self, View):
    return View('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.

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.

Global View Caveats

Template Location

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
...

and not inside the package directory. This is a Jinja 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 a relative import for your Masonite project. For example it will catch:

app/
config/
databases/
...
package/
  dashboard.html

So if you are making a package for Masonite then keep this in mind in where you should put your templates

Extending Views

When you extend a view, you are isolated to the directory you are in when you want to extend templates and you're view namespace loses it's globalization and all extending should be done relative to the current template. For example, if you have a package with a directory structure like:

package/
  controllers/
    PackageController.py
  templates/
    __init__.py
    index.html # needs to inherit base.html
    base.html
setup.py
MANIFEST.in
...

And a controller like:

package/controllers/PackageController.py
def show(self):
    return view('/package/templates/index')

You will have to extend your template like so:

package/templates/index.html
<!-- This is right -->
{% extends 'base.html' %}

{% block content %}
    ... index.html code goes here ...
{% endblock %}

and not extend your template with another global view:

package/templates/index.html
<!-- This is wrong -->
{% extends '/package/templates/base.html' %}

{% block content %}
    ... index.html code goes here ...
{% endblock %}

Passing Data to Views

A lot 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):
    return view('dashboard', {'id': Request.param('id')})

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>

If this looks weird to you or you are not sure how the container integrates with Masonite, make sure you read the documentation

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 documentation.

Helper Functions
Service Container
Service Container