Статьи

Эти страницы не находятся в дефолтном модуле, так как они вызываются, когда symfony срабатывает не так как задумано. Эти шаблоны можно найти в $sf_symfony_lib_dir/exception/data/ директории:

• error.html.php: страничка вываливается, когда на сервере происходит внутренняя ошибка в продакш моде, в других модах(enviroment), где флаг debug стоит в true, вываливается exception c полным стеком вызовов и указанием ошибки
• unavailable.php: страничка вываливается, когда юзер запрашивает страницу в то время как ваш сайт disabled (при помощи disabled task: "php symfony project:disable application env"), короче находится в спячке (under construction). А так же эта страница появляется, когда происходит очистка кэша (php symfony cc). То есть в промежуток времени, когда вы запустили task и до его окончания. На крупных сайтах кэш может быть большим и его чистка порой занимает несколько секунд. Symfony не обрабатывает запрос при частично очищенном кэше, поэтому запросы, пришедшие до окончания очистки кэша, будут отправлены на эту страницу .

Чтобы кастомизировать эти страницы, просто создайте директорию error в config директории всего вашего проекта или отдельно для каждого application. Либо тут my_project/config/error, либо my_project/apps/frontend/config/error. Создайте в этой папке файлы error.html.php и unavailable.php - symfony будет использовать их, вместо своих.

Необходимо активировать error_404_module и error_404_action в конфигурационном файле settings.yml

# apps/frontend/config/settings.yml
all:
  .actions:
    error_404_module:     error      # Необходимо указать ваш модуль
    error_404_action:       404       # и действие

К примеру вот так:

# lib/form/YourForm.class.php
sfContext::getInstance()->getUser()->->getAttribute('...');

В некоторых случаях выполнение action заканчивается вызовом другого action. Например, action выполняющий обработку POST запроса, обычно редиректит(redirect) в другой action после сохранения данных в базу. Другой пример - подмена action, обычно используется в index actions, когда надо вывести список элементов, здесь происходит перенаправление в list action (forward). Базовый класс sfActions поддерживает два метода, чтобы перенаправить приложение в другое русло: Если action перенаправляет вызов в другой action:

$this->forward('otherModule', 'index');

Объект роутинга в компонентах

# apps/frontend/modules/module/actions/components.class.php
 
class modulenameComponents extends sfComponents
{
 
  public function executeAction(sfWebRequest $request)
  {
    
    $object = $this->getContext()->getController()
      ->getAction($this->getModuleName(), $request->getParameter('action'))
      ->getRoute()->getObject();
  } 
}

Выбор даты года из списка. В years задается диапазаон дат.

$years = range(date('Y') - 110, date('Y'));
'founded' => new sfWidgetFormDate(array('format' => '%year%', 'years' => $years)),

Недавно столкнулись с проблемой в тесте. В тесте с помощью sfBrowser (sfTestFunctional) запрашивали страничку, используя роут:

url_for('@cart_clear');

роут был объявлен следующим образом routing.yml:

cart_clear:
  url: /cart/clear
  params: {module: cart, action: clearcart}

Че то не задавался таким вопросом раньше, сейчас решил рассмотреть этот вопрос. На своих проектах я стараюсь не использовать хостинг как таковой, а брать VDS/VPS и его настраивать под задачу. Что нам нужно, чтобы сайт на симфони нормально функционировал?

Часто приходится выводить выпадающий список с object_select_tag, но сортировать по произвольному полю в базе. Пример использования object_select_tag

echo object_select_tag($domain, 'getObjectId', array (
'related_class' => 'Object',
'peer_method' => 'getSortedObject',
'control_name' => 'object_id',
'include_blank' => true,
)); 

Регистрируясь в нашей системе пользователь должен подтвердить свой email. Как только пользователь подтверждает свой email его с чистой совестью можно добавить в группу «client» и разрешить использовать все возможности нашей системы не требуя перелогиниться. И вот вчера, решая эту простую задачу я столкнулся с очень любопытным явлением, о котором я бы хотел рассказать.

При создании мультиязычного приложения, обязательно, сталкиваешься с проблемой перевода, не только контента, но и всего интерфейса приложения, включая и заголовки. Рассмотрим, несколько способов перевода:

Нашел небольшой класс для генерации sql файла для моделей sfDoctrineCustomBuildSqlTask.class.php

Небольшой кодес, который, поможет вам не удалять файлы вручную, а использовать веб=)

require_once(dirname(__FILE__).'/../../config/ProjectConfiguration.class.php');

$configuration = ProjectConfiguration::getApplicationConfiguration('backend', 'prod', false);
sfContext::createInstance($configuration);

chdir(sfConfig::get('sf_root_dir'));  
$task = new sfCacheClearTask(sfContext::getInstance()->getEventDispatcher(), new sfFormatter());

$arguments = array();

$options = array('env' => 'prod');
$task->run($arguments, $options);

Соответсветственно, указывается режим dev/prod

Для того чтобы сгенерировать ссылку в экшене:

$this->getController()->genUrl('action/method?key=value');

Или подключить хелпер Url

Есть два способа загрузки файлов, первый через форму, а второй такой: