Первый плагин для разработчиков

Здравствуйте.
В последних своих статьях я затронул темы стиля кодирования и проксирования методов модулей. Темы так и остались открыты, поэтому, продолжая начатое в них, представляю плагин для разработчиков — funcPack.
Что это такое: прежде всего этот плагин – попытка сделать немного удобнее и приятнее работать, оформленная в виде плагина. Ну и по порядку особенности – пока их немного:
  • — поддержка Alto 1.0-alpha;
  • — возможность проксирования методов;
  • — 9 валидаторов значений;
  • — примесь для класса плагина с методом публикации скриптов;
  • — Live templates для валидаторов и прокси-методов для PhpStorm (сегодня вышла 7-я версия — обновляемся).
Да, код плагина написан в соответствии с рекомендациями которые обсуждались ранее.

Проксирование методов

На данный момент реализовано только проксирование модулей CMS, методы модулей плагинов, пока вызываются по прежнему.


В чем сахар:
  • — работает автокомплит;
  • — нет магии (по крайней мере очевидной);
  • — работает и показывает phpDoc (ctrl+q в PhpStorm);
  • — подсказываются параметры метода (ctrl+p в PhpStorm);
  • — параметры могут передаваться по ссылке;
  • — инспектор корректно проверяет этот код;
Да, вызов очень длинный, зато без магии. Для удобства набора был создан специальный Live Template для PhpStorm, который идет в составе плагина и позволяет только с помощью нажатия ctrl+j и набора нескольких кодовых букв набрать вызов. Кодовые символы представляют собой имя модуля с лидирующей буквой «m».
На картинке вызов набран нажатием ctrl+j, букв m,u и таба.


Live Template создан для всех модулей – файл proxy.xml его нужно положить сюда: http://www.jetbrains.com/phpstorm/webhelp/live-templates.html.

Валидаторы значений

Другая вспомогашка, реализованная в плагине – валидаторы значений. Для того, что бы проверить значение нужно выполнить следующие действия:
  • — описать метод проверки;
  • — сделать локализацию строк ошибок;
  • — вызвать проверку.
Созданные 9 валидаторов позволяют проводить проверку значений в одну строку – пример на картинке (код валидаторов основан на соответствующем коде фреймворка Yii).


Общий принцип использования валидаторов следующий: В параметр статического метода передается массив описаний валидаторов и этот метод возвращает 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

Похожие статьи

  • Обновился плагин funcPack
    Здравствуйте. Вот и кончилась зима, всех с первым днем Весны! Давно лежали на полке пара вещей и, наконец, удалось привести их в порядок и добавить к плагину. Описание того, что в плагине уже есть здесь: http:...

4 комментария

0
Пара вопросов по плагину:

1) Версия PHP 5.4 нужна только для примесей? Или где-то еще используются специфические конструкции/ф-ции 5.4?

2) Не вполне понял относительно валидаторов — сейчас в движке уже есть механизм валидации значений, причем, исходящий корнями тоже из Yii. Предлагается иная реализация? Хотелось бы плюсы/минусы понять
0
1. из php 5.4 используется: примеси, обращение к массиву через [] а не через array, получение результата метода по индексу $foo=bar[0]

2. напишу позже, с телефона не удобно :)
0
Нет, иную реализацию я не предлагаю. Цель плагина не вносить новое, а упростить написание кода используя предложенные в плагине механизмы.

Что касается валидаторов в LS, то у меня к ним неоднозначное отношение:
1. С одной стороны это качественный механизм проверки, который в частности используется и в сущности User
2. А с другой стороны 15 классов и 1500+ строк кода, что бы использовать их в 5-и сущностях из более 7 десятков, причем валидация значений с их помощью вообще не используется. В отличие от Yii, использование валидаторов при проверке модели/сущности не является обязательным – отсюда и нежелание разработчиков их использовать – зачем учить/рассматривать код 15 классов и методику их использования, если можно написать свой метод validateMe() и его пользовать – быстрее и проще. Получается, что это архитектурный излишек, без которого можно и обойтись, причем его использование не доставляет очевидных плюсов.
3. А может, валидаторы LS – это задел на будущее – потом, планируется что-то большое и удобное с их использованием.

Цель, которую я ставил при реализации предложенного набора валидаторов проста, и на самом деле единственна – валидация набора значений для того, что бы сократить объем кода и сделать его читабельней. Я не покушался на механизм модуля Validate и как-то менять его не предлагаю.

Вот пример я взял код из модуля Admin и в нем сделал все проверки через вализаторы. Сразу скажу – пример не рабочий, поскольку не все используемые валидаторы и их модификаторы реализованы.


Плюсы-минусы: в бою валидаторы не обкатывались, поэтому сложно судить. Наверное, примеры будут позже.
Отредактирован:
+1
Здесь у меня вопрос к разработчикам – Можно ли, понимая маппер как интерфейс доступа к данным перенести в него логику работы с КЭШем. При этом если в КЭШе будет результат – возвращать его, а если нет – получать от БД???
Мне представляется такой подход идеологически неверным. Маппер — это аппарат работы с источником данных. А кеш — это некое временное хранилище данных, но никак не их источник. И в общем случае кеш вовсе не обязательно является прослойкой между модулем и маппером.

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

В общем, мой ответ на вопрос: переносить работу с кешем в маппер не стоит.
Отредактирован:
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.