Blesta 3.0: Designing A Modular System

There are two prevailing factors that determine how well a software product can adapt, improve, and be extended without imploding in on itself. They are:

1. Coupling, and
2. Cohesion

Coupling represents how dependent a given module is on other modules within the system (I use the term “module” in this article in an abstract sense to describe an object or set of objects that are designed to accomplish some task). A loosely coupled module doesn’t rely or expose much of its inner workings to other modules. Conversely, a tightly coupled module relies heavily on other modules and may expose portions of its inner workings so that other modules may interact with it.

Version 3 of Blesta is built on top of an MVC (Model-View-Controller) framework, which, as the name suggests, separates control into three distinct areas. Building off of an MVC framework (in our case, minPHP) gives us the discipline needed to maintain a loosely coupled system. But it’s not without its challenges. For example, as I’ve mentioned in a previous article explaining data validation, error handling can be handled in a number of ways, but the best way is this through message passing. This allows the errors of a model to be accessed and interpreted without the controller having any direct knowledge of the model or how it works, and vice versa, thus maintaining a loosely coupled relationship.

Cohesion relates to how well the various functional elements of a module are related. High cohesion requires that the module be, in a sense, single-minded. In other words, a class may have high cohesion if all of its methods are closely related. Low cohesion means that a module attempts to accomplish too many tasks, or relates to multiple distinct sets of data.

When designing a modular system, we strive for high cohesion because it improves readability and comprehension of a particular module. If a module attempts too much it becomes bloated, disorganized, and difficult to maintain.

This works hand in hand with coupling. As each module becomes more refined it generally becomes more independent, or loosely coupled. A perfect example of this is the payment gateway system in version 3, which consists of four merchant gateway interfaces (Credit Card, ACH, off-site Credit Card, and off-site ACH). Each interface is designed to accomplish a distinct set of actions (high cohesion), and each payment gateway is thereby only associated with the rest of the system through the implemented interfaces (low coupling). This allows us to create a wide variety of payment gateways that can process credit cards only, or ACH payments only, or any other combination of interfaces without requiring any changes to any other parts of the system.

Blesta 3.0: Full Featured ACL (video)

ACLs (Access Control Lists) allow refined control over resources in Blesta v3. There are a few notable differences in the way ACLs are implemented in Blesta vs other applications.

1. Plugins can easily register resources into the permission system to be controlled within the Staff Groups settings page for seamless integration.
2. The permission system automatically ties into the primary and secondary navigation elements, so even custom controllers can take advantage of the ACL.
3. The ACL library can be invoked directly for even more refined control. You can design your own hierarchy of permissions and explicitly deny or allow any resource.

In this video, I touch on some of the basics. The ACL currently has 87 resources, but we’ll likely have over 100 in the initial release for the core. The Order and Support plugins will add to that.

Blesta 3.0: Smarter i18n

i18n, or internationalization, is the process of adapting software to be deployed around the world. Since version 1.0 we’ve dedicated a large portion of our time to making Blesta an international product. And in version 3 we’ve gone even further by enhancing our multi-language support.

To start, you’ll notice language definitions are now diffused across multiple files. This serves two purposes. First, it promotes congruency between objects and their associated language (each Controller and Model has its own language file). Secondly, it allows us to load only content that is relative to the resource being requested. This saves memory, speeds up load times, and makes development much easier.

Syntax support has also been greatly improved. Previous versions supported tag replacement, but many phrases and sentences were graphed or concatenated together. This meant that some translations were left with incorrect syntax or awkward phrasing. We were able to do away with that thanks to minPHP‘s Language support.

Here’s an example, flashing a success message after having saved a staff group:

<?php
// Success
$this->flashMessage("message", Language::_("AdminSystemStaff.!success.group_updated", true, $this->post['name']));
$this->redirect($this->base_uri . "settings/system/staff/groups/");
?>

Here’s the related language definition:

$lang['AdminSystemStaff.!success.group_updated'] = "The staff group, %1$s, has been successfully updated!";

And the visual result:

In addition, version 3 offers automatic fall-back language support in the case of missing definitions.

And finally, we’re introducing translation support for modules, gateways, plugins, and widgets. Everything is translatable. Let’s see how long it takes the competition to catch on.

Blesta 3.0: AJAX events with browser state updates

In this developer commentary, I give an in depth look at how AJAX events are handled in version 3 and how you can include them in your own widgets or plugins.

The technology employed here allows us to seamlessly update the state of the browser when performing AJAX requests. This permits the user to navigate using the browser’s back and forward buttons while at the same time offering backward compatibility with normal requests for the same resource.

The context of this video is technical in nature and best suited for viewers with a strong understanding of PHP, minPHP, javascript, and jQuery.

Click the icon in the bottom right of the video player to go full screen.

Blesta 3.0: Data Validation

Blesta 3 offers a huge collection of programming tools for developers. From encryption to session handling, and everything in between. Today we’ll focus on the ins and outs of input validation using the Input component packaged with minPHP.

Input validation in version 3 is clear, concise, and modular. Rules reside within the business logic (the model). The benefit of this design is three fold:

1. No (or at least reduced) redundancy
2. Increased readability/writability
3. Reduced testing/less bugs

Some may argue the benefits of input validation from the first source (i.e. the controller). The folly of this design is its complexity and redundancy. Suppose a client can sign up through an order form, through a signup form, or be created by a staff member. Now you have three locations to test, update, and debug each time a business rule changes (for example, phone number is now required). Now suppose you need clients to be created through an API. Adding a fourth set of rules is just plain silly. A client is a client, regardless of where they originate, so why not consolidate all of this?

“Well, Cody,” you might say, “a phone number is only required when a client places an order so we need separate rules.” Hogwash! Add a parameter to your Clients::add() method to identify a signup via order to set the phone number rule as required.

Let’s look at a few examples.

<?php 
// /app/models/clients.php
class Clients extends AppModel {
    public function __construct() {
        Loader::loadComponents($this, array("Input"));
    }
 
    public function add(array $input) {
        // Input is coming straight from POST
        $rules = array(
            'first_name' =--> array(
                'empty' => array(
                    'rule' => "isEmpty",
                    'negate' => true,
                    'message' => $this->_("Clients.!error.first_name.empty"),
                    'post_format' => "trim"
                )
            ),
            'last_name' => array(
                'empty' => array(
                    'rule' => "isEmpty",
                    'negate' => true,
                    'message' => $this->_("Clients.!error.last_name.empty"),
                    'post_format' => "trim"
                )
            ),
            'email' => array(
                'format' => array(
                    'rule' => "isEmail",
                    'message' => $this->_("Client.!error.email.format"),
                    'post_format' => "trim"
                )
            )
        );
 
        $this->Input->setRules($rules);
        if ($this->Input->validates($input)) {
            // Insert into the database, email, or do anything else needed when a client is added
        }
    }
}
?>

Let’s break this down.

1. Line 5 loads the Input component (in reality this is already done in AppModel, but you ought to know how it happens)
2. Lines 10 – 34 define our rules. For those who’ve worked with cakePHP this will look somewhat familiar.
3. Lines 11, 19, and 27 are the indexes of the input data from our input array parameter. Evaluating arrays would look something like ‘addresses[]’, or ‘addresses[][city]‘, etc.
4. Lines 12, 20, and 28 begin individual rule sets. The labels here are superfluous (we could use numerically indexed elements instead), but these help us understand what’s expected of the rule. Any number of rule sets can be added.
5. Each rule contains two necessary components:
   1. The ‘rule’ index, and
   2. The ‘message’ index
6. The first defines how the input is evaluated. If the rule returns true the validation passes, if false, the validation fails. The message is what’s set for the error upon failure. In this example, and throughout Blesta, messages are language definitions which are translated before being set ($this->() maps to [Language::()]3).
7. Lines 14 and 22 tell the “isEmpty” rule to negate the response. Obviously we don’t want to require first and last names to be empty. Instead we want to ensure non-emptiness.
8. Lines 16, 24, and 31 perform a formatting action on data after the rule is evaluated. Conversely, there’s a ‘pre_format’ action that formats the data before the rule is evaluated. Both ‘pre_action’ and ‘post_action’ work just like ‘rule’.
9. Line 36 prepares the rules for evaluation
10. Line 37 runs the validation, setting any errors that are encountered into the Input object, accessed via Input::errors(). AppModel defines a public method called “errors” to grant access to these errors from our controllers. As you’ve probably deduced, Input::validates() returns boolean true if validation was a success and false otherwise.

In the above example, all of the rules are defined within the Input component, but rules can consist of PHP functions (as seen on line 16), callbacks, or even boolean values. In addition, a rule can also define parameters. In any case, however, the first parameter to the rule is always the input value.

Below we look at an example of a rule set where the phone number is conditionally dependent on a method parameter, with a more complex rule.

<?php
    if ($order_signup) {
        $rules['phone'] = array(
            'format' => array(
                'rule' => array(array($this, "isPhone"), $input['country']),
                'if_set' => true,
                'message' => $this->_("Client.!error.phone.format"),
                'final' => true
            )
        );
    }
?>

Notice we now have a couple new actions. The ‘if_set’ action allows the rule to be executed if and only if the field is set. The ‘final’ action tells us that if this rule does not pass evaluation then there’s no point in evaluating any other rules. Similarly, there’s another action called ‘last’ that will cease evaluating rules within a particular rule set (that is, for a single field).

Our rule is to execute a public class method and pass an additional parameter which will help us determine the correct format for the phone number based on the country. The signature of Clients::isPhone would look something like this:

public function isPhone($number, $country)

As you’ve seen, the Input component allows us to reuse code (one of the main goals behind object oriented programming), reduce redundancy, and create readable rules quickly and easily.