ALPHA Framework: Model 2.x … what’s new?

The doubtful variable

First of all I’ve structured with more consistence the template variables.

To understand better what I mean, a variable, before the changes I’ve made, were stored in the template variables array as is.

$theModel = ClassFactory::get('Model');
$theModel->setVar("animal.type","panda");
/*
 * In the Model::$variables array you found exactly the key 
 * "animal.type"  with the "panda" value inside. 
 */ 
$theModel->setVar("animal", array( "name" => "Po") );
/* 
 * Produced the key animal in the $variables static array with a 
 * nested array.

So, the Model, to detect the variable {var:animal.type} or {var:animal.name} and getting the right result, requires an effort not irrelevant, introducing some complexity when we should manage various variable types like objects, numbers, array etc. Again the nesting of the variables is  unlimited. So the combinations to detect the traversing key to reach the right value, increase exponentially. All that means the grown of potential errors and bugs !

Since the changes made in the Version 2.0, I’ve completely refactored the setVar( ) that apparently remain the same but it uses internally the new method createVar( ). The last method receive a generic variable of any type and convert it in an associative array granting a common form for the information stored in the static array $variables.

The above source code now, produces an associative array as follows :

Model::$variables = {
  'animal': {
    'type': ['panda'],
    'name': ['Po']
  }
}

So, when You are using {var:animal.type} the Model Class knows exactly what you are asking for interpreting the above request as:

Model::$variables['animal']['type'][0]; // This will return "panda"

Isn’t it cool, clean, structured and doubt-free?

With that I’ve increased a little bit the amount of memory used, but I’ve reduced the rendering execution time. Bu that’s not all!

Reducing the number of run-time Model instances

After the variable management I’ve worked to reduce in general the usage of memory of the the class Model.

So first of all, let’s understand how the Template Engine works.

1. It takes a CuTeML file and look for plug-ins and process them, replacing the plug-in HTML tags with the requested contents.
2. Then replaces variables, conditional blocks, iterations and other stuffs on the template and at the end output the entire generated HTML.

The plug-in itself is a template file, so, the Model class  was creating an instance and the 2 steps were repeated for each plug-in. This means a lot of memory usage if you are using a lot of plug-in in the template file. And I can assure you that it was too expensive in execution time!

Here comes the first optimizations: now the Model does not create a new instance of itself for each plug-in but uses the same instance storing the current status of variables, then makes what is needed and restore the status of variables. This has reduced a little bit the amount of used memory, but not so many as we have used with the new $variables structure.

Well, excited by this minimal improvement I’ve analyzed each line of code of the class Model and looking for the points where the Model instantiates again itself. The methods that was doing that were:

1. retrieveFromCache()
2. renderPlugin(), Just discussed above.
3. render(),
   1. If a value matches a possible CuTeML syntax
   2. When the template uses the {include:…} command.
   3. In the iteration loop

Well, for all them I’ve applied the same concept previously described: store the Model status, using this instance to process and render the template and restoring the Model status at the end.

The above improvements has grant an increment of performance and a reduction of memory usage balancing the memory used to store the template variables.

Unit Test

Due to a lack of unit test, in the Model we’d find so many calls to the Debug class to log the function entering, function exiting, given parameters for each method and so on. This causes a significant usage of memory to log what we don’t need if we have the certainty that the Model class works fine.

So another effort was made in the development of  Unit Test specific for the class Model.

After I did it, I’ve removed the unuseful Debug calls too gaining a lot of time.

To see the unit test of the Model Class, just type the following URL in your browser:

http://localhost/myFirstApp/?core_info=unit-test&class=model

Where http://localhost/myFirstApp/ is the URL to your Web Application.

This tells the framework to enter in the unit test page and output results for Model class. Further unit test for other classes and updated for the Model Class will come soon!

With all the above changes the Model gains about  the 800% to render a page (almost 8 time faster). If Google didn’t registered the V8 name well I would do it! :-)