Other (simplified) approaches to MVC

I assume you're already familiar with how Jet MVC works. However, I mention in other chapters, so that's not the only way to tackle MVC. Yes, a full deployment of Jet MVC lends itself to a classic complex online application project. It fits as the basis of a potal, an e-shop, or your CMS. That's what it's designed for, and I wouldn't start a new project without it. But if you're making a simple single-purpose tool, it can be all cannon fodder for sparrows.

And you'll find such practical examples right in the sample application package. There's the installer (~/_installer/), profiler output (~/_profiler/), and Jet Studio (~/_tools/studio/). All of these microapplications are actually separate subprojects. This is also the reason why they are not fully built on Jet MVC. Each of these small applications has a precise purpose. And all of them are also MVC, but each one is a bit different. And we're going to show how you can use them to also approach MVC, not have any bases and pages and still have an MVC application built on Jet, and even modular ones at that.

Instead of long theorizing, let's get straight to practical examples.

1. Example - Installer

What is the essence of an installer? It is actually a one page application. It's a single page that changes based on state. That is, the step the user is currently in. This means that we don't need anything like a base and pages for the installer to work.

Another important fact is that the installer is made up of individual steps. The steps are actually additional micro-applications. Steps are actually modules. And we can add steps, remove steps, even solve dependencies in a primitive way.

The whole installer uses forms and UI elements - so we'll need generic view scripts.

The installer has some basic UI layout. True, one common to all steps. Admittedly only one, but it is common. That is, we need a layout.

Each step obviously needs to display its UI and its outputs. So each step needs to have its view.

And of course each step needs to manage its application logic somehow. So that means that the step must have its controller

The entire installer must also have an initialization.

And on top of all that there must be something like a router, but it doesn't control and manage the current page, but the current step of the install.

So there we have an MVC application built on Jet. And the moment ... Where is the Model? The model is for the Jet installer itself, and especially the application setup. So the application configuration is the model, the MVC base of the installed application is the model, and so on.

The installer also has its classes (~/_installer/Classes/), its dictionaries (~/_installer/dictionaries/), and most importantly its modules - so here more precisely steps (~/_installer/Step/)

Although the installer does not use any bases and pages for itself, it uses Jet\MVC_View and Jet\MVC_Layout, which can be and are used separately.

And please refer to the installer sources for further details ;-)

2. Example - profiler output

The output of profiler is the most primitive application.What should it do?

  • Initialize the Jet Profiler
  • Save the run log
  • Show the status bar on the page
  • Show detailed run information
Nothing more ... You don't even need modularity for that. On the contrary, it's supposed to be minimalistic so that it doesn't interfere too much with the running of the project being developed. I mean, scratch modularity, we don't need it.

The model is clear. The role of the model is played by the Jet Profiler and especially the application runtime records compiled by it.

What about Layout? No ... No need. There is certainly no need for a status bar, and the application runtime detail is one output.

A View? It definitely does. View can be used completely on its own, without layout, but it's still the same view scripts as everything else. They're in the ~/_profiler/views/ directory.

What about controller? Yes, of course, we need that one. But there's no need for anything complicated. In fact, a single anonymous class, which you can find in ~/_profiler/views/Controller.php

We have an MVC application built on Jet again, and even an important one for Jet. Completely minimalistic and titular, non-modular, single-purpose, but it still has Model, View and Controller.

3. Example - Jet Studio

Jet Studio is the opposite case. This is already a pretty large application. However, by its very nature, it can't use the full Jet MVC because it's an application that can define and set up bases, create and fully manage pages, operate on modules, and even create modules. Studio does work with Jet and makes full use of it, but at the same time it has to stand on the side, so to speak.

Everything said about the installer applies to Jet Studio. With the crucial difference that it is not a single-purpose, single-page application. No, Jet Studio is made up of several parts. And we actually have modularity again.

Previous chapter
Cache / Cache
Next chapter
Application modules