Web:Extend can be used as an MVC framework. We implemented a derivative of the original MVC design. The biggest difference is the use of a passive view. As you will soon understand, the architecture is very simple, with the various components being loosely coupled and modifiable easily without any effect on other components.
The main advantage of this architecture is that it enforces the separation of the output, of the data access layer and of the application's processes. You probably already heard that you shouldn't mix HTML and PHP code? Well it's the same kind of separation.
Under this architecture, the output is handled by the view, the data access layer is handled by the domain model and the application's processes are handled by the controller.
With Web:Extend, when a page is accessed by a browser, the request is redirected to the bootstrap file. This file is the entry point for all pages used by your application. It loads the framework and sends the request directly to the controller. The request is then translated and an event is generated from it. The event is then sent to another part of the controller: the frame. Frames are where you write the application's controller code and handle or respond to the events received.
Depending on the event, you might have to send data to the domain model, retrieve data from it and send it to the view; or you might simply have to perform some calculations and send them directly to the view. There's no restriction. You don't have to use models if you don't need them, nor do you have to send output back if you don't need to.
Here's a simplified diagram of the data flows occurring in the framework:
MVC data flow
As you can see, the domain model stores or retrieves data; the controller receives, queries or sends data; and the view only receives data.
By using this simple architecture there is very few dependencies between the different parts of your application. There is at most 2 dependencies: the controller depends on the domain model and on the view. There is no dependency at all between the domain model and the view, as evidenced by this diagram:
MVC dependencies
The main advantages to this (besides simplicity) are that the domain model and the view can be tested independently. You need however to use mock objects to test the Controller itself. But you'll find out that most of the time the operations performed by the controller are very, very simple.