В последних своих статьях я затронул темы стиля кодирования и проксирования методов модулей. Темы так и остались открыты, поэтому, продолжая начатое в них, представляю плагин для разработчиков — funcPack.
Что это такое: прежде всего этот плагин – попытка сделать немного удобнее и приятнее работать, оформленная в виде плагина. Ну и по порядку особенности – пока их немного:
- — поддержка Alto 1.0-alpha;
- — возможность проксирования методов;
- — 9 валидаторов значений;
- — примесь для класса плагина с методом публикации скриптов;
- — Live templates для валидаторов и прокси-методов для PhpStorm (сегодня вышла 7-я версия — обновляемся).
Проксирование методов
На данный момент реализовано только проксирование модулей CMS, методы модулей плагинов, пока вызываются по прежнему.
В чем сахар:
- — работает автокомплит;
- — нет магии (по крайней мере очевидной);
- — работает и показывает phpDoc (ctrl+q в PhpStorm);
- — подсказываются параметры метода (ctrl+p в PhpStorm);
- — параметры могут передаваться по ссылке;
- — инспектор корректно проверяет этот код;
На картинке вызов набран нажатием ctrl+j, букв m,u и таба.
Live Template создан для всех модулей – файл proxy.xml его нужно положить сюда: http://www.jetbrains.com/phpstorm/webhelp/live-templates.html.
Валидаторы значений
Другая вспомогашка, реализованная в плагине – валидаторы значений. Для того, что бы проверить значение нужно выполнить следующие действия:- — описать метод проверки;
- — сделать локализацию строк ошибок;
- — вызвать проверку.
Общий принцип использования валидаторов следующий: В параметр статического метода передается массив описаний валидаторов и этот метод возвращает true или false в зависимости от результатов проверки, генерирую при этом сообщение об ошибке стандартным для Alto способом.
Само описание Валидатора представляет собой массив, где первым (нулевым) значением идет наименование типа валидатора – реализованное как константа класса FV – для того, что бы использовать phpDoc. После модификаторы валидатора в формате ключ=>значение. Например, проверка даты, на то, что бы она была меньше какой-либо другой даты будет выглядеть так:
P::validate([
[FV::BASE_DATE, 'value' => date('d.m.Y'), 'format'=>'dd.MM.yyyy', 'required' => '19.10.2013', 'operation' => '<='],
]);
Я не буду описывать все модификаторы, потому что в их коде есть очень хорошее описание – его там больше чем самого кода, но используя ctrl+q на константе имени валидатора Вы всегда можете про него почитать в phpDoc – вот так:
Реализованы следующие валидаторы:
1. Проверка на булево значение.
2. Проверка на валидный url, в том числе и в IDN формате.
3. Сравнение значения на больше-меньше-равно;
4. Проверка даты на больше-меньше-равно;
5. Проверка типа значения (строка, число, дата, время…)
6. Проверка длины строки на больше-меньше-равно.
7. Проверка числа на больше-меньше-равно.
8. Проверка на корректный email.
9. Проверка на включение в набор.
Для валидаторов тоже создан LiveTemplate.
Примеси
Примеси — пока всего лишь задел на будущее. Пока для примера реализована примесь для класса плагина, которая содержит метод публикации скриптов и стилей – для ее использования нужно ее просто подключить, а затем обратиться к методу примеси.
Этот код аналогичен коду:
P::modules()->viewer->AppendStyle(Plugin::GetTemplatePath(__CLASS__). "css/style.css"); // Добавление CSS
P::modules()->viewer->AppendScript(Plugin::GetTemplatePath(__CLASS__). "js/script.js"); // Добавление JSЧто планируется
1. Реализовать примесь, расширяющую маппер для работы с КЭШем. Здесь у меня вопрос к разработчикам – Можно ли, понимая маппер как интерфейс доступа к данным перенести в него логику работы с КЭШем. При этом если в КЭШе будет результат – возвращать его, а если нет – получать от БД???2. Метод преобразования кода, меняющий магические вызовы на проксирующие методы. Для того, что бы перевести Ваш плагин на использование проксирующих методов необходимо все замены делать вручную – есть задача создать скрипт преобразования – поскольку преобразование здесь чисто формальное и может быть сделано автоматом.
3. Добавить валидаторы ACL, Topic, User, Blog – для типовых проверок.
Это пока основное.
Если у Вас есть предложения по дополнительному функционалу – пишите.
Проект на github: https://github.com/andrey-v/funcpack
1) Версия PHP 5.4 нужна только для примесей? Или где-то еще используются специфические конструкции/ф-ции 5.4?
2) Не вполне понял относительно валидаторов — сейчас в движке уже есть механизм валидации значений, причем, исходящий корнями тоже из Yii. Предлагается иная реализация? Хотелось бы плюсы/минусы понять
2. напишу позже, с телефона не удобно :)
Что касается валидаторов в LS, то у меня к ним неоднозначное отношение:
1. С одной стороны это качественный механизм проверки, который в частности используется и в сущности User
2. А с другой стороны 15 классов и 1500+ строк кода, что бы использовать их в 5-и сущностях из более 7 десятков, причем валидация значений с их помощью вообще не используется. В отличие от Yii, использование валидаторов при проверке модели/сущности не является обязательным – отсюда и нежелание разработчиков их использовать – зачем учить/рассматривать код 15 классов и методику их использования, если можно написать свой метод validateMe() и его пользовать – быстрее и проще. Получается, что это архитектурный излишек, без которого можно и обойтись, причем его использование не доставляет очевидных плюсов.
3. А может, валидаторы LS – это задел на будущее – потом, планируется что-то большое и удобное с их использованием.
Цель, которую я ставил при реализации предложенного набора валидаторов проста, и на самом деле единственна – валидация набора значений для того, что бы сократить объем кода и сделать его читабельней. Я не покушался на механизм модуля Validate и как-то менять его не предлагаю.
Вот пример я взял код из модуля Admin и в нем сделал все проверки через вализаторы. Сразу скажу – пример не рабочий, поскольку не все используемые валидаторы и их модификаторы реализованы.
Плюсы-минусы: в бою валидаторы не обкатывались, поэтому сложно судить. Наверное, примеры будут позже.