25 марта 2017 в 0:48
Решил изучить принципы построения сайтов по принципу headless-Drupal. Не могу понять, как лучше получить меню? Установил rest_menu_items и rest_menu_tree. Получил приблизительно такую картину:
Смущает, что в первом варианте есть параметры
"meta_data":{"entity_id":"453"},"delete_route":{},"edit_route":{}},
вроде пустые, но закрадывается сомнение в безопасности.
Второй вариант почему-то возвращает не все пункты меню.
Третий вообще возвращает не пункты меню, а описание и название меню.
Думаю, я не первый задался этим вопросом, поэтому надеюсь, кто-нибудь поделится опытом.
ЗЫ: как вариант, подойдёт любой пример вменяемого сайта на headless-Drupal 8 - поковыряю его респонсы в девтузах, может пойму что-то))
| Вложение | Размер |
|---|---|
 rest-menus.png | 44.92 КБ |
Комментарии
https://www.youtube.com/playlist?list=PLUBR53Dw-Ef9Rr-bjMlosZclKLtPK4HhR
Спасибо за ссылку, много интересного. Но у этого чувака в видосах на странице нет ни одной менюшки. Соответственно, по моему вопросу там ничего нет.
Если что, мне не надо рассказывать про роутинг. Мне нужно просто получить список ссылок меню.
тут тебе решать, насколько целесообразно в headless drupal использовать menu-ui
ладно бы данные, но меню то в апи зачем?
имхо.
ты ведь щелкаешь мышкой модель данных в дру (со всеми полями связями правами),
и для нее - строишь апи для фронта.
меню - это фронт, зачем там меню дру?
Ты предлагаешь захардкодить в шаблон все пункты меню? Или как?
да,
на базе дру организовать api
а фронт приложение строить так, как тебе необходимо.
но это имхо.
повторюсь, выбор примерно следующий:
http://buytaert.net/should-we-decouple-drupal-with-a-client-side-framework
Ну это же бред какой-то. Вот прикинь, есть навигационное меню с пунктами личный кабинет, мои заказы, справка, контакты. И вдруг надо туда впереть ссылку на страницу "публичная оферта". И что? Шаблоны править? Бред же. Так или иначе, список пунктов меню должен лежать в бэкэнде.
вот опять "бред", "должен"...
это подход нуба, не инженера - ты пробуй, сравнивай, и бери оптимальный вариант)))
по мне - если разделяешь бек и фронт, начни с полного разделения.
иначе - ты себя просто изначально загоняешь в рамки.
И опять же, то, что я собираюсь делать, полностью соответствует правой картинке. Список ссылок меню - это данные. И рендерить их я буду на клиенте.
)))
и у этих, с json_api менюшек друпальных нет...
https://www.youtube.com/playlist?list=PLZOQ_ZMpYrZsyO-3IstImK1okrpfAjuMZ
Как же так!
api вообще не должна кандубасить маршрутизация фронт,
фронту пох что думает api о его маршрутизации
Хотел задать вопрос, но пока писал понял.
И что же именно ты понял?))
Да появился тот же вопрос, как мне получать список меню. Но после комментов x..лиgаna, осознание прочтённого пришло с задержкой:-)
Я тебе по секрету скажу, что хулиган и мультпикс по этой теме дальше хэллоуорлда не зашли))
ээ..
дажи хелоуорда не было))))
Тем более))
Представь себе, я до сих пор на 100 процентов уверен, что я прав.
со временем все поймешь, не торопи события)))
суть в том, что друпаловские сервисы это далеко не единственный, и уж точно не самый лучший способ организовать данные и апи для доступа к ним.
это просто возможность - сделать бек на дру? да - можно.
нужно как минимум попробовать что-то иное, чтоб знать, чего вообще хотеть))))
Суть в том, что для несферических ситуаций любые готовые решения ведут к ограничениям и проблемам. Классический REST-подход (один эндпоинт - один тип данных) ведёт к большой связности кода. В JSON-API - есть свои ограничения - он не умеет собирать обратные референсы и не умеет делать агрегацию. Естественно, я сейчас не про друпал, а вообще. Надо ещё посмотреть GraphQL - если он умеет обратные референсы и агрегации, то можно смело отказываться от всех остальных методик, хотя думаю вряд ли. И придётся по-прежнему лепить приложения из всего подряд.
В любой многопользовательской и мало-мальски сложной системе фронт ведёт себя сообразно ситуации и данные перед отправкой с фронта или после приёма с фронта валидируются и проверяются права доступа. Именно поэтому зайдя в фэйсбук я вижу ссылки для администрирования страниц, которые я создал, а больше их никто не видит. И изначально эти данные находятся в бэке, и они являются для фронта управляющими.
Сущности да. Но не едиными сущностями живут приложения. Помимо сущностей есть ещё действия, права доступа и информация о структуре сущностей, необходимая для генерации форм создания и редактирования тех же сущностей.
так к чему пришли то по итогу?
По итогу когда дело дошло до живых проектов, все менюшки были захардкожены в конфигурационных файлах на фронте. Специфика проектов позволяла это. Но думаю, если надо будет всё-таки реализовать задачу, то посмотрю ещё раз упомянутые модули или напишу свой рест-эндпоинт.