Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 8
Вот честно, затея цикла публикаций может и хорошая, но реализация ни о чём: ни одна затронутая тема не раскрыта в достаточном объёме. Прочитал и не понял что хотел сказать автор и кто есть целевая аудитория. Новичкам слишком мало данных, а более опытным людям — слишком скучно и очевидно.
Теперь по порядку:
Теперь по порядку:
- «отображение уведомлений» — не является задачами контроллера, это задачи объекта. В контексте системы всегда должен быть целевой объект или группа объектов, с которыми работает пользователь. Именно эти объекты и должны хранить в себе сообщения. Можно сходить в тот же simple_form и посмотреть как замечательно всё работает без участия контроллера. В более продвинутом случае за валидации и сообщения от них должен отвечать отдельный обработчик (привет Trailblazer).
- Пример со статусами проекта наигран: кто мешает добавить state_machine и пользоваться формой edit/update для проекта сохраняя RESTfull?
- С орзанизацией контроллеров — это палка о двух концах: получается отдельные контроллеры, но лишаетесь единообразных урлов, то есть не получится обратиться к "/user/1/posts", "/user/1/posts.old_api", "/user/1/posts.new_api2" и тп. Альтернатива — модули в namespace целевого контроллера, например, User::OldApi. И далее при помощи метапрограммирования можно сделать красивые конструкции из `respond_with` с различными `format`.
- Про хлебные крошки вообще не понятно… Что пробовали? Чем не понравилось? Чем своя реализация лучше всех прочих?
> не получится обратиться к "/user/1/posts", "/user/1/posts.old_api", "/user/1/posts.new_api2"
Если так делать, в контролере придется хранить код на 3+ реализации апи. А это, рано или поздно — конфликты имен и функционала. По-моему, если решили делать новую версию апи, то лучше сразу в отдельный нэймспэйс вынести, а старый код оставить как есть. А если проект с нуля, то такой подход, просто избавит от этих проблем в будущем.
Мы только используем
Если так делать, в контролере придется хранить код на 3+ реализации апи. А это, рано или поздно — конфликты имен и функционала. По-моему, если решили делать новую версию апи, то лучше сразу в отдельный нэймспэйс вынести, а старый код оставить как есть. А если проект с нуля, то такой подход, просто избавит от этих проблем в будущем.
Мы только используем
namespace: :site вместо scope module: :web. Так урл-хэлперы будут с префиксами, и вызовы их яснее: можно ошибиться и написать в админке form_for user / link_to user / user_path вместо form_for [:admin, user] / link_to [:admin, user] / admin_user_path. Вариант с нэймспэйсом просто выдаст ошибку, а со скоупом — вернёт неверный урл. Вроде бы был ещё какой-то тонкий момент связанный с этим, но сейчас не вспомнил.
> Вот честно, затея цикла публикаций может и хорошая, но реализация ни о чём: ни одна затронутая тема не раскрыта в достаточном объёме. Прочитал и не понял что хотел сказать автор и кто есть целевая аудитория. Новичкам слишком мало данных, а более опытным людям — слишком скучно и очевидно.
Спасибо за отзыв. У меня нет большого опыта в написании статей. Если у кого-то есть желание и время помочь в написании статей о rails, то я всегда открыт предложениям. Можно, например, по очереди публиковать статьи или проставлять ссылки на профиль.
> «отображение уведомлений»
тут имелись в виду flash и сообщения об ошибках-исключениях
> Пример со статусами проекта наигран
Естественно используется стейтмашина. Пример о том, что при завершении проекта нужно заполнить дополнительные поля. В форме редактирования проекта этих полей быть не должно. В примере кода все показано.
> С орзанизацией контроллеров
Тут нужно посмотреть на вашу ситуацию. Моя методика взята из статьи habrahabr.ru/post/136461. Я ее применяю на протяжении 3х лет и ни разу мои контроллеры не распухали. Метапрограммирование тоже полка о двух концах, с ним нужно быть аккуратным.
> Про хлебные крошки вообще не понятно…
Пробовал все гемы, которые нашел на github(их штук 5).
Они как я писал в статье, они все запрашивают слишком много данных. Моя реализация требует указания только самого необходимого. Все, что она может получить самостоятельно — получает сама. Например, по имени контроллера из локали получает заголовок, по названию action так же получает заголовок.
Спасибо за отзыв. У меня нет большого опыта в написании статей. Если у кого-то есть желание и время помочь в написании статей о rails, то я всегда открыт предложениям. Можно, например, по очереди публиковать статьи или проставлять ссылки на профиль.
> «отображение уведомлений»
тут имелись в виду flash и сообщения об ошибках-исключениях
> Пример со статусами проекта наигран
Естественно используется стейтмашина. Пример о том, что при завершении проекта нужно заполнить дополнительные поля. В форме редактирования проекта этих полей быть не должно. В примере кода все показано.
> С орзанизацией контроллеров
Тут нужно посмотреть на вашу ситуацию. Моя методика взята из статьи habrahabr.ru/post/136461. Я ее применяю на протяжении 3х лет и ни разу мои контроллеры не распухали. Метапрограммирование тоже полка о двух концах, с ним нужно быть аккуратным.
> Про хлебные крошки вообще не понятно…
Пробовал все гемы, которые нашел на github(их штук 5).
Они как я писал в статье, они все запрашивают слишком много данных. Моя реализация требует указания только самого необходимого. Все, что она может получить самостоятельно — получает сама. Например, по имени контроллера из локали получает заголовок, по названию action так же получает заголовок.
Без inherited_resources управление вложенными ресурсами рано или поздно превратится в муку.
По-хорошему API и Frontend должны быть в разных изолированных движках, и уже потом монтироваться в приложуху. В таком случае можно разделить гемы на более реальные группы и загружать движки в отдельных воркерах без ненужных модулей. Я не настолько маньячу и держу модели общими, некоторые, кто такой же стратегии придерживаются, разделяют и их тоже.
Зачем в этом топике про хлебные крошки, я так и не понял, но раньше тоже изобретал велосипед пока не наткнулся на https://github.com/lassebunk/gretel. Оно может и требует небольшого допила, но, в целом, способ, на мой взгляд, элегантный, и не требует залазить с хлебными крошками в контроллер, где им явно не место.
А еще, я слышал, что если использовать нераскрытые неймспейсы в названиях классов, то боженька покарает.
По-хорошему API и Frontend должны быть в разных изолированных движках, и уже потом монтироваться в приложуху. В таком случае можно разделить гемы на более реальные группы и загружать движки в отдельных воркерах без ненужных модулей. Я не настолько маньячу и держу модели общими, некоторые, кто такой же стратегии придерживаются, разделяют и их тоже.
Зачем в этом топике про хлебные крошки, я так и не понял, но раньше тоже изобретал велосипед пока не наткнулся на https://github.com/lassebunk/gretel. Оно может и требует небольшого допила, но, в целом, способ, на мой взгляд, элегантный, и не требует залазить с хлебными крошками в контроллер, где им явно не место.
А еще, я слышал, что если использовать нераскрытые неймспейсы в названиях классов, то боженька покарает.
Скажите пожалуйста, а как вписывается в REST личный кабинет пользователя но без id в адресе?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление сложностью в проектах на ruby on rails. Часть 2