Decorating models (legacy)

This is legacy documentation for model decoration 1.0! View the current documentation here.

Introduction to model decoration

Model decoration is a way to split a single model definition into multiple files. The goal is to ease the burden of maintaining large code bases by modularizing a model class. This permits the usual Outlast Framework workflow of modularized plugins to seamlessly work together.

Unlike standard OOP extending, decoration will add feature to the original model definitions rather than creating a separate model class. Any time you interact with the model, you will continue to use the original model name.

In Outlast Framework, model decoration is very similar to the Categories feature in Objective C.

The benefits of decoration

Let’s assume we have a project where we want to add a few fields to the User model.

We could just copy over everything from the plugin to the app level (app hierarchy would result in that the /app/model/user.model.php file is more important than /plugins/user/model/user.model.php) and modify the full user model. The downside of this approach is that if we make any modification at a later date to the plugin version (such as fixing bugs, adding new methods, fields, or features) these features would be overwritten by the app-level copy of the User model and would thus be ignored.

We could also use standard OOP extend. But in this case we have to define a new class and each time we refer to the child class, we have to actually use the name of the child class. This breaks modular code.

With Outlast Framework model decoration, we take the original User model (such that all features, methods, and fields of the plugin-level model file are preserved) and we simply add a few additional features at the app-level. All modular code on the plugin- or system-level will continue to function as before, without modification.

Creating your first decoration

Here are the steps to creating a model decorator:

  • Create a new file at the app level. The file name needs to be the same as the original model file name, so in our example /app/model/user.model.php
  • Unlike standard model classes (which extend zajModel), decorations need to extend zajModelExtender
  • At the end of your model class, you need to specify which model you are decorating, in our example SampleUser::extend('User', 'User');. Most often, both parameters will be identical.
  • Review supported and unsupported features below. Model decoration is still in beta.

Now let’s take a look at our example:

Supported and unsupported features

Decoration is still in beta. This means that certain features are available, others are not.

What you can do:

  • add fields by defining them in the __model method
  • add any number of static methods
  • add model events and even override them by using MyModel::stop_propagation()

What you can not do:

  • instance (non-static) method are not supported
  • instance (non-static) variables are not supported
  • you cannot call the parent method from a child static method
Outlast Web & Mobile Development (c) 2021 | Privacy Policy |