MySource Matrix Developer

A Primer to the Paint Layout Asset

In The Beginning: Before Paint Layouts

Before Paint Layout assets were created, control of assets was solely controlled by a printBody() function within the asset. This meant that asset interfaces needed to be created, and maintained, by a developer – or another user with knowledge of PHP and the MySource Matrix framework. This made styling assets daunting for teams or individuals specializing in implementation or design, but with limited development skills.

This fixing of the front-end interface also made displaying these assets inflexible. For example, customising the front-end presentation of a core asset – such as a user, without any further requirement for custom attributes – would have required a custom asset to be created as an extension of that core asset, with the only difference being a custom printBody() function. Also, some data – such as metadata – cannot be relied upon to exist on all assets, and therefore cannot be included in a fixed front-end interface.

The printBody() function is important to provide a default interface, particularly for core assets, however it should not be the only way to be able to define an interface for an asset type.

How Do Paint Layouts Fit Into the Matrix?

The place of Paint Layouts in the MySource Matrix architecture is best looked at when taken in conjunction with Designs. These two assets control different parts of painting a page: Designs are used to customise the layout of the page at a high level – everything around the asset being painted – whereas Paint Layouts are used to customise the painting of the asset itself.

In assets that list other assets (such as Asset Listing Page), Paint Layouts are also taken into account when painting the body of assets (using the keyword in the applicable type format). If this is not desired, a keyword is also available to paint the default body of an asset, ignoring any Paint Layouts that would otherwise apply to the asset.

Different URLs, Different Views

Paint Layouts allow different "views" of the same asset – assets can be presented in different ways when accessed from different URLs or locations within the asset hierarchy. This is an important difference to Design inheritance, which works on an asset basis.

Conditional Keywords and Branching

An advanced feature of Paint Layouts is the ability to include simple “IF-THEN-ELSE” style branching inside a type format, based on the value of a certain keyword. These branches are defined using special keywords in the type format of the Paint Layout asset, and the branch taken depends on whether that keyword would evaluate to Boolean TRUE or FALSE.

This feature is written primarily with branches depending on the state of the system in mind – such as whether a user is logged into the system or not. To facilitate this, a system of what are known as Conditional Keywords is available on a type format level. These allow you to define keywords that will return TRUE or FALSE depending on whether a certain condition is met.

For example, say you wanted a section of your page viewable to only users in your intranet, which uses a certain range of IP addresses. You can set up a Conditional Keyword based on the User IP Condition, and enter the ranges of IP addresses to grant access to. A Conditional Keyword branch can then be added to the type format, and the private section of the page can then be added to the "true" branch.

Handling Multiple Asset Types in a Folder

Paint Layouts can handle formats for multiple asset types (as well as a "catch-all" default format) – similar to the display formats used in Asset Listing pages. This allows you to style many different types of assets in a tree, while only having to apply the Paint Layout once. The Paint Layout is then inherited to lower-level URLs – similar to how Design inheritance works – and formats are applied to all assets in that tree.

Giving Presentation to Data-Only Assets

One practical use of Paint Layouts is in presenting custom assets whose sole purpose is to represent an item of data. In the case of this type of asset, paint layouts allow the ability to separate content and business logic – which are contained within the asset - from presentation. Instead of placing a complicated front-end interface into the printBody() function by the developer, the interface can be defined using a Paint Layout and then applied to assets.

The advantages of this to the implementer are tremendous. Previously, when a change needed to be made to a custom asset, the implementer was required to delve into the code for that asset and edit the printBody() – or ask a developer to do so, if the implementer lacked knowledge of the underlying PHP language. With Paint Layouts, the assets' presentation can be defined exclusively through the MySource Matrix administration interface – with not much more complexity than editing a standard page! Much of the logic can also be added from the administration interface, by using Paint Layouts in conjunction with conditional keywords.

(Note that in most cases, especially with assets intended for the core or a commercial package, it is still advisable to provide the ability to an asset to "paint itself" by providing a printBody() function. This default presentation can then be overridden by a Paint Layout.)

Conclusion

So, as can you see, Paint Layouts are a remarkably powerful tool for making assets paint the way you want. Yet I’ve only just scratched the surface as to the power of this flexible asset – there are many other ways you can use this asset. For example, you could turn an otherwise lifeless folder or user group into an FTP-style listing of its children with nest content cells and asset listings. The style used in the Paint Layout can then be applied consistently throughout a site or part of the hierarchy. For many, this may be a preferred solution compared to using Standard Pages or Asset Listings as parents.