Configure the form root element with Symfony Forms 3

While creating the forms with Form component from Symfony you can write your own Type classes which builds the forms. It’s pretty simple to add your own fields and all the required stuff for it.

class SignUpType extends AbstractType {
  public function buildForm(FormBuilderInterface $builder, array $options) {
  $builder
    ->add('email', Type\EmailType::class, array(
      'label' => __('Email', Plugin::NAME),
      'required' => false,
      'constraints' => array(
         new Constraints\NotBlank(array(
           'groups' => array('personal', 'company'),
         )),
         new Constraints\Email(array(
           'groups' => array('personal', 'company'),
         )),
      ),
     'validation_groups' => array('personal', 'company'),
     'attr' => array(
       'data-form-element-role' => 'conditional-listener',
       'class' => 'regular-text',
     ),
    ))
    ;
  }
}

But that if you want to configure out the root form element. For example, setup few additional classes and data attributes for your tag? Just add configureOptions() method and fill all the required stuff inside.

class SignUpType extends AbstractType {

  // buidForm here

  public function configureOptions(OptionsResolver $resolver) {
    $resolver->setDefaults(array(
      'attr' => array(
        'data-form-type' => 'conditional-form',
        'id' => 'your-id',
      ),
    ));
  }
}

Coding standards. CamelCase and snak_case

Coding standards

Hi there. I’m working on some plugins for WordPress and I really love WordPress, it’s standards and being a WordPress Developer but sometimes I feel lost while writing code.

I think this idea is not a priority issue of WordPress community. And also this idea can be perceived as negative, but I really hope you would give it a chance.

After a lot of thinking I realized that only one thing stopping me from being happy: snack_case instead of CamelCase.

Why I think that CamelCase is better? There is few reasons for it.

Continue reading

Новые инструменты. Symfony Validator

Я хотел написать про кучу нового и интересного с чем удалось познакомиться и какие мысли пришли в голову — но это много. Поэтому разобьем все на несколько постов. Первый (этот) пост посвящен короткому, но знакомству, с Symfony Validator.

На прошлой неделе я разобрался с работой Symfony Validator. Это потрясающая библиотека (дополнение) позволяет проверять любые типы данных на какие-либо соответствия. Если коротко, то проверка чего угодно сводится к паре дополнительных строчек. И не нужно городить очередную реализацию какой-нибудь формы в 101 раз.

Библиотека хороша тем, что работает где угодно, даже в WordPress — для этого ей ничего не нужно. Это большой плюс Symfony — весь фреймворк по сути набор небольших модулей (symfony.com/components), которые умеют работать независимо друг от друга (может скоро и Doctrine захочется прикрутить к WordPress? — пока не было необходимости). Я использую все это для проверки настроек большого плагина (энтерпрайз и все такое).

Ниже приведен простой пример использования Validator, но он полностью рабочий (должен быть, писал в блокнотике по памяти). Конечно, все это подойдет лишь для демонстрационного «стенда». Для нормального применения пришлось написать с десяток новых классов, «задокументировать» все это в интерфейсах и прочее. Но результат того явно стоил.

// Создаем валидатор
$validator = Validation::createValidator();

// Входные данные
$input_data = array(
	// Значение должно быть ссылкой
	'url' => 'http://korobochkin.com/',

	// Список чего-либо
	'post_types' => array( 'post', 'page' )
);
// Создаем правила для проверки массива
$constraints = new Constraints\Collection( array(
	'url' => array(
		// Не должно быть пустым
		new Constraints\NotBlank(),
		// Должно содержать ссылку
		new Constraints\Url()
	),
	'post_types' => new Constraints\Choice( array(
		// Доступные (разрешенные) варианты (опции)
		'choices' => array_values( get_post_types() ),
		// Может быть выбрано сразу несколько
		'multiple' => true,
		// Строгая проверка типов для брони :)
		'strict' => true
	) )
) );

// Проверяем
$errors = $validator->validate( $input_data, $constraints );

if( count( $errors ) === 0 ) {
	// Ошибок нет, переменная $input_data прошла проверку
}
else {
	// Есть ошибки при валидации
}

Настраиваем Xdebug и PHP Storm для работы с Symfony 2 через консоль

Ставим Xdebug, который на Mac OS X уже установлен, и подключаем в /private/etc/php.ini:

[XDebug]
zend_extension=/usr/lib/php/extensions/no-debug-non-zts-20121212/xdebug.so
xdebug.remote_enable = 1
xdebug.remote_host = 127.0.0.1
xdebug.remote_port = 9000
xdebug.idekey = PHPSTORM
;xdebug.remote_autostart = 1

Обратите внимание, что путь до расширения Xdebug может быть другим в зависимости от системы и ее кривости.

В PHP Storm создаем PHP Script конфигурацию в меню Run → Debug Configurations. В поле File указываем полный (абсолютный) путь до app/console.

Чтобы все завелось нужно в терминале написать:

export XDEBUG_CONFIG="idekey=PHPSTORM"

Включаем прослушивание подключений.

Запускаем наш скрипт через app/console и дебагер работает.

Формочки в WordPress

Любимый WordPress перестает быть таковым, как только ты сталкиваешься с задачами, связанными с постройкой форм. В WordPress для работы с ними нет ничего, вообще. Ну, разве что AJAX-экшены можно добавлять и на том спасибо. А пока ищу библиотеку (компонент) с помощью которого можно будет строить формочки. Нашлось всего два:

  1. imavex.com/pfbc3.x-php5
  2. github.com/symfony/Form

Почувствуйте разницу — всяких JS-свистелок для анимашек и дерганий чего угодно на страницах сотни и, вероятно, даже тысячи, а библиотек для обработки форм всего две. Ожидаемая статистика. Так что вместо ругания PHP-программистов, поругайте лучше JS-программистов, лень у которых развита, наверное, больше, чем у всех остальных — привет переменным, названными одной буквой 🙂

Пока даже не знаю можно ли это будет привинтить к WordPress, но компонент от Симфонии — нечто.

P. S. Подумываю о посте с заголовком «Монополия говнокода». Агрессивное название 🙂