Janusz Slota » php

How to handle sfError404Exception

Janusz Słota — Tue, 06 Dec 2011 18:42:46 +0000

The problem:

Let’s say you need to migrate old website to you new Symfony app. You want to keep all old links working. When they do not match the new link scheme, you want to redirect with 301 (or 302) to correct page in the new URL scheme. All these can be managed via backend module.

My first thought was I need a filter to catch sfError404Exception and handle redirections from there. Well, in Symfony 1.4 you can’t do it without changing the Symfony core files, so it’s not an option. This is because the filters are not even get called, as routing finds out first, that the module and/or action does not exists and throws this exception.

The solution:

There is the easier way of doing this. First you need to add new route that catches all that does not match current link scheme. In fact you need to replace default and default_index routes with something like this:

# apps/frontend/config/routing.yml
 
your_other_routes_here: ~
 
# generic rules
# please, remove them by adding more specific rules
# default_index:
#  url:   /:module
#  param: { action: index }
 
# default:
#  url:   /:module/:action/*
 
# at the very end of the file
catchall:
  url:   /*
  param: { module: default, action: catchall }

If you still need default and default_index routes you need to somehow handle forwards in your executeCatchall action. Please note that the above catchall route cannot be combined together with default and default_index. If you put catchall above these two, they won’t be executed ever, on the other hand – if you put it below these two, catchall will never be executed.

Then in this case you need to create executeCatchall action in your default module:


// apps/frontend/modules/default/actions/actions.class.php
class defaultActions extends sfActions
{
  public function executeCatchall(sfWebRequest $request)
  {
    // find your redirectation using $request->getPathInfo()
    $redirection = Doctrine_Core::getTable('Redirection')->findOneByPathInfo($request->getPathInfo());
 
    // this ensures that if there is no specified redirection, the old sfError404Exception gets thrown
    $this->forward404Unless($redirection); 
 
    // redirect
    $this->redirect($redirection['redirect_to']);
  }
}

In the above example I’m assuming the following model class:

Redirection:
  columns:
    path_info:        { type: string(255) }
    redirect_to:      { type: string(255) }

Of course this is very basic implementation of redirection functionality, but it shows the correct way of doing it. I hope it’ll help.

What’s wrong with handling sfError404Exception inside the execute404() action?

Well, it often happens that you need to throw sfError404Exception in your actions. It doesn’t feel right for me to throw this exception inside the method that handles it.

How to set default value or option in the Symfony embeded form inside the Action

Janusz Słota — Mon, 26 Sep 2011 13:23:56 +0000

Let’s say you have Symfony 1.4 form User with embedded form Entry

class UserForm extends Something
{
  public function configure()
  {
    $this->embedForm('entry', new EntryForm());
  }
}

and let’s say that this embedded form contains sfWidgetFormChoice widget

class EntryForm extends BaseEntryForm
{
  public function configure()
  {
    $this->widgetSchema['cars'] = new sfWidgetFormChoice(array(
      'choices' => array(),
      'expanded' => true
    ));
    $this->validatorSchema['cars'] = new sfValidatorChoice(array(
      'choices' => array()
    ));
  }
}

Mind that choices option is an empty array – I want to set this option in the action as it depends on data in the session.

I found that, the following code in the action layer doesn’t work:

class defaultActions extends sfActions
{
  public function executeIndex(sfWebRequest $request)
  {
    $this->form = new UserForm();
    $this->form->getEmbeddedForm('entry')->getWidget('cars')->setOption('choices', $this->getUser()->getAttribute('cars'));
  }
}

Not sure why, but it’d work if the cars widget is attached to the UserForm. Maybe it’s related to this bug. Anyway, if try to set option choices, it sets correctly, but the view layer ignores it.

class defaultActions extends sfActions
{
  public function executeIndex(sfWebRequest $request)
  {
    $this->form = new UserForm();
    $this->form->getEmbeddedForm('entry')->getWidget('cars')->setOption('choices',$this->getUser()->getAttribute('cars'));
 
    if($this->form->getEmbeddedForm('entry')->getWidget('cars')->getOption('choices') == $this->getUser()->getAttribute('cars'))
    {
      throw new Exception('setting up options for embedded forms works correctly, but the view layer seems to ignore it.');
    }
  }
}

So, if you have trouble setting up the dynamic options for the embedded form, you can do this, which seems to work.

class defaultActions extends sfActions
{
  public function executeIndex(sfWebRequest $request)
  {
    $this->form = new UserForm();
    $this->form['entry']['cars']->getWidget()->setOption('choices', $this->getUser()->getAttribute('cars'));
  }
}

Same problem is with validatorSchema. I found that this seems to work:

class defaultActions extends sfActions
{
  public function executeIndex(sfWebRequest $request)
  {
    $this->form = new UserForm();
    $this->form['entry']['cars']->getWidget()->setOption('choices', $this->getUser()->getAttribute('cars'));
 
    // validator part
    $validatorSchema = $this->form->getValidatorSchema();
    $validatorSchema['entry']['cars']->setOption('choices',array_keys($this->getUser()->getAttribute('cars')));
  }
}

I hope it’ll help.

What’s the average length of an email address?

Janusz Słota — Tue, 05 May 2009 16:52:18 +0000

This question always comes up, when you have to design new table in database to store email addresses. Is VARCHAR(30) long enough? Or maybe you should use VARCHAR(255) or maybe TEXT as I’ve seen in some projects?

My live database, which I’ve used for this test contains 92298 valid email addresses, verified with the Pear Validate class with domain checking.

if(Validate::email($email,true))
{
    // add to database
    return true;
}
else
{
    // return error
    return false;
}

It means, if the email address is in this database – it is real and correct, otherwise the field is empty. So to make sure not to include empty fields, I’ve issued following query:

SELECT COUNT(*), LENGTH(email) AS SIZE FROM customer WHERE email LIKE '%@%' GROUP BY SIZE ORDER BY SIZE;

This query returns set of values, which I’ve used to create this chart (with OpenOffice.org Calc).

As you can see majority of email addresses are around 13 to 34 characters long. To store email addresses I’ve used VARCHAR (255) but as you can see VARCHAR(50) is enough.

The answer: VARCHAR(50) should do.