CMS
PHP
Разработка веб-сайтов
Комментарии 11
+1
Мне кажется сомнительным решением писать роуты к cli-модулям, а не оформлять их как консольную команду
И как такое чудо вешать на крон?
Ни в одном популярном фреймворке такого вопроса и не возникнет.
И не описан способ получения ссылки по интересующему роуту с передачей параметра, как это делается почти везде. Как в вашей системе получить ссылку на комментарий к созданному мной элементу каталога?
0

Они и есть консольные команды, просто формат для унификации аналогичен остальной маршрутизации.
CLI команд сейчас всего несколько, к примеру, очистить кэш можно следующим образом:


./cli clean_cache:System/optimization

Где clean_cache выступает в роли аналога HTTP метода, а System/optimization в роли аналога пути страницы.


Параметры командной строки превращаются в унифицированные параметры, доступные через привычный $Request->query(), аналогично параметрам после ? в URL:


./cli get:Module_name bool_param text_param="Some value"

./cli help:System выведет справку с доступными командами и форматом вызова (аналогично вызову ./cli без каких либо параметров).


Как в вашей системе получить ссылку на комментарий к созданному мной элементу каталога?

Увы, фреймворк ничего такого из коробки не предоставляет. Не знаю почему, но мне как-то даже не было нужно такое никогда. Можете уточнить для чего конкретно такое может быть нужно, что нельзя вручную сформировать ссылку? Интересно узнать сценарии использования.

0
Можете уточнить для чего конкретно такое может быть нужно, что нельзя вручную сформировать ссылку?

допустим, генерация ссылки на комментарий или на какую-либо страницу/раздел/статью/путь к api и т.п
Или же генерация ссылки для карты сайта
Генерация ссылки в шаблоне для почтовой рассылки. Много сценариев можно придумать, и переименование модуля не приведет к тому, что придется вручную переписывать уже захардкоженные ссылки во всех местах с их упоминанием.
Где clean_cache выступает в роли аналога HTTP метода, а System/optimization в роли аналога пути страницы.

Почему бы не сделать консольные команды по человечески, например:
/usr/bin/php /path/to/bin/console cache:clear //symfony
php app/cli.php main test world universe //phalcon
php artisan make:console SendEmails //laravel

В чем смысл именно такой реализации?
0

Во фреймворке нет очевидной связи между определённым маршрутом и моделью, к примеру, статьи. Соответственно, нет простого способа в общем виде ассоциировать какие-то сущности с маршрутами и обратно. В последнее время всё больше перехожу на подход API + по сути отдельное приложение на фронтенде, которое работает с API. В этом случае пути всё равно придется генерировать не на сервере. В общем, нужно будет над этим подумать.


Приведу команду к вашему формату:


/usr/bin/php /path/to/bin/console cache:clear //symfony
/usr/bin/php /path/to/bin/cli clean_cache:System/optimization //cleverstyle framework

Не вижу какой-то фундаментальной разницы. В то же время, в Symfony не так очевидно, какой код отвечает за команду, а в CleverStyle Framework я не смотря в код знаю, что за запрос отвечает статический метод cs\modules\System\cli\Controller::optimization_clean_cache().


Почему именно так? Мне это показалось весьма логичным и удобным (как в HTTP запросах: метод и цель), а в контексте остальной маршрутизации даже в некотором смысле очевидно. Вы выполняете операцию (clean_cache) над сущностью или в контексте определённого пути (System/optimization).


Если бы мы создавали статьи из командной строки, то у нас были бы методы get, post, delete и сущность Articles. То есть в формате Symfony получается articles:get, а здесь get:Articles, хотя суть та же.

0
/usr/bin/php /path/to/bin/cli clean_cache:System/optimization

в CleverStyle Framework я не смотря в код знаю, что за запрос отвечает статический метод cs\modules\System\cli\Controller::optimization_clean_cache()

Наверно потому что вы автор. Лично для меня связь не настолько явная.

0

Естественно, я имею ввиду что оно полностью ложится на конвенцию. Если понять несложный принцип, то всё сразу становится на свои места, не нужно изучать код и конфигурацию для того чтобы с почти 100% вероятностью узнать что будет происходить и где это искать.

0

Моки и стабы на используемый внешний код и вперёд. В инструментах для разработки самого фреймворка такие штуки уже есть готовые и активно используются, при желании можно любые собственные инструменты притащить.

0
А как сделать тогда кастомный рот без языкового префикса типо "/l/" и какой язык при этом будет выбран?
0

Есть события, с их помощью вы можете делать любые алиасы, которые вам только заблагорассудится.


Если не указывать язык в URL — будут взяты к сведению заголовки запроса. К примеру, Accept-Language если это браузер, так же поддерживаются заголовки, которые отправляет Facebook, когда встраивает preview в ленте (ему почему-то не хотелось стандартный Accept-Language применять).
Далее если и заголовков нет никаких — используется язык, сконфигурированный в настройках системы.
Так же если пользователь зарегистрирован и в профиле явно указан язык — он так же будет иметь бОльший вес, чем язык в заголовках и чем в настройках системы.


Но это уже не совсем к маршрутизации относится, это многоязычность, с которой тоже много все интересного происходит)

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