print Proposal: change to MVC system

The complete re-build of the CLI layer was an interesting project and the result is a far superior system for building CLI apps (in my opinion). Part of this success was a conserted effort to avoid directly accessing the cliRequest object or other singleton objects. The apps are largely built through composition instead of the previous inheritance based approach.

A distinct advantage of coding the CLI layer in this way, was being able to attach the application to the request allowing cliCommands to re-route back to the main app or to other commands within the app.

What has this to do with the MVC layer?

Well, one thing I have never been comfortable with is the way that the mvcRequest instance is used. Whenever it is needed, the instance if requested and then used. Generally in the scorpio MVC system, the request is not modified it is only read from, but really it should be being passed as a parameter to each controller and then (if and only if needed) to the model etc. By attaching it to the controller as a parameter, the view would automatically have access, all without needing to call mvcRequest::getInstance().

Changing this would allow testing of the various components with mocked mvcRequest objects and make the interfaces neater.

This change, however, would require changing the mvcControllerBase interface and the start-up mechanism. A simpler change would be to add the request at launch time by delaying the call to initialise() so instead of that happening at __construct() it is deliberately called. The later method would allow a slower change over without breaking all existing controllers.

Another change is to refactor the methods controlling autoloading, files and file locations. They are currently split between mvcDistributorBase, mvcAutoload and mvcSiteConfig. All are inter-related and it is a rather confusing setup. This should be re-factored to move all file locations to mvcAutoload, after all distributor does not need to know about files, loading or locations. The one method that will cause the most problems in this refactoring will be getTemplateFile(). That is used to locate the template file in a site and should be moved to mvcTemplateBase. mvcAutoload would still need mvcSiteConfig to be able to handle the routing (it needs the site chain).

Finally, mvcDistributor sets several properties in the request. These should be moved out to the request. This change is the least likely to break the system as the assignment is handled transparently to the user.

There are no plans currently to add any of these changes to the 0.2, except perhaps the mvcRequest update.

<  1  >