Chris Abernethy . com» Zend Framework

Extracting Translatable Strings From Zend_Validate

Brownoxford — Thu, 24 Apr 2008 01:05:59 +0000

Recently I started working with Zend Framework's Zend_Form and its integrated automatic translation functionality using Zend_Translate. In general, the functionality is really great, but if you have ever tried to translate all of the possible validation error messages, you know that finding them can be a long manual task. Naturally, I brought this up on #zftalk, and the consensus seemed to be that the translatable messages could be extracted using a little PHP and ReflectionClass magic.

ReflectionClass to the Rescue

The following is the script that I came up with, which pulls translatable error messages along with available message variables and generates a data structure based on the class name of the validators. Here is the script in its entirety, with some short comments describing how it works:

$zend_library = "/my/php/library";
set_include_path($zend_library);

// Create a new RecursiveDirectoryIterator for the Zend_Validate
// directory and recursively iterate over the files.

$messages = array();
$rdi = new RecursiveDirectoryIterator($zend_library . '/Zend/Validate');
foreach (new RecursiveIteratorIterator($rdi) as $path) {

    // Read in the file and generate the expected class name by
    // converting the portion of the path starting with Zend/Validate
    // and replacing '/' with '_'. For example, this converts the path
    // Zend/Validate/Regex.php to Zend_Validate_Regex.

    require_once($path);
    $class = strtr(preg_replace('#.*(Zend/Validate/.*)\.php$#', '\1', $path), '/', '_');

    if (class_exists($class)) {

        // If the expected class exists, create a ReflectionClass
        // instance and fetch the properties of the class. Make
        // sure that the property '_messageTemplates' exists, as
        // this indicates that we are dealing with an actual concrete
        // Zend_Validate class.

        $reflection = new ReflectionClass($class);
        if ($reflection->hasProperty('_messageTemplates')) {

            // Get the default properties as an associative array and
            // add the 'value' key to the _messageVariables property
            // since by default, 'value' is always available for substitution
            // into a message template.

            $props = $reflection->getDefaultProperties();
            $props['_messageVariables']['value'] = true;

            // Add an element to the $messages array, keyed on
            // the name of the current class. The element contains
            // an array of translatable templates, and an array of
            // valid message variables that can be substituted into
            // those templates.

            $messages[$class] = array(
                'templates' => $props['_messageTemplates']
              , 'variables' => array_keys($props['_messageVariables'])
            );
        }
    }
}

Printing out an element of the $messages array shows the structure that is now available to work with, which brings us to the next step... what can we do with this data?

print_r($messages['Zend_Validate_Regex']);

Array
(
    [templates] => Array
        (
            [regexNotMatch] => '%value%' does not match against pattern '%pattern%'
        )
    [variables] => Array
        (
            [0] => pattern
            [1] => value
        )
)

Processing the Output

Now we have the data that we need to start providing translations, what can be done with it? I am using the Zend_Translate_Tmx translation adapter, so I iterate over the data and write out a single TMX 1.4 format file for all of my validation error translations (including some notes regarding the source of the translatable string as well as the possible variables that can be used). The following code illustrates how this is done:

$format = '
        
            Validation message template for class %s.
            Possible variables include %s
            
                %s
            
        
';

echo <<


    
    
    
XML;

foreach ($messages as $class_name => $data) {
    $variables = join(', ', $data['variables']);
    foreach ($data['templates'] as $key => $template) {
        printf($format, $key, $class_name, $variables, $template);
    }
}

echo "    \n"
  .  "\n";

The collected data can of course also be formatted in whatever way is required by the type of Zend_Validate_Adapter that you are using.

Hopefully this will save you some time in your translation efforts. One thing to watch out for is that several validators re-use messageTemplate identifiers and so cannot be translated (see bug ZF-3164 for more info).

Benchmarking Zend Framework Routes

Brownoxford — Fri, 11 Jan 2008 03:34:51 +0000

Hanging out in #zftalk on freenode is a great way to learn more about using Zend Framework, if you're not already there get yourself an IRC client and sign on. Recently, the following question was posed:

How can I create a route with an optional parameter; e.g /search/:foo/:bar, where :bar is optional? Do I need to create two different routes?

Several users correctly suggested specifying a default value for :bar when constructing the route, and it was also mentioned that both standard routes and regular expression routes could be used to solve the problem. Naturally, this lead to a discussion of which type of route would be fastest, with no real numbers to fall back on.

The purpose of this article is to present benchmark numbers for both route types (for the specific application described above) and to describe the methods used to run the benchmark tests. This won't be a full tutorial on how to use xdebug or kcachegrind, so I won't go into great details about how to use them, but the full source code for the benchmarks will be available at the end of the article.

Method

In order to profile the different routing options, xdebug was used in profiling mode and the resulting profile data was viewed in kcachegrind. The profiling test uses two URLs, one with the optional parameter and one without. Each router's match() method is called 10000 with each of the two URLs.

The Standard Route

The first route tested was the standard route, which is instantiated with a string describing the route, and an array of default options. The route accepts two parameters, indicated by :foo and :bar. Since a default value is specified for :bar in the initialization array, the route will match both of our test URLs, using the value 'mybar' if no parameter is given for :bar.

$route = new Zend_Controller_Router_Route(
    'search/:foo/:bar'
  , array(
        'controller' => 'search'
      , 'action'     => 'index'
      , 'bar'        => 'mybar'
    )
);

The Regex Route

The next route tested was the regex route, which is instantiated in the same way as the standard route, with the addition of an array that maps parameter positions to value names; this allows the route map the results from an internal preg_match call to the numerically keyed captured parameters.

$route = new Zend_Controller_Router_Route_Regex(
    'search/(\w+)(?:/(\w+))'
  , array(
        'controller' => 'search'
      , 'action'     => 'index'
      , 'bar'        => 'mybar'
    )
  , array(
        'foo' => 1
      , 'bar' => 2
    )
);

The Results

The initial test with 10,000 iterations using the test URL that contained both the foo and bar parameters shows that the standard route is faster than the regex route by about 12%. The image at right is a kcachegrind visualization of the call tree rooted in the function that executes the two tests with a distance limit of 1.

The second test of 10,000 iterations used the test URL with did not contain the bar parameter. It shows that the regex route is significantly faster than the standard route by about 48%.

Based on these tests, it seems like the best choice depends on how often the optional parameter is expected to be provided. If the answer is less than about 60% of the time, the regex route would seem like the best choice; otherwise the regex route will be faster. Keep in mind that this is all based on a specific route, and your situation may vary so if performance is an issue some custom tests may be in order.

If you are interested in reproducing these benchmarks, you can download the benchmarking scripts and customize them as needed.

Migrating to Zend Framework: Legacy Scripts

Brownoxford — Tue, 04 Dec 2007 21:27:25 +0000

Migrating an existing PHP application to Zend Framework can be a daunting task, especially if the migration must occur all at once. It is much easier to migrate the application in sections over a longer period of time. This approach requires some modification from a normal Zend Framework setup, in which all requests for non-existent files are passed to the bootstrap file and dispatched, but all requests for files which do exist (images, css and, in our case, legacy scripts) bypass the bootstrap and are served directly. In our scenario, we want to be able to integrate features of the Zend Framework into the legacy scripts without rewriting them as MVC components, and without having to duplicate code from the bootstrap (ie: in an auto_prepend file).

The following mod_rewrite rules will perform the normal routing of non-existent URIs to the bootstrap, but will also route requests for PHP scripts to the bootstrap (this example assumes that the rewrite rules are specified in a per-directory context):

RewriteEngine   On
RewriteCond     %{REQUEST_FILENAME} !-f    [OR]
RewriteCond     %{REQUEST_FILENAME} \.php$
RewriteCond     %{REQUEST_FILENAME} !-d
RewriteRule     ^(.*)$ /bootstrap.php/$1 [L,NS]

Once legacy scripts are successfully being sent to the bootstrap, we need to modify it so that it does the right thing. The following code checks to see if the current request is for an existing script, and if so that script is served instead of running the front controller dispatch. Any bootstrapping that occurs before this code will be available to the legacy scripts; for example, the Zend_Registry, any config loaded with Zend_Config, Zend_Loader, etc.

$request  = new Zend_Controller_Request_Http();
$docroot = $request->get('DOCUMENT_ROOT');
$uri     = $request->getPathInfo();

if (file_exists($docroot . $uri)) {

    ob_start();
    include $docroot . $uri;

    $response = new Zend_Controller_Response_Http();
    $response->setBody(ob_get_clean());
    $response->sendResponse();

    exit;

}

This approach works well for basic sites, but what happens if you already have mod_rewrite rules in place to create SEO-friendly URLs that redirect to actual scripts? This causes a problem because the value of the actual script is not available to Zend Framework, so the request is very likely to be handled by the default /controller/action route. Consider the following example:

RewriteRule ^/calendar/([0-9a-zA-Z_]+) /view_calendar.php?user_name=$1

As long as this rule appears in your apache configuration prior to the bootstrap routing rules outlined previously, the request for /calendar/someusername will be redirected via an internal subrequest to /view_calendar.php?username=someusername. This operation updates the %{REQUEST_FILENAME} value used by mod_rewrite, so the legacy script matching rule is invoked and this request is handed off to the bootstrap script.

The problem that we run into here, is that the bootstrap script is unaware of the update in URI, and still believes that it is handling a request for /calendar/somuser. Since there is a default routing rule in the front controller for paths matching the format /controller/action, our request is dispatched to a non-existent controller and an error is thrown.

This issue can be avoided by converting the SEO mod_rewrite rules into Zend Framework router rules that route to a custom subclass of Zend_Controller_Action that encapsulates the bootstrap code that we developed earlier for serving legacy scripts. Here is Zend Framework rewrite router implementation of the calendar mod_rewrite rule listed above:

$front  = Zend_Controller_Front::getInstance();
$router = $front->getRouter();
$route  = new Zend_Controller_Router_Route_Regex(
    'calendar/([0-9a-zA-Z_]+)',
    array(
        'controller' => 'legacy',
        'action'     => 'index',
        'script'     => '/view_calendar.php'
    ),
    array(
        1 => 'user_name'
    ),
    'calendar/%s'
);
$router->addRoute('calendar', $route);

In order to handle this route, we need to implement a subclass of Zend_Controller_Action called LegacyController. This class will have a single action called indexAction which is where our legacy script handling code will go:

class LegacyController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
        $viewRenderer->setNoRender(true);

        $request = $this->getRequest();
        $docroot = $request->get('DOCUMENT_ROOT');
        $uri     = '/' . ltrim( $request->getParam('script'), '/' ); // Force leading '/'

        if (file_exists($docroot . $uri)) {
            ob_start();
            include $docroot . $uri;
            $output = ob_get_clean();
            $response = $this->getResponse();
            $response->setBody($output);
            $response->sendResponse();
        } else {
            // You could redirect to a custom 404 handler here.
        }
    }
}

This works great, but now we have some code duplication between the LegacyController and the bootstrap file. To get rid of the duplication, we can add an additional route that forwards requests for php scripts to the LegacyController like this:

$front  = Zend_Controller_Front::getInstance();
$router = $front->getRouter();
$route  = new Zend_Controller_Router_Route_Regex(
    '(.+\.php)',
    array(
        'controller' => 'legacy',
        'action'     => 'index',
    ),
    array(
        1 => 'script'
    ),
    '%s'
);
$router->addRoute('legacy', $route);

This new route allows us to remove the legacy script handling code from the bootstrap file and use the LegacyController for all legacy requests. One item to note is that this rule does NOT provide leading '/' to the value of 'script', which is why the LegacyController must use the '/' . ltrim($script) construct.

Using Module Templates with Zend Framework

Brownoxford — Fri, 30 Nov 2007 20:45:34 +0000

I've just finished watching some of the archived webinars related to Zend Framework over at Zend.com, and found some great information about rendering view output into a sitewide template in the MVC applications with Zend Framework webinar.

Since I'm currently developing a website with multiple modules, each having their own distinct look, I'd like to extend the examples provided in the webinar to allow specifying per-module templates. Here is what I came up with:

First, modify the example to add private member variables $_template and $_module and add a constructor that accepts and stores values for these variables.

class My_Plugin_RenderIntoTemplate extends Zend_Controller_Plugin_Abstract
{
  private $_template = null;
  private $_module   = null;
	
  public function __construct( $template, $module = 'default' )
  {
    $this->_template = $template;
    $this->_module   = $module;
  }

Next, modify the dispatchLoopShutdown() method in the example to add a check that returns immediately if the current module is not the module specified at instantiation time.

  public function dispatchLoopShutdown()
  {

    if( $this->_module != $this->getRequest()->module ) {
      return;
    }

    $view = Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer')->view;
    if (empty($view)) {
      return;
    }

    $response      = $this->getResponse();
    $content       = $response->getBody();
    $view->content = $content;

    $response->setBody($view->render($this->_template));
  }
}

Finally, register instances of the plugin with the front controller in the bootstrap code:

// Set up the Front controller.
require_once 'Zend/Controller/Front.php';
$front = Zend_Controller_Front::getInstance( );

$front->addModuleDirectory( '../application/modules' )
      ->registerPlugin( new My_Plugin_RenderIntoTemplate( 'foo-template.phtml', 'foo' ) )
      ->dispatch( );

In my example, I am using the conventional modular directory structure as outline here. In this case, the script named in the plugin constructor should be located at the application/modules/foo/views/scripts/foo-template.phtml.