I’m using the MVC architecture Laravel 4.2 to create a relatively complex web application. This application consists of a website which is very heavily based on whether an event has occurred or will occur. i.e. if an event is in the future, I will be displaying a countdown, whereas if it is in the past, I will be displaying information about it.
Overall, about 50% of the entire “page” markup may be unique depending on whether it has occurred or will occur.
My question is, should I be using a large if statement inside the view to display what I want based on its future/past occurrence (Yes! Otherwise you will be violating DRY with duplicated markup) or should I create a view which contains the markup for future events and another view which contains the markup for past events and get my controller to route to the applicable view (Yes! Views should be dumb and display & routing logic should be left to the controller).
What would be the correct choice in this situation, or more appropriately what questions could I ask myself to help me determine the best approach to take to this in the future?
2
While views shouldn’t contain business logic, they still can contain basic conditional logic, loops, etc.
Since your website is “very heavily based on whether an event has occurred or will occur”, this is definitively a case where you’ll have two views, not one.
What questions could I ask myself to help me determine the best approach to take to this in the future?
What you should ask yourself is whether each view corresponds to a page, as it would be defined by a person who don’t know anything about the internal workings of a website.
-
For example, a list of products and the details of a product are logically two pages, and so you’ll find two views.
Internally, it may correspond to a single AJAX request which retrieves all info about all the products. Or in order to display the details of a product, you may be doing a dozen AJAX requests to different APIs. What matters is that non-technical persons will see it as a page which shows a list of products and a page which shows the details.
-
On the other hand, a list of products ordered by a price and a list of products ordered by a name feel more like a single page, and will probably correspond to a single view.
Since the notion of pages is itself not very precise, you may also be guided by how much change is there between two views:
-
If two views are sharing no more than a header and a footer, there are chances they should remain separate.
-
If two views are practically a copy-paste with only a tiny part being different, they should be merged in a single view with an
if/elsestatement. -
In between, the choice remains rather subjective.
Note that having two different views doesn’t necessarily lead to code duplication (or rather markup duplication in this case). Most view/template engines have:
-
Master views, which enable for a given template to inherit from a master template which contains the surrounding markup,
-
Partial views, which enable for a given template to embed markup from another template, markup which can this way be shared between several views.
I’ve never used Laravel, so I’m not 100% sure this will work for you, but one method I’ve used in the past is to include either a list or an optional value in my viewmodel that contains the name of another model to render and the data to put there. The view then iterates over the list/checks for presence of the value and includes the appropriate view definition.