Page Routing: Нужна информация о "современном подоходе"

[Voral]

Статья про роутинг

Используйте PublicPageController только для миграции со старого движка маршрутизации .... В остальных случаях применяйте контроллеры.

Хотелось бы видеть в документации (а в этом примечании соответствующую ссылку). Как делать правильно. Ведь допустим сейчас на проекте есть некая страница на которой лежит: верстка и пара компонентов. И какой путь "конвертации"? Чтоб не гадать и не плодилось разных подходов на разных проектах - раскрыть бы эту тему в документации. Как это видит вендор.

Возможно даже в этой же статье в примерах выше дать пример который показывает упрощено "вот ваша страница раньше теперь будет так"

[cyber-jet]

Уже отписал в похожей теме - #97 (comment)

Прописать новый роутинг в .htaccess можно уже сейчас если версия 21.400.0. или выше, там есть обратная совместимость, и в этом даже можно убедиться, прочитав код в routing_index.php

PS: Вообще архитектурно новый роутинг для контроллеров это прямо глоток свежего воздуха для bitrix, остаётся только вопрос почему так долго, если это уже давно есть в других фреймворках.

[Voral]

Ну тут я скорее о полноте документации. Реальный пример: Новый роутинг я использую давно, но все как АПИ. А тут задача сделать новый шаблон и решил опробовать (благодаря тому ишью) перенести все на роутинг.. И вон как бы из документации уже следует, что надо отказываться от старых подходов, но не дает ответа как.

Т.е. именно как сам роутинг как таковой задействовать понятно. Не понятно как реализовать полноценную замену для PublicPageController. (даже без эрмитажа)

[cyber-jet]

А тут задача сделать новый шаблон и решил опробовать... перенести все на роутинг

Можно, а зачем? В том смысле, что это даст в парадигме Bitrix CMS, частью которой являются шаблоны компонентов, а следовательно компоненты, а следовательно то что они пишут в urlrewrite.php? Примеры роутинга в документации есть и они исчерпывающие, какие ещё нужны?

[Voral]

Ок. Предположим имеем сейчас /blog/index.php в котором: HTML, ComponentA, HTML, ComponentB. Как переходный вариант согласно документации PublicPageController и этот index.php подключаем. Но мы хотим уже не переходный, а на контроллерах. Где пример как поступить правильно? Предположим теперь надо сделать комплексный компонент повторяющий этот код... ок... Но даже для одиночного компонента где исчерпывающий пример?

Все это (внедрение контроллеров) похоже на движение к единой точке входа. Вполне логично, что постепенно убирать файлы /blog/index.php и заменять на прописывание их маршрутами в файлах роутинга. (к тому же urlrewrite уже точно направление на его выпиливание).

Возможно я не внимательно где то прочитал. Можете указать где об этом в документации. Раз в ней явно написана рекомендация переходить на контроллеры?

Если я не прав в своем пожелании, то для чего вообще это примечание про PublicPageController

[cyber-jet]

Ещё раз, для невнимательных, есть Bitrix framework и есть Bitrix CMS, и это разные разделы документации.

[Voral]

Ещё раз, для невнимательных, есть Bitrix framework и есть Bitrix CMS, и это разные разделы документации.

Не понятно в чем проблема и о чем спор?

Попробуйте подойти как человек который ищет в документации ответы на вопросы. Документация сказала А. Но не сказала Б. Даже если это другая документация - можно дать ссылку и на другую документацию. Да хотя бы упомянуть где искать ответ. Или в этом примечании не про cms? А просто некая миграция между чем то и чем то :)

Кроме того: обратите внимание в этой документации есть раздел "Основы cms" есть статья про инфоблоки...

Более того это действительно важно. Все это, на мой взгляд, однажды позволит убрать все кроме единой точки входа за пределы корня сайта (как пример).

[morvit]

Ещё раз, для невнимательных, есть Bitrix framework и есть Bitrix CMS, и это разные разделы документации.

На практике framework и cms используются вместе (и вряд ли когда-либо будут существовать отдельно), поэтому нужен единый понятный подход.

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

Было бы полезно:

• явно это зафиксировать в документации
• дать пример реализации публичных страниц с новым роутингом

Сейчас как раз не хватает вендорского примера для таких кейсов.

Отдельное пожелание (исходя из первого абзаца): рассмотреть поддержку хотя бы базовых edit area (аналог AddEditAction / AddDeleteAction) при использовании renderView в публичной части.

[cyber-jet]

На практике framework и cms используются вместе...

CMS написана на вреймворке, по другому быть не может.

Куда ещё явнее это фиксировать, если одно находится в разделе "Основы фреймворка" а второе в "Основы CMS". Кэп подсказывает что "edit area" это CMS (Content Management System).

[morvit]

Кэп

Очевидно - это про разделение. Неочевидно - про использование.

[irpsv]

Всем привет)

Предположим теперь надо сделать комплексный компонент повторяющий этот код... ок... Но даже для одиночного компонента где исчерпывающий пример?

Комплексный компонент по сути тоже плохой пример (если мы говорим про новый код, старый типа каталожные компоненты можно использовать за неимением альтернативы). В данном случае можно сделать "view" и в него как есть перенести текущее содержимое страницы за исключением хедера футера. Но в данном случае будут вопросы по эрмитажу (это проблема продукта, а не доки, сам подход верный). Согласен что стоит дополнить доку как нужно действовать в этой ситуации.

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

Зависит от вашей публичной части, если вам эрмитаж не нужен, то вполне вьюхи решат вашу проблему. Согласен, что ограниченность эрмитажа это проблема. Этот момент у нас зафиксирован, будем решать.

[cyber-jet]

Ещё раз. Уточните пожалуйста проблему, потому что роутинг, контроллеры, вью, это всё относится к фреймворку Битрикс. Где тут компоненты, эрмитаж и шаблоны? RenderView отдает прямо из контроллера html, как это вписывается в CMS Битрикс с его эрмитажем, блэкджеком и системой шаблонов?

PS: комплексный компонент нужен только чтобы комплексно кешировать его результаты.

[irpsv]

Почему вы делите фреймворк и CMS? Использование контроллеров и роутинга, НЕ означает отключения всех функций CMS и возможность их использования.

[cyber-jet]

Почему вы делите фреймворк и CMS? Использование контроллеров и роутинга, НЕ означает отключения всех функций CMS и возможность их использования.

Я ни чего не делю, а просто смотрю на уровень абстракции, и у вас в доке это разные разделы, что в принципе правильно. Эрмитаж, и в частности визуальный редактор, который позволяет настраивать компоненты на странице без знаний программирования, в том числе использовать систему шаблонов и всё что с ними связанное, задавать режим SEF, который автоматом при сохранении страницы пишет правило в urlrewrite.php, через который осуществляется роутинг уровня компонентов, это всё относится к CMS. Да можно сделать сontrollerable компонент, работать с ним асинхронно, но на этом в принципе всё, это совсем не то-же самое что RenderView абстракции уровня "модуль", у компонента есть свои методы вывода html, и возможность передать входящие параметры компонента, потому что ajax.php не знает где расположен компонент и какие у него параметры.

Роутинг это скорее restful api(GET, POST, PUT, DELETE), или для обработки запросов с фронта, например от vue или react. Если честно не приходит в голову рабочий сценарий где эти подходы нужно было бы совместить с возможностями визуального редактирования интерфейса эрмитаж. Исходя из этого прикидываю, что если нужно что-то сделать редактируемым визуально на странице, делается компонент, в нем пишется обработчик для запросов на редактирование с визуальной части, роутинг и RenderView для этого не нужны.

PS: Если предположить что страницы целиком будут собираться и отдаваться RenderView, это же совсем другая история, не "канон" для Битрикс, где изначально вся структура сайта построена на файлах.