Skip to main content

Model-Action Framework

Let front-ends handle views.

This is the time we break up MVC and make it more practical. We are going to focus on back-end without view concerns. There are deeper issues regarding the broader concerns of the model, view and controller. The three-point idea cannot be so simple. The reality is more complicated. Now without view, we are going to slice model and controller into smaller applicable concerns. Views should not be handled from the back-end. We are threshing the view concern from the back-end altogether.

First of all, look at the plethora of front-end frameworks concerning views. Why do model and controller not catching up? Because model and controller are invisible to the naked eyes. Because users can decide on the looks and feels of an application. Because users have no idea and do not care on how data are being handled. Thus, due to the absence of users at the back-end, there is no pressure at all for developers to really pursue on improving model and controller.

The model-action framework is not a deviation from MVC. It is focusing on a set of concerns within MVC more thoroughly, specifically regarding the model and partially on the controller. A model cannot simply be an object as in the object-relational mapping (ORM). Object and model are two different things. A model is more abstract and semantic such as a user, a permission, a shop, a product, a cart, etc. It is never a good idea to simply wrap a model into a programming object. In fact, from the relational database theory, ORM itself is a bad idea. ORM is a quick and dirty database work that most front-end users do not understand and do not care. Unfortunately, we can still live with ORM as long as it works.

Whenever we use an application we always act on a model or more. I.e., user signs-in, shop shows offerings, cart checkouts, etc. Hence, there is a model-action pattern. Both model and action are abstract. They need to be mapped into the actual programming codes. We can make coding simpler when we slice them into model-actions. Always work on a model-action concern at a time. Two different model-actions are two different concerns.

A model can be sliced into many unique concerns where each is representing a unique action. I.e. user signs-up, user signs-in, user signs-out, user cancels, user changes-password, user changes-profile, etc. Every model-action needs a controller. The model-action framework involves controller. A controller is mapping an abstract model-action into a programmable expectation. How the controller handles it is a different concern. The controller may work with ORM, relational database, or nosql. The controller may work with complex algorithm or AI. The controller may look up somewhere else on the Internet. However, the result from a controller must satisfy the model-action concern. Similarly upstreaming, a model-action is satisfying the view concern from the front-end. Unfortunately, all existing back-end MVC frameworks are handling it in a very awkward way.

In the model-action framework, controllers satisfy the actions of models. An individual controller scope is kept small but not necessarily simple. However, there is a preset-controller-toll pattern which slices controller concerns into even smaller generalized cross-cutting concerns. A preset is a piece of code that run before and across controllers. A preset slices out some general concerns across controllers. There can be a chain of presets where each is handling a smaller unique generalized concerns across controllers. Some uses for presets are access control and logging. And a toll is a piece of code that run after and across controllers. A toll behaves almost similarly to a preset but on a totally different set of cross-cutting concerns. Some uses for tolls are watchdogs and filters. A controller is sandwiched between presets and tolls, where the controller delegates generalized concerns to them. Hence, the individual controller concerns becomes smaller.


The model-action framework and the preset-controller-toll pattern are not just theories. Harubi implements them.





Comments

Popular posts from this blog

Setting Up PyScripter for Quantum GIS

PyScripter is a general purpose Python Integrated Development Environment (IDE). Quantum GIS (QGIS) is a desktop GIS application that can be extended with Python plugins. Both are open source softwares. We intend to use PyScripter as an IDE to build QGIS Python plugin. We are using PyScripter 2.4.1.0 and QGIS 1.6.0 in Windows. PyScripter does not come with Python. On the other hand, QGIS is built in with Python. Thus, we will setup up PyScripter to use the build in Python in QGIS. We assume both PyScripter and QGIS are already installed. Preparing PyScripter batch file We assume that QGIS is installed in C:\OSGeo4W\ folder and PyScripter is installed in C:\Program Files\PyScripter\ . 1. Copy qgis.bat in C:\OSGeo4W\ bin to pyscripter.bat 2. Edit pyscripter.bat to remove the last line that read something like this start "Quantum GIS" /B "%OSGEO4W_ROOT%"\apps\qgis\bin\qgis.exe %* and replace it with this in one line Start "PyScripter" /B "C:\Progr...

Using React in Foundation for Sites

This post was the precursor to the Foundation-React Template . React and Foundation are two different web UI frameworks addressing different needs. They evolve differently. Both of them are powerful on their own accord. Fusing them together may create superpower. We will walk through the process of adding React into Foundation. We will start by installing both Foundation and React through command line interface (CLI). Then we will create a simple Todo web app. Along the way we will highlight the development process. But before all that, let us summarize React and Foundation. The details can be found at their respective websites. Both of them are well documented. React is a run-time UI rendering engine. It renders dynamic UI elements in its own fast virtual DOM, and only update necessary changes to the slow browser DOM. This behaves like a  double buffering DOM which makes any UI update feels fast. React wraps a UI rendering script in a component. A React component can ...

Debugging PHP using Apache Error Log

PHP runs on the server side and behaves like a function that return a value against the given arguments. A remote client may call this function and expect a specified return value and nothing else. So how do we debug this function ? It must not return debugging messages since the client is never designed to handle them. We must never burden any client to handle debugging messages. If we run PHP through Apache server then we can use the error log to keep our debugging messages. It may not be the best way to do it. But we only want to talk about this approach now. Error Logs The Apache error log files generally can be found in the following directory: var/log/apache2 We issue the following command from within the directory to read the latest error messages: # tail error.log The tail command reads the last few lines from the error.log file and prints them on the terminal. If we need to read a specific number of lines from the end of the file then we can specify the -n opti...