In a previous post I described some of the reasons why you would want to store your session data in an alternate location to temporary files on your server. I explained the setup of database session storage using Doctrine and how this would allow you to take advantage of storing session data in a database. However depending upon your application requirements storing your session data in a database may cause excessive load on you database. You could of course use a separate dedicated database server to store your session data. However there is an alternate setup that will allow you to centralise your session storage ready for horizontal scaling of your hosting e.g. adding additional web servers.

symfony provides a very easy way for you to configure your application to use a number of alternate session storage strategies. In this article I will explain the steps needed to setup your application to use first APC as your session storage and then Memcache. Both of these strategies result in the session data being stored in volatile memory on your server and a cookie is stored on the client to maintain reference to the session data. You can set the lifetime of the cookie to control your session timeout.

Install APC and Memcached modules

First we need to ensure that your server has the required packages installed. I am using Ubuntu 9.04 in this example but the packages are available for your preferred linux distro. To install the required packages run the following commands.

Install the required PHP modules and the correct version of apache to successfully install APC, then install the Pecl APC module.

sudo apt-get install php5-dev php-pear apache2-threaded-dev
sudo pecl install apc

Install memcache

sudo apt-get install memcached

Configure APC session storage

Once you have your server setup with the required packages you need to configure symfony to use your preferred session storage strategy. To do this you simply need to modify the factories.yml file for you application. You need to modify the section of the factories.yml that defines your application storage strategy e.g.

Amend your factories.yml to include the following settings then change the parameters to reflect you setup such as the domain and session name.

all:
  storage:
    class: sfCacheSessionStorage
    param:
      session_name: sfproject #[required] name of session to use
      session_cookie_path: / #[required] cookie path
      session_cookie_domain: example.com #[required] cookie domain
      session_cookie_lifetime: +30 days #[required] liftime of cookie
      session_cookie_secure: false #[required] send only if secure connection
      session_cookie_http_only: true #[required] accessible only via http protocol
      cache: 
        class: sfAPCCache #[required] define the cache strategy
        param: ~ #[required] this empty key is required or you will get warnings

Once you have made this change clear the symfony cache and try your application. You will not see any noticeable difference unless you check the symfony toolbar and look for the additional cookie stored on the client.

This example defines the use of sfAPCCache as the session storage strategy. APC stores the session data in memory on your web server making it quicker to access than reading a file or database record.

Configure Memcache session storage

To setup memcache session storage it is almost as simple. Amend your factories.yml to include the following settings then change the parameters to reflect your setup including any specific values for your memcache server if you set it up differently.

all:
  storage:
    class: sfCacheSessionStorage
    param:
      session_name: sfproject #[required] name of session to use
      session_cookie_path: / #[required] cookie path
      session_cookie_domain: example.com #[required] cookie domain
      session_cookie_lifetime: +30 days #[required] liftime of cookie
      session_cookie_secure: false #[required] send only if secure connection
      session_cookie_http_only: true #[required] accessible only via http protocol
      cache: 
        class: sfMemcacheCache #[required] define the cache strategy
        param:
          servers: # Array of servers
            localserver:
              host: localhost # hostname or IP of mamcache server
              port: 11211 # default memcache port

Once you have made this change clear your symfony cache and test your application.

Memcache is a volatile storage strategy very similar to RAM in you PC or Mac. It is very quick to access as the session data is held in the server memory rather than in a file or database. Memcache can also be centralised onto a dedicated memcache server allowing your application to be scaled. The example above uses localhost as the memcache server but the host value of the configured server could be modified to be an alternate dedicated memcache server.

I will be running some performance tests using these strategies and also compare the default file based session storage and also the database session storage strategy. If you have already run these tests I would be keen to see your results.

I hope these examples prove useful. If you have any queries or questions please leave a comment.

Related Articles

• November 25, 2009 -- symfony Doctrine database session storage
• October 8, 2009 -- Propel doUpdate update multiple records in a single statement

Why use database session management?

Sessions allow you maintain persistence within PHP applications. With every HTTP request a PHP application must re-assign every variable and object needed in your application. Sessions allow you to store data that is required to persist past each HTTP request allowing it to be easily retrieved and used.

Sessions are commonly used when  creating a secure application, used to store the state of a user e.g. if they are logged in or credentials to control access to content.

By storing session data in a database table you are able to create an application interface that will show information about the users that are logged in. This for example could show the number of users logged into the application or show administrators who is logged in.

If you  need to scale your application by adding more than one server, saving your session data in temporary files can lead to major problems. By using database storage you can optimise and unify the session storage, ensuring that session data is always available and consistent.

Obviously there are other solutions for scalable session storage such as APC or MemCache but these solutions are for another post.

How to setup Doctrine database session storage

You first need to add a table to you database schema that will be used to store your session data. Although you can create this table manually, adding it to your scheme also created the model classes that you can later use to interact with the table data.

Session:
  columns:
    id: { type: string(32), primary: true, notnull: true }
    data: { type: string(4000), notnull: true }
    time: { type: integer(4), notnull: true }

Once you have added the table to your schema you can build your model and database:

./symfony doctrine:build-all

You then need to configure your symfony application to use this table to store all session data. To do this you need to modify the factories.yml file for your application. Update your file to include the following lines:

all:
  storage:
    class: sfPDOSessionStorage
    param:
      db_table: session # Name of the table storing the sessions
      db_id_col: id # The primary key column
      db_data_col: data # The column where the session data will be stored
      db_time_col: time # The column where the timestamp of the session will be stored
      database: doctrine # Name of the database connection to use

Once you have modifies your factories.yml file you will need to clear the symfony cache. After that your application should run exactly as it did before except that your users session data will be stored in the database table.

The data column stores all the session data in a serialised form this is deserialized each time a user requests the data. There are many uses for this type of session storage and I hope this brief explanation helps you.

Subscribe to my RSS feed or follow me on twitter to find out about setting up symfony to use APC or MemCache session storage.

Related Articles

• November 30, 2009 -- symfony APC cache and Memcache session storage
• October 8, 2009 -- Propel doUpdate update multiple records in a single statement

YAHOO.util.Event.addListener(forms, 'submit', this._onFormSubmit, this);

_onFormSubmit: function(e, o)
{
  YAHOO>util.Event.preventDefault(e);
  // Set the form
  YAHOO.util.Connect.setForm(e.currentTarget);
  // Configure the callback object
  callBackObj = {
    success: o._loadRemoteFormSubmissionTemplateComplete,
    failure: o._loadRemoteFormSubmissionTemplateFailed,
    argument: {
      objType: objType, 
      region: regionObj,  
      mode: submitbutton.value}
  }
  // Make the request
  YAHOO.util.Connect.asyncRequest('POST', e.currentTarget.action, callBackObj);
}

With non multi-part forms you can hijack the submit event of the form and create an asynchronous request. However once you try with multi-part data no matter how you set this up and attempt to cancel the form submit action the form will still make an HTTP request in the main window.

The YUI Multi-Part Data Solution

The solution is very simple once you find it but it is easy to overlook! In order to use YUI connect to create an asynchronous request you must remove the ‘submit’ button and replace it with a ‘button’ then assign it an eventListener that will create the asyncRequest.

var alternateButton = document.getElementById('alternateButtonId')
YAHOO.util.Event.addListener(alternateButton, 'click', this._onFormSubmit, this);

_onFormSubmit: function(e, o)
{
  YAHOO.util.Event.preventDefault(e);
  // Set the form
  YAHOO.util.Connect.setForm(e.currentTarget);
  // Configure the callback object
  callBackObj = {
    success: o._loadRemoteFormSubmissionTemplateComplete,
    failure: o._loadRemoteFormSubmissionTemplateFailed,
    argument: {
      objType: objType, 
      region: regionObj,  
      mode: submitbutton.value}
  }
  // Make the request
  YAHOO.util.Connect.asyncRequest('POST', e.currentTarget.action, callBackObj);
}

When trying to use multi-part data YUI Connection Manager will create an iframe in the document that your form will submit the data to. If you try and use the submit handler YUI currently does not change the target value of the submit event.

The YUI examples do all show the use of alternate buttons rather than a standard submit button however it can be easily overlooked. I hope this helps someone!

Related Articles

• No Related Post

This task is simple in SQL but after a while using any abstraction layer you may find like me you forget about the simple solutions as you spend you day working with complex objects and trying to hydrate custom objects. Blah blah blah…

The complex solution to a simple problem:

// Obtain the connection configured
$conn = Propel::getConnection(YourObjectPeer::DATABASE_NAME);
// Create a Criteria object that will select the correct rows from the database
$selectCriteria = new Criteria();
$selectCriteria->add(YourObjectPeer::COLUMB_TO_SELECT, 'value_to_match');
// Create a Criteria object includes the value you want to set
$updateCriteria = new Criteria();
$updateCriteria->add(YourObjectPeer::COLUMB_TO_CHANGE, 'value_to_be_set');
// Execute the query
BasePeer::doUpdate($selectCriteria, $updateCriteria, $conn);

Thats it! I hope it helps…

Related Articles

• November 30, 2009 -- symfony APC cache and Memcache session storage
• November 25, 2009 -- symfony Doctrine database session storage

Magento is an Open Source eCommerce platform developed using the Zend Framework by Varien. It is a fabulously customizable and extendible platform that once mastered can allow you to develop feature rich eCommerce solutions for your clients quickly and effectively. However for some mastering the Magento platform may not be that easy.

Magento uses common design patterns such as MVC, Application Controller and Two Step View to structure the application and provide mechanisms to extend and override the functionality and presentation. The platform has a huge number of files and directories that can cause confusion for newcomers to the platform. However this extended folder structure clearly defines where the platforms core files exist and where you can place your custom code and modules. Allowing you to extend the platform without modifying the core and breaking the upgrade process.

However daunting the platform appears or skeptical you may be due to the unfamiliar concepts, invest a small amount of time with the platform and it will soon start to payoff. This list of tutorials and resources will help you get up to speed quickly.

Magento eCommerce Tutorials and Resources

I have compiled the following list of resources that have helped me while developing for the Magento platform.

Developing Themes

• Learning to Design and Code for Magento Themes
• Designer’s Guide to Magento
• Configuring Templates, Adding a Product Grid in Magento
• Magento Template Advices

Custom Code and Modules

• Writing a custom module in Magento, detailed walktrough
• How To Write Magento Custom Module: Cash On Delivery Payment Method
• Magento Design and Magento Development blog
• snippi | MAGENTO CODE SNIPPETS
• Create Payment Method Module
• HOWTO: Repackageable custom extension development in magento

API Documentation

• Magento Documentation (phpdoc)

Tips and Advice

• MageTips
• Top 3 mistakes by Magento beginners

Related Articles

• No Related Post

I don’t think I’m alone in the fact that over the past twelve months I have been learning Cocoa specifically Cocoa Touch for the iPhone. Apps and tutorials will follow! However I have also been looking at Cappuccino (http://cappuccino.org/) a direct port of Cocoa to JavaScript. The intention of Cocoa and Cappuccino is to make the development of applications a quick, simple and fun exercise, however if like me you are approaching this from a web development standpoint those first steps can be a little hard.

However I have found a set of resources that will be invaluable if you too are trying to get to grips with Cocoa or Cappuccino.

Cocoa & Objective-C

Cocoa is an Object Orientated MVC framework build in Objective-C a superset of C. It is the framework used to develop the native applications for Mac and the iPhone. It is a well proven framework created and supported by Apple with a vast developer community.

Cappuccino & Objective-J

Cappuccino is and Object Orientated MVC framework built in Objective-J a superset of JavaScript. It is a direct port of Cocoa by the guys behind (http://www.280north.com/). It runs directly in any JavaScript enabled web browser. Cappuccino has been used in a number of applications such as:

• http://280slides.com/
• http://almost.at/

Where do you start?

Cocoa has vast amounts of very very high quality documentation on the Apple site (http://developer.apple.com/) however it is not the most accessible read. It is amazing once you have made those first steps but there are not many step by step tutorials or lesson based examples. However after a lot of searching and reading I have found some great starting points:

• http://andymatuschak.org/articles/2007/09/09/getting-started-with-cocoa-a-friendlier-approach/
• http://cocoadevcentral.com/
• http://www.teachmecocoa.com/

Cappuccino when compared to Cocoa is in it’s infancy. As such the documentation is not as complete, however you can transfer a lot of knowledge from the Cocoa documentation. Again here is a list of the resources I have found when learning Cappuccino:

• http://www.littletreesoftware.com/blog/
• http://cappuccino.org/learn/tutorials/
• http://cappuccino.org/learn/documentation/

Conclusion

These frameworks can be very daunting at first and the syntax alien but after I while using them they can be a very intuitive and expressive languages. The Cocoa community is very large with a wealth of knowledge however it appears that not may developers pass on the experiences online so it can be very hard to find good examples online. Cappuccino opens the door for existing Cocoa developers to move to building for the web. This hopefully will lead to much more content being made available for people new to the language.

I have found the learning Cappuccino and Cocoa together very helpful and the examples I have found transfer very well. I look forward to seeing the rich web applications that will come out of the meeting of these two communities and technologies.

Related Articles

• No Related Post

With all this said when using the Gaia Framework with MDM Zinc application wrapper you have a couple of issues to resolve.

• File paths and references from the application executable.
• External Interface calls.

Most flash developers are likely unfamiliar with developing installable applications so these issues may be daunting when first encountered. However once explained there are simple solutions to both these issues that I will explain in detail.

File Paths and References

When Flash is used within a website it is served by a webserver and files can always be referenced from the root of the website e.g. /flv/example-video.flv or relative to the location of the .swf e.g. flv/example-video.flv.

However when your .swf is running inside the MDM Zinc wrapper it can no longer reliably reference files using the absolute path from root or a relative path. To resolve this you will need to evaluate the location that the application is running at before creating a path to the files based on this computed path.

Zinc Context Object

To solve this problem I have created a singleton context object. This object allows me to run the required application setup code and access the application properties from everywhere within my Gaia based application.

package com.designdisclosure.utils.mdm
{
  import mdm.*;
  import flash.events.Event;
  import flash.events.EventDispatcher;
  import flash.display.*;

  public class ZincContext  extends Sprite
  {
    private static  var _instance:ZincContext;
    public var zincGlobals:ZincGlobals;

    /**
    * Public static method to instantiate the ZincContext object.
    * @return ZincContext Object Instance
    */
    public static function get instance():ZincContext
    {
      if(_instance === null)
      {
        _instance = new ZincContext(new SingletonEnforcer());
      }

      return _instance;
    }

    public function ZincContext(pvt:SingletonEnforcer):void
    {
      if(pvt == null)
      {
         throw new Error("Error: Instantiation failed: Use ZincContext.instance instead of new.");
      }

      // Initialize an MDMZinc application and create a callback method for when this is completed
      mdm.Application.init(this, onMDMinit);
    }

    private function onMDMinit():void
    {
      // Use this method to setup your Zinc application
      // This is the same as applicationDidFinishLaunching from cocoa
    }

    /**
     *  Get the absolute path to the application and its files.
     *  I use a VMWare machine during testing and found
     *  that the application path is alittle un-reliable
     *  and needs modification when running in the VM.
     */
    public function getApplicationPath():String
    {
      var path:String = mdm.Application.path;

      return path;
    }

    public function get isZincApplication():Boolean
    {
      return (getApplicationPath.length)? true : false;
    }
  }
}

internal class SingletonEnforcer {}

This object can be used to obtain the application path, an absolute location at which the Zinc application is running. The can then be used in any function the loads external resources. However here is the main problem within the Gaia framework. It is possible to update the path to the site.xml file that is loaded in main.as but even if you load the file from an absolute path the framework does not update the paths used to load any assets referenced in the xml file its self.

Fixing the file paths

Although my next suggestion is not by any means ideal as it involves modifying the framework, I have yet to find a better solution. This obviously will lead to problems when updating the framework to future revisions. However these changes re fairly limited in scope as it is only a single file SiteModel.as. Here are my modifications that inject the application path if it exists into any location where external files are loaded.

    public function load(path:String):void
    {
      if (path == null) path = "site.xml";
      if (path != "xml/site.xml" && path != "site.xml") GaiaDebug.log("site.xml path = " + path);
      var request:URLRequest = new URLRequest(CacheBuster.create(ZincContext.instance.getApplicationPath()+path));
      loader = new URLLoader();
      loader.addEventListener(Event.COMPLETE, onLoadComplete);
      loader.load(request);
    }

private function parseSite():void
    {
      _title = _xml.@title || "";
      _preloader = _xml.@preloader || ZincContext.instance.getApplicationPath()+"preload.swf";
      _menu = (_xml.@menu == "true");
      _delimiter = _xml.@delimiter || ": ";
      _routing = !(_xml.@routing == "false");
      _history = !(_xml.@history == "false");
      _indexFirst = (_xml.@indexFirst == "true");
      _assetPath = _xml.@assetPath || ZincContext.instance.getApplicationPath();
      // preloaderDepth
      var depth:String = String(_xml.@preloaderDepth).toLowerCase();
      if (depth == Gaia.MIDDLE || depth == Gaia.BOTTOM) _preloaderDepth = depth;
      else _preloaderDepth = Gaia.TOP;
      // preloaderDomain
      var domain:String = String(_xml.@preloaderDomain).toLowerCase();
      if (domain == Gaia.DOMAIN_CURRENT || domain == Gaia.DOMAIN_NEW) _preloaderDomain = domain;
      else _preloaderDomain = Gaia.DOMAIN_NULL;
      // defaultFlow
      var flow:String = String(_xml.@flow).toLowerCase();
      if (flow == Gaia.PRELOAD || flow == Gaia.REVERSE || flow == Gaia.CROSS) _defaultFlow = flow;
      else _defaultFlow = Gaia.NORMAL;
      if (_routing) _routes = {};
    }

private function parsePage(node:XML, parent:PageAsset = null):PageAsset
    {
      validateNode(node, true);
      var isIndex:Boolean = (node.@id == _indexID);
      var page:PageAsset = new PageAsset();
      page.node = node;
      page.id = node.@id;
      page.src = ZincContext.instance.getApplicationPath()+node.@src;
      page.title = node.@title;
      page.bytes = node.@bytes;
      page.assetPath = ZincContext.instance.getApplicationPath()+node.@assetPath || _assetPath;

      page.preloadAsset = true;
      page.menu = (node.@menu == "true");
      if (page.menu && page.title.toLowerCase() == "about") GaiaDebug.warn('* Warning * "About" is not permitted in Flash context menus');
      if (page.menu && page.title.length > 0) _menuArray.push(page);
      page.landing = (node.@landing == "true");
      // domain
      var domain:String = String(node.@domain).toLowerCase();
      if (domain == Gaia.DOMAIN_NEW || domain == Gaia.DOMAIN_CURRENT) page.domain = domain;
      // depth
      var depth:String = String(node.@depth).toLowerCase();
      if (!isIndex)
      {
        page.setParent(parent);
        page.external = (node.@src.split(".").pop() != "swf" || node.@src.indexOf("javascript") > -1);
        if (page.external) page.window = node.@window || "_self";
        if (depth == Gaia.TOP || depth == Gaia.BOTTOM || depth == Gaia.NESTED) page.depth = depth;
        else page.depth = Gaia.MIDDLE;
      }
      else
      {
        if (depth == Gaia.TOP || depth == Gaia.MIDDLE) page.depth = depth;
        else page.depth = Gaia.BOTTOM;
      }
      // flow
      var flow:String = String(node.@flow).toLowerCase();
      if (flow == Gaia.NORMAL || flow == Gaia.PRELOAD || flow == Gaia.REVERSE || flow == Gaia.CROSS) page.flow = flow;
      // assets
      if (node.asset.length() > 0 || node.@seo != undefined) page.assets = parseAssets(node.asset, page, node.@seo, int(node.@seoBytes));
      // child pages
      if (node.page.length() > 0)
      {
        page.defaultChild = node.@defaultChild;
        page.children = parseChildren(page, node.page);
        if (!page.children.hasOwnProperty(page.defaultChild)) page.defaultChild = node.page[0].@id;
      }
      // terminal page
      else
      {
        if (page.src.substr(page.src.length - 4) == ".swf") page.landing = true;
        if (isIndex) GaiaSWFAddress.isSinglePage = true;
      }
      // only add terminal and landing pages to routes
      if (_routing && page.landing)
      {
        var route:String = node.@route || page.title;
        if (isIndex) route = route || page.id;
        page.route = getValidRoute(route, page.id).toLowerCase();
        _routes[page.route] = page.branch;
      }
      return page;
    }

These changes allow you to test your application within the flash authoring environment as the application path will be empty and it will load the files with local references. If you run the application inside a Zinc wrapper the files will be references with an absolute path.

External Interface calls

In order for flash applications to communicate with the browser they use External Interface. This is used extensively within the Gaia framework for logging and also search engine optimization with swfAddress. However MDM Zinc does not handle these calls particularly gracefully and as it is not possible to turn this functionality off within the framework we again need to make a couple of modifications.

Blocking external calls

Inside SWFAdress.as there is a test for ExternalInterface.available however inside Zinc this will incorrectly report true. The only fix for this is as follows:

private static var _availability:Boolean = false; // used to be ExternalInterface.available;

Conclusion

The solutions I have proposed here will resolve the issues the prevent you from using Gaia within a Zinc application. However I believe that these issues could be resolved in a number of ways within the respective products.

MDM Zinc need resolve the issue with ExternalInterface and the its incorrect implementation as this is essentially a bug in the platform.

The issues with the Gaia framework can not be considered bugs as the framework does exactly what it was intended to do. However I would suggest that the framework would be greatly improved if additional configuration were made available to users. Being able to turn off the SEO modules such as SWFAddress and external calls would be very helpful. Not only for use within MDM Zinc but also in situations where the flash application is not the entire web page. If you use Gaia to be build a smaller component within a page the SWFAddress calls can also cause problems.

The loading of assets would also be greatly improved if it were possible to update their paths at run time. Obviously this is not a common requirement but it would make the framework much more flexible and far more useful.

Related Articles

• No Related Post

This plugin was built after reading “Designing the Obvious” by Robert Hoekman, jr. and working with a number of unsatisfactory validation libraries. It is intended that this plugin will allow you to configure the validation and feedback to make your forms poka yoke devices i.e. impossible for users to make any errors while entering data.

Thanks to Alon Noy for a starting point for the validators! The following symfony validators have been ported to JavaScript implemented in the plugin:

• sfStringValidator
• sfNumberValidator
• sfRegexValidator
• sfEmailValidator
• sfCompareValidator

I also plan to implement a client side callback validator that will allow you to call your own client side validators or even call ajax function to run server side validation in real time.

Installation

To install the plugin you can either download the latest files from the symfony wiki or you can checkout the SVN version.

Install the plugin

symfony plugin-install http://plugins.symfony-project.com/sfPokaYokePlugin

Add the sfPokaYoke filter to your app filters.yml

rendering: ~
web_debug: ~
security: ~

# generally, you will want to insert your own filters here

poka_yoke:
class: sfPokaYokeFilter

cache:     ~
common:    ~
flash:     ~
execution: ~

Clear you cache

symfony cc

You’re done. Any forms that have validation rules will have client-side rules applied too. sfPokaYoke looks for validation rules that match the action name the form will be submitted to. This will also now work with named routes.

Usage Example

Once any validation rules are applied to the actions for your form, rules will be created for the client-side validation.

You can configure the client side validation to be triggered on the form submit or when the individual field loses focus. This is done by adding config values to your app.yml and will define how sfPokaYokePlugin responds to the users interaction

If the input value fails any validation rules that error will be inserted next to the input.

You do not need to add any <div> tags to capture these in-line errors unless you have a specific location in you form markup where you wish the error to be displayed. sfPokaYoke will look for the symfony form error locations and use those <div> tags if available.

If your template includes the following symfony form helper, sfPokaYoke will insert the errors into this location.

<?php echo form_error('name') ?>

On form submission a list of all error is inserted as the first child of the form. Each listed error item has an onclick event attached to allow the user to click on the error to focus the form field and resolve the problem.

<ul id="pkykGlobalErrors">
   <li class="globalErrorTitle">The following form information has been completed but it contains errors:</li>
   <li class="errors" id="pkykGlobal_username">Please enter your username.</li>
   <li class="errors" id="pkykGlobal_password">Please enter your password.</li>
</ul>

As each input error is corrected by the user the in-line and list errors are removed.

Example configuration

The code block below is an example app.yml file entry to configure the interactions of sfPokaYoke

all:
  # Example app.yml config for sfPokaYoke
  pokayoke:
    # Turn PokaYoke on and off
    on: true
    # Turn on the debuging this will cause alerts at each validation action
    debug: false
    # Event hooks - validation called on both field blur and form submit
    validate_onblur: true
    validateon_submit: true

    # Define which events should display the inline and global form errors
    display_inline_onblur: true
    display_inline_onsubmit: false
    display_global_onblur: false
    display_global_onsubmit: false

    # Inline error id="error_for(_name)" and class="form_error"
    inline_id_prefix: error_for_
    inline_class: form_error

    # <li class="form_error"></li> the global error lost class
    global_class: form_error
    # The text used to introduce the global errors list
    global_title: 'The following form information has been completed but it contains errors:'
    global_titleclass: pkyk_global_title

    # Add an onClick event to the items in the global list - click to focus the field with the error
    global_onclick_focus: true;

Related Articles

• No Related Post

• PokaYoke – one of my contributions to the symfony framework. Client side validation component that integrates with the symfony framework or that can equally well be used with any project that requires simple and very configurable clientside validation.
• Eclipse PDT – setting up the ideal combination of eclipse plugins for web development
• Parallels Virtual Appliance – setting up a Fedora based virtual machine to use as your development machine.

So there you have it. Welcome to my blog and feel free to pass judgment

Related Articles

• No Related Post