Вообще если задуматься, аннотации — большое зло, это «чёрные ящики кода» которые непонятно откуда и как вызываются и непонятно как разбирать ошибки связанные с ними, да и вообще сам процесс смешивания кода или данных с комментариями говорит о каких-то проблемах с возможностями языков программирования.
В данной статье как раз указано о создании своей аннотации. Можно было ее назвать «inputAttributes», к примеру. Проверка на наличие аннотации есть в компоненте.класс Phalcon\Annotations\Collection метод boolean has (string $name)
Посмотрел внимательнее, нашел. Но в итоге у нас динамические аннотации, если я например ошибусь в названии аннотации (например напишу @FormOption вместо @FormOptions), то узнаю про это в самый последний момент, парсер не укажет — что такая аннотация не объявлена.
Ипонскийбох! Convention over comments в частности для правил маршрутизации на практике — очень неудобно. По URL неясно, куда роутится запрос, и, не глядя в код, неясно, как будет выглядеть URL. То есть настроить может только сотрудник, близко знакомый с кодом, то есть программист.
С моей точки зрения проектировать систему надо так, чтобы в случае кастомизации продукта (в частности, необходимость реконфигурация URL) или технических неполадках (в частности, если рабочие URL вдруг стали выдавать 404) специально обученный человек знал, какой конфиг поправить.
Рассказывать админам о архитектуре проекта непроизводительно, а тем более учить его PHP, чтобы он понимал source code.
Я про крупные проекты. В небольших проектах, вполне возможно, управляет всем один тестировщикоадминопрограммист и он всё знает.
Phalcon PHP фрейморк. Работа с аннотациями