Extending the default module action

August 20, 2008 in Scales
Tags: modules

Often in a project, module actions have to manage the same common kind of functionalities :

• paging
• sorting
• filtering
• any other general job

You end up with actions that implements each functionality, maybe into separate methods :

class articleActions extends sfActions
{
  protected function processSort() { …  }

  protected function processFilter() { …  }

  public function executeIndex()
  {
     $this->processSort();
     $this->processFilter();
     $this->pager = new sfPropelPager(‘Article‘, 20);
     …
  }
} 

Let’s extract these jobs and use them in all your modules.

Extending sfActions

A Symfony action is a stack of extended classes, so you can easily add your own class to the stack and can put all the common code in it.

Let’s factorize all theses functionalities into a custom action class that extends sfActions.

Let’s create the /lib/myBaseActions.class.php file :

class myBaseActions extends sfActions
{
  // Implement your general methods here
  protected function processSort()
  protected function processFilter()
  …
} 

Now, simply change the parent class in your module action class :

class articleActions extends myBaseActions
{
  public function executeIndex()
  {
  }
  …
} 

The dirty job is now centralized and executed implicitly in all your modules.

Besides, extracting the logic that way forces you to write decoupled and cohesive code, as each method only do a specific job.

About auto-generated modules

You should take a look at how a module action generated by the sfAdminGenerator.

• Simply init a module :

$ symfony propel:init-admin article_admin Article

• Go to http://yourapp/article_admin to generate cache files

Check /cache/prod/modules/autoArticle_admin/actions/actions.class.php.

You can get inspired from it, specially from these design principles :

• sorting and filtering infos are stored in the session
• Criteria modifications for both is split into separate methods