Как смоделировать редактирование нескольких связанных ресурсов на одной веб-странице? - PullRequest
2 голосов
/ 12 апреля 2010

Допустим, у нас есть модель компании, в которой много сотрудников и много проектов

Если мы хотим показать проекты, мы перейдем к
"/ Компания / 1 / проекты / индекс"

Если мы хотим отредактировать 1 проект, мы перейдем к
"/ Компании / 1 / проекты / 1 / редактировать"

Что если мы хотим отредактировать все проекты одновременно на одной веб-странице?
Мы можем перейти в «/ company / 1 / edit» и поместить вложенные формы для всех проектов

Но что, если нам понадобится другая веб-страница для редактирования всех сотрудников одновременно?
Мы не можем снова использовать "/ company / 1 / edit" ..

Сейчас мы делаем "/ company / 1 / projects / multiedit", "/ company / 1 / projects / multupdate" - но, как вы видите, это не отдых.

Как мы можем смоделировать это спокойно?

Ответы [ 3 ]

3 голосов
/ 12 апреля 2010

Ресурсы не управляют Дизайн интерфейса


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

Что если мы хотим отредактировать все проекты одновременно на одной веб-странице?

Тогда вы, вероятно, должны предоставить виджеты для каждого и POST каждое обновление последовательно. Вы можете использовать AJAX, чтобы сделать это приятным опытом для конечного пользователя

Сейчас мы делаем "/ company / 1 / projects / multiedit", "/ company / 1 / projects / multupdate" - но, как вы видите, это не отдых.

И это нормально, если вам не нужно быть RESTful - не так ли? Ваше приложение для внешнего использования или для внутреннего бизнес-процесса?

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

Если вы действительно чувствуете, что вам нужно быть RESTful, и если вы верите (как вы упомянули в комментарии ниже), что состояние всех проектов и сотрудников необходимо атомарно обновлять, тогда вам следует

1. Ввести новые контейнерные ресурсы «Сотрудники» и «Проекты», чтобы смоделировать связь между Компанией и набором «Сотрудник», а также между Компанией и набором «Проект».

2. В ответ на GET on Company вы должны включить URI для ресурсов «Сотрудники» и «Проекты» (т. Е. Всего два URI).

3. В ответ на GET для сотрудников или проектов вы должны либо вернуть состояние всех базовых ресурсов или URI для каждого, чтобы можно было определить их состояние.

4. При обновлении сотрудников вы должны переслать все состояние базовых ресурсов (предположительно, одним огромным). Новое государство полностью заменяет старое государство,

Этот последний шаг требует значительных затрат - вам следует пересмотреть ограничение на то, что это обновление «все или ничего». Помните, что это не имеет ничего общего с REST - то, что вы сделали, это выставили инвариант в вашей бизнес-логике интерфейсу сервиса .


Лично я бы:

1. сделать все возможное, чтобы удалить этот инвариант из уровня представления

2. моделировать ресурсы без вложенности - это более гибко, и REST ничего не может сказать о URI, за исключением того, что каждый ресурс должен иметь один

3. представить ресурсы сотрудников и проектов, чтобы смоделировать связь между компанией и сотрудником и проектом

4. попросите представительство компании вернуть URI для проектов и сотрудников (еще два).

5. каждый сотрудник и проектное представительство должны содержать соответствующую компанию

6. Разработайте пользовательский интерфейс, чтобы он мог отображать список проектов / сотрудников для компании и позволять обновлять каждый из них индивидуально.

7. Пакет всех POST вместе и отправлять их через AJAX на общую кнопку нажмите


Стоит взглянуть на великолепные скринкасты, которые Райан Бейтс сделал на вложенных ресурсах, но не забывайте, что вложенные ресурсы не являются основной частью REST - цитирую Роя Филдинга

Важно то, что каждый важный ресурс имеет URI, что позволяет получать представления этого ресурса с помощью GET.

Достаточно сказано - удачи! Chris

0 голосов
/ 12 апреля 2010

Я думаю, то, как вы делаете это сейчас, на самом деле очень хорошо. Изобретать искусственные ресурсы просто для того, чтобы соответствовать базовой схеме REST URL, мне не кажется правильным. Кроме того, в Rails есть коллекции и маршруты участников именно для добавления дополнительных действий, поэтому то, что вы делаете, соответствует философии Rails.

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

Есть ли у вас добросовестный ресурс, кроме компаний и проектов, которые должны обрабатывать несколько редакций и несколько обновлений? Думаю, нет. Но опять же, как и в случае с классами, иногда это вопрос мнения.

0 голосов
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...