Architecture Overview

9 views Markdown

One request enters. One dispatcher decides whether it is a page or a mutation, and the answer comes back as HTML or as JSON. Everything else is a layer serving that sentence.

Overview

WISECP is a custom MVC framework, not a general-purpose one wearing a costume. It has controllers, models and views in the usual sense, plus two pieces of its own. Operations are the only way data changes. Hooks are how anyone outside the core takes part.

Reading a feature usually means reading four files. The controller answers the address and the model fetches the rows. The template turns them into markup, and the operation trait changes them. Once that shape is familiar the codebase stops being large and starts being repetitive, which is the point.

Structure

The Request Flow

one request
index.php
  └─ bootstrap.php   constants, autoloader, configuration, session, language
      └─ Bootstrap::run()   address -> route -> controller file + params
          └─ {controller}->index(), or ->main() when there is no index()
              ├─ the request carries `operation`  -> operation method -> JSON
              └─ anything else                    -> page_{name}()    -> HTML

The fork in the middle is the thing to remember. The operation name is read from the request, not from the verb, so either verb can carry it. What it decides is that no page will be built. A request that names an operation never produces a page, and a page method never writes. That separation makes permissions, demo mode and error formatting decidable in one place instead of in every screen.

The Layers

Router Turns an address into a controller and its parameters. Routes are translated per language, so the same page has a different path in each one.
Controllers The base every controller extends. It loads the matching model, exposes the view, collects the data a template will receive and dispatches operations.
Models The base every model extends. Database access lives here and nowhere above it.
View Picks the template directory and builds the output from a template and the collected data.
Operation The object handed to an operation method. It carries the demo guard, the hook helper and the JSON response.
Hook The extension surface. Modules, themes and installation-level rules all attach here.

Three Surfaces, One Application

The admin panel, the public website with the client area, and the scheduled command line all run the same core. They differ in which controllers answer, which templates are used and which session is in play. A helper written for one is available to the others. That is why business rules belong in helpers rather than in a controller.

Pitfalls

The admin and client sides are separate code paths

They often do the same thing through different files. A change made on one side is not automatically true on the other. When you fix a behaviour, check whether its twin exists elsewhere.

Queries belong in the model

A query written in a controller or a template works. Later it becomes the reason a page cannot be reused, cached or called from the command line. Put it in the model even when it is one line.

Was this helpful?

Thanks for your feedback!

Still Need Help?

Our support team is here around the clock for anything you can't find above.