MVC architecture and ProcessWire

[JeevanisM]

Hello All,

I would like to know more about ProcessWire and the MVC approach.

1. Does the PW follow Model View Control  guidelines?

2. if yes, where are the Controller / View  / Model separation ?

3. If No, whats the architecture ProcessWire follows ?

[szabesz]

Hello,

Recommend @teppo's module: 

 

[teppo]

2 hours ago, JeevanisM said:

I would like to know more about ProcessWire and the MVC approach.

1. Does the PW follow Model View Control  guidelines?

2. if yes, where are the Controller / View  / Model separation ?

3. If No, whats the architecture ProcessWire follows ?

Just to clarify this a bit:

1. No (out of the box).

3. ProcessWire doesn't enforce any specific architecture on you; instead you can utilise just about any architecture/strategy you want. If you haven't yet had the chance to read https://processwire.com/docs/front-end/output/, I'd suggest checking it out — learning about direct output and delayed output (and their differences) should clear some things up.

As @szabesz pointed out above, there are ways to use MVC (or something very similar) on ProcessWire powered sites/apps. In my opinion MVC is great for a lot of stuff, but as always, by design ProcessWire makes zero assumptions: for some use cases simple direct output approach is quite enough, and makes things more straightforward (to build, but also to maintain) ?

[MoritzLost]

Another perspective: The API acts as the model, with the $page / Page class giving you access to page data through a generic interface. By default, the PHP template file for the current content type / template acts as Controller and View, though you can easily seperate Controller and View by using, for example, a frontend templating library like twig. That's close to my usual setup:

• View: Twig acts as a View layer, since it gets pretty privileged access to API variables, you can get anything done you'd usually do in a PHP View class.
• Controller: The PHP template file acts as the Controller, for example processing input and rendering the correct Twig template. Usually, I just keep the template logic procedural, because ProcessWire already does a lot of work in determining the correct template file and setting up API variables. Though you could also use a custom Controller class and just use the template file to instantiate it.
• Model: As mentioned above, the $page API variable is already a kind of generic model for your data, and for sites that are mostly brochure sites / presentational in nature, this is really all you need. But if you want to go further, you can create custom page classes by extending the Page class and set your template to use that, this way you can make your model as smart as it need to be.

I have written two tutorials on how to integrate Twig if you're interested ?

Part 1: Extendible template structures
Part 2: Custom functionality and integrations

[szabesz]

17 hours ago, MoritzLost said:

• View: Twig acts as a View layer, since it gets pretty privileged access to API variables, you can get anything done you'd usually do in a PHP View class.
• Controller: The PHP template file acts as the Controller, for example processing input and rendering the correct Twig template. Usually, I just keep the template logic procedural, because ProcessWire already does a lot of work in determining the correct template file and setting up API variables. Though you could also use a custom Controller class and just use the template file to instantiate it.
• Model: As mentioned above, the $page API variable is already a kind of generic model for your data, and for sites that are mostly brochure sites / presentational in nature, this is really all you need. But if you want to go further, you can create custom page classes by extending the Page class and set your template to use that, this way you can make your model as smart as it need to be.

I treat things similar to this, except that the separation between "view" and "controller" is created by PW's "Prepend file" feature possible via the template settings. The procedural code of the "controller" is placed into a file article-control.php, for example, while the "view" is in article.php, which is the standard template file with PHP's "alternative" syntax, just as originally intended by Rasmus Lerdorf.

 To keep files organized, I put this into /site/init.php for each template that needs code:

$templates->get('article')->filename = $config->paths->templates . 'pages/articles/article.php';

While the location of the prepended "controller" is set in the admin like this:

pages/articles/article-control.php

This way I can put any article/articles related files into the pages/articles/ directory, and not just these two ones but files like included template partials, JavaScript files only required by article pages, etc.

Edited March 1, 2020 by szabesz
typo

[Craig]

Another loose approach to MVC like the last few posts above, is how I usually do things. Pages API is the model, template files are controllers, and separate files for views:

<?php namespace ProcessWire;

// templates/home.php

region('breadcrumbs', false);

region('content', wireRenderFile('views/home/hero'));
region('content+', wireRenderFile('views/home/testimonials'));
region('content+', wireRenderFile('views/home/benefits'));

$meta['name']['twitter:description'] = $settings->site_tagline;
$meta['property']['og:description'] = $settings->site_tagline;

<?php namespace ProcessWire;

// templates/register.php

require_once("./_forms.php");

$status = processRegisterForm();

if ($status && $status['success']) {
	wire('session')->redirect($page->url . 'success/');
}

$view = [
	'status' => $status,
];

if (wire('input')->urlSegment(1) == 'success') {
	region('pageTitle', 'Registration complete');
	$page->summary = '';
	$viewName = 'views/register/success';
} else {
	$viewName = 'views/register/form';
}

region('content', wireRenderFile($viewName, $view));

wireRenderFile() is an alias of the PW Files API 'render' function and takes a path to a file and an optional array of data/variables. I also use the Markup Regions functionality.

The examples above are taken from this GitHub repo for one of my sites.

[qtguru]

I think the question should be what type of application are you looking to build that requires MVC ? because I find PW appropriate for making proper CMS sites, anything other than that, then you should be using a proper MVC for such, there will be scenarios you will encounter, I doubt you would want to tweak PW to fit uncovered scenario.