Inherited views

When we are using MVC frameworks only view layer does

not correspond to the OO principles

What frameworks give us from the box

• view rendering

• partial rendering

• support of helper methods

Biggest disadvantage of the view layer

• does not support unit testing

Disadvantages of helpers

• do not allow inheritance

• methods are calling without a receiver

• collision between helpers with similar methods

We can replace helpers to decorators and improve

presentation logic

Advantages of decorators

• allow inheritance

• allow encapsulation

• friendly for unit testing

• does not mutate decorated object

• does not change the behavior of decorated object

Decorators has advantages over helpers

But decorators are not developed for view layer

View Componentsnext generation of view layer

Cellsview-model layer

Advantages of ‘cells’

• basically a small MVC stack

• own render engine

• OOP features

• separate presentation from the view logic

Benefits for application structure

• slim controllers

• clear views

• maintainability

When do we need such approach?

Cells applicable for

• layouts

• generic views

• complex view logic

• widgets

Simple example

Typical situation

• duplicated views for some UI part

• each view can render specific partials

• each partial can build specific content

Every new case expects change of current condition

state and file structure

Somebody should maintain this stuff

To avoid this painful we can use the power of

components

Defining base logic

Defining base partials

Inheriting our component

Customizing our partials

Calling our component

Conclusions

• separated from presentation logic

• easy maintenance

• test coverage

• isolated dependencies

–Valentyn Ostakh

Thanks!

Questions?