Comments 11
И как такое чудо вешать на крон?
Ни в одном популярном фреймворке такого вопроса и не возникнет.
И не описан способ получения ссылки по интересующему роуту с передачей параметра, как это делается почти везде. Как в вашей системе получить ссылку на комментарий к созданному мной элементу каталога?
Они и есть консольные команды, просто формат для унификации аналогичен остальной маршрутизации.
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 без каких либо параметров).
Как в вашей системе получить ссылку на комментарий к созданному мной элементу каталога?
Увы, фреймворк ничего такого из коробки не предоставляет. Не знаю почему, но мне как-то даже не было нужно такое никогда. Можете уточнить для чего конкретно такое может быть нужно, что нельзя вручную сформировать ссылку? Интересно узнать сценарии использования.
Можете уточнить для чего конкретно такое может быть нужно, что нельзя вручную сформировать ссылку?
допустим, генерация ссылки на комментарий или на какую-либо страницу/раздел/статью/путь к 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
В чем смысл именно такой реализации?
Во фреймворке нет очевидной связи между определённым маршрутом и моделью, к примеру, статьи. Соответственно, нет простого способа в общем виде ассоциировать какие-то сущности с маршрутами и обратно. В последнее время всё больше перехожу на подход 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, хотя суть та же.
/usr/bin/php /path/to/bin/cli clean_cache:System/optimization
в CleverStyle Framework я не смотря в код знаю, что за запрос отвечает статический метод cs\modules\System\cli\Controller::optimization_clean_cache()
Наверно потому что вы автор. Лично для меня связь не настолько явная.
Есть события, с их помощью вы можете делать любые алиасы, которые вам только заблагорассудится.
Если не указывать язык в URL — будут взяты к сведению заголовки запроса. К примеру, Accept-Language если это браузер, так же поддерживаются заголовки, которые отправляет Facebook, когда встраивает preview в ленте (ему почему-то не хотелось стандартный Accept-Language применять).
Далее если и заголовков нет никаких — используется язык, сконфигурированный в настройках системы.
Так же если пользователь зарегистрирован и в профиле явно указан язык — он так же будет иметь бОльший вес, чем язык в заголовках и чем в настройках системы.
Но это уже не совсем к маршрутизации относится, это многоязычность, с которой тоже много все интересного происходит)
Маршрутизация в CleverStyle Framework