Comments 13
Хотелось бы больше услышать про парсер аннотаций и маршрутизатор аннотаций: в чем профит, подводные камни и т.д.
Сейчас статья выглядит как «наткнулся на аннотации, смотрите как можно делать».
Сейчас статья выглядит как «наткнулся на аннотации, смотрите как можно делать».
Сейчас статья выглядит как «наткнулся на аннотации, смотрите как можно делать».
Профит аннотаций очевиден: роутинг описан рядом с action-ом сразу можно сопоставить с action и url.
Камни: Сложнее выявить неоднозначность роутинга и необходимость парсить/кэшировать.
На самом деле всё не совсем так — лично мне просто очень импонирует то, что экшн контроллера лишь возвращает набор данных, а не создает, к примеру, объект респонса и делает что-то вроде echo или обертку над echo в ввиде send() в самом экшене, или же, как часто можно встретить в примерах реализаций подобное: echo json_encode($result);. Можно писать очень тонкие контроллеры, без дублирования стандартных операций, всю логику вынося, скажем, на сервиса.
А касательно роутинга — то это достаточно крутая возможность, которую, в тоже время, можно заменить на стандартную Phalcon\Mvc\Router, разграничив достпуп по типам http запросов в виде конфига, например:
При этом слегка ухудшив понятность кода, потому как, я думаю, Вы не будет спорить что с аннотациями код будет выглядеть как минимум красивее.
На счет профита и подводных камней. Собственно профит, как я уже написал выше, в совмещении функционала и красоты. А вот подводных камней, теоретически, они могут быть — Phalcon это расширение, продебажить реализацию не просто(разве в сишных исходниках), чтобы с уверенностью сказать что там все хорошо.
Парсинг основан не на, де-факто, стандартном подходе с Reflection, а на собственной с-шной реализации, работающей значительно быстрее Reflection + из коробки есть возможность кеширования результатов парсинга (например, Phalcon\Annotations\Adapter\Files для хранения результата в файле)
А касательно роутинга — то это достаточно крутая возможность, которую, в тоже время, можно заменить на стандартную Phalcon\Mvc\Router, разграничив достпуп по типам http запросов в виде конфига, например:
$routes->addGet('/get');
$routes->addPost('/post');
При этом слегка ухудшив понятность кода, потому как, я думаю, Вы не будет спорить что с аннотациями код будет выглядеть как минимум красивее.
На счет профита и подводных камней. Собственно профит, как я уже написал выше, в совмещении функционала и красоты. А вот подводных камней, теоретически, они могут быть — Phalcon это расширение, продебажить реализацию не просто(разве в сишных исходниках), чтобы с уверенностью сказать что там все хорошо.
Парсинг основан не на, де-факто, стандартном подходе с Reflection, а на собственной с-шной реализации, работающей значительно быстрее Reflection + из коробки есть возможность кеширования результатов парсинга (например, Phalcon\Annotations\Adapter\Files для хранения результата в файле)
Вот мне интересно, почему аннотации записываются в блоке комментариев, а не как декораторы в питоне — непосредственно перед функцией. Ведь если по какой-то причине не распарсятся — это будет неверная логика приложения. А если их описывать не в закомментированном виде, а в явном — приложение не запустится, что будет значить примерно одно и то же. Ведь у них все равно есть отдельный парсер, который не завязан не Reflection
example
/*
* @annotation
*/
funciton getList() {}
против
@annotation
function getList() {}
Думаю просто потому что php к этому еще к этому не пришел (а может и не прийдет). Аннотации не являются встроенными возможностями языка, потому и приходим к их реализации через комментарии.
Это понятное дело. Я про то, что покуда они все равно парсятся препроцессором в том или ином виде, а если он не отработает — приложение будет отрабатывать неправильно, почему сразу не сделать так. Ведь если препроцессор не отработает в текущем виде — приложение запустится, но будет неправильно функционировать. Если сделать как я предлагаю — оно даже не запустится, что будет однозначно (по первой же ошибке) указывать на то, что не сработало. Ну и синтаксически красивее. Единственное, поддержка в IDE будет никакой, но если они и сейчас не поддерживают аннотации — это все равно не удобно.
Но это лично мое ИМХО и хотелось бы узнать, почему внедряют расширения языка именно в виде комментариев? Причем, так делает не только Phalcom. Это связано с тем, как работают предкомпиляторы? Т.е. они после загрузки файла через рефлексию изменяют код или есть другие причины?
Но это лично мое ИМХО и хотелось бы узнать, почему внедряют расширения языка именно в виде комментариев? Причем, так делает не только Phalcom. Это связано с тем, как работают предкомпиляторы? Т.е. они после загрузки файла через рефлексию изменяют код или есть другие причины?
Достаточно не простой вопрос, и подобные предложения не раз рассматривались собcтвенно разработчиками php. Видимо к единному стандарту они не пришли или же отложили эту тему. Собственно также важно понимать принцип работы интерпритатора — сперва происходит парсинг, выявить на этом этапе не синтакисческие ошибки не получится, после код уже интерпретируется в исполнимый байткод. Если аннотации добавить как структуры языка с определенными ключевыми словами — можем получать parse error при некорректом использовании, уже на этапе парсинга, но думаю список таких зарезервированных лексем языка может быть крайне большим и потеряет свой смысл. Думаю кроме такого варианта нет возможности выявить не на этапе выполнения. Конечно было бы очень не плохо даже на этапе выполнения получить к примеру E_STRICK при несоответствии аннотации содержимому метода (или как-нибудь иначе). Собственно php любой тип ошибок, связанный с выполнимым кодом, кроме parse error выявляет уже на этапе его выполнения(E_COMPILE и E_CODE не в счет, это ошибки другого характера).
Хм. Не, питон мне не сильно нравится, но вот идея декораторов прям очень нравится (сейчас в голове живет идея сделать некий аналог для js, там такое реализовать не сложно, в ноде, например, попросту расширить require, который перед исполнением модуля еще парсер запустит). Такая идея позволит самому свободно дописывать декораторы. Собственно, в php можно поступить аналогичным образом. Использовать не include(), а свою функцию, которая будет аналогом require в ноде. Т.е. он открывает файл, парсит его на наличие декораторов, вызывает функции обработки декораторов (очевидно, они должны быть объявлены заранее), в случае, если обнаружен необъявленный декоратор — вызывается ошибка времени исполнения (покуда я предлагаю путь не изменения самого языка, а дописывание), затем оборачивает код в модуль и исполняет его как функцию. Эдакий AMD подход на php. Но, наверное, там это излишки.
Но такой подход позволит одним кликом экспортировать роуты, организовывать тесты REST API (подменяя аннотации, хотя это возможно и сейчачс), да и… Похоже, у меня node.js головного мозга.
Но такой подход позволит одним кликом экспортировать роуты, организовывать тесты REST API (подменяя аннотации, хотя это возможно и сейчачс), да и… Похоже, у меня node.js головного мозга.
deniskin, вы сломали Хабр. Количество «странных» публикаций увеличилось :(
Наследовать контроллеры REST приложения от Phalcon\Mvc\Controller — не самая лучшая затея, MVC стек у нас сделан для MVC приложений, с накладываемым overhead на view и другие необходимые зависимости и сервисы.
Для большей скорости, простоты и именно реализации REST стоит присмотреться к Phalcon\Mvc\Micro ( docs.phalconphp.com/en/latest/reference/micro.html )
Для большей скорости, простоты и именно реализации REST стоит присмотреться к Phalcon\Mvc\Micro ( docs.phalconphp.com/en/latest/reference/micro.html )
Я никогда не работал с Phalcon, непонятно что возвращают эти методы: XML, JSON, HTML? Как это настраивать?
Sign up to leave a comment.
Простой каркас Rest Api на основе Phalcon