Masonite Documentation
v1.5
v1.5
  • Introduction
  • Prologue
    • Introduction and Installaton
    • Contributing Guide
    • How To Contribute
    • Release Cycle
  • What's New
    • Masonite 1.3
    • Masonite 1.4
    • Masonite 1.5
  • Upgrade Guide
    • Masonite 1.3 to 1.4
    • Masonite 1.4 to 1.5
  • 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
  • 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 - Designing Our Blog
    • Part 4 - Migrations
    • Part 5 - Models
    • Part 3 - Authentication
Powered by GitBook
On this page
  • Introduction
  • Getting Started
  • Contracts
Edit on Git
Export as PDF
  1. Managers and Drivers

Contracts

Introduction

Contracts are used when creating drivers to ensure they conform to Masonite requirements. They are a form of interface in other languages where the child class is required to have the minimum number of methods needed for that driver to work. It is a promise to the class that it has the exact methods required.

Contracts are designed to follow the "code to an interface and not an implementation" rule. While this rule is followed, all drivers of the same type are swappable.

Drivers are designed to easily switch the functionality of a specific feature such as switching from file system storage to Amazon S3 storage without changing any code. Because each driver someone creates can technically have whatever methods they want, this creates a technical challenge of having to change any code that uses a driver that doesn't support a specific method. For example a driver that does not have a store method while other drivers do will throw errors when a developer switches drivers.

Contracts ensure that all drivers of a similar type such as upload, queue and mail drivers all contain the same methods. While drivers that inherit from a contract can have more methods than required, they should not.

Getting Started

Contracts are currently used to create drivers and are located in the masonite.contracts namespace. Creating a driver and using a contract looks like:

from masonite.contracts.UploadContract import UploadContract

class UploadGoogleDriver(UploadContract):
    pass

Now this class will constantly throw exceptions until it overrides all the required methods in the class.

Contracts

There are several contracts that are required when creating a driver. If you feel like you need to have a new type of driver for a new feature then you should create a contract first and code to a contract instead of an implementation. Below are the types of contracts available. All contracts correspond to their drivers. So an UploadContract is required to create an upload driver.

BroadcastContract

CacheContract

MailContract

QueueContract

UploadContract

PreviousAbout DriversNextIntroduction

Last updated 7 years ago