Как структурировать добавление/удаление гибкой модели в базовой модели

Этот вопрос концептуальный, надеюсь, он не вызовет суеты.

Я новичок в Backbone, особенно когда приходится решать, что должно быть моделью, а что нет. Я пытаюсь сделать что-то похожее на поведение Trello, где одна карточка может или может не иметь набора функций пользовательского интерфейса, таких как контрольный список, срок выполнения, участники и так далее. Мой вопрос:

Может ли кто-нибудь предложить идеи о том, как структурировать отношение «карта» к «частям», что позволило бы мне добавлять/удалять отдельные компоненты из более крупного родителя. В настоящее время я представляю часть пользовательского интерфейса (то есть контрольный список) как собственную модель, но не знаю, как связать ее с родительской картой, которая, предположительно, также будет моделью.

Я разбираюсь в моделях, представлениях и коллекциях, но из-за неопытности у меня проблемы с делегированием того, какой компонент приложения должен быть, и как структурировать отношения. Я не ищу «правильный» ответ, поскольку подходы могут различаться, но в большей степени я ищу понимание того, как люди структурируют свои настройки и какая может быть обычная практика.


structure backbone.js conceptual backbone.js-collections
person Tey    schedule 30.04.2015    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Трудно дать хороший ответ, который был бы более определенным, чем «это зависит». Что касается пользовательского интерфейса, у вас, вероятно, будет родительское представление card, а затем представления, расширяющие представление card, например listCard, checkCard или textCard. Это позволяет вам СУШИТЬ с компонентами представления карты, которые остаются полезными для различных типов карточек (перетаскивание, удаление и т. д.), а также реализовать собственное поведение для каждого типа представления в подклассе представления (например, шаблоны или функциональные возможности интерфейса). ).

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

person Michael.Lumley    schedule 01.05.2015
comment
Итак, вот что меня сбило с толку в концепции Trello. Если карточки привязаны к явному типу (член, контрольный список), то ваш подход полностью работает, но Trello позволяет вам добавлять/удалять специальные расширения по своему усмотрению. Карта может иметь любое количество перестановок расширенных полей, и не кажется разумным делать каждую комбинацию расширенным классом. Это похоже на то, что они изменяют структуру данных карты на лету в зависимости от того, что пользователь хочет включить. - person Tey; 01.05.2015
comment
Для иллюстрации у меня может быть карточка [по умолчанию+участник] или [по умолчанию+участник+изображение], или [по умолчанию+контрольный список+изображение], или [по умолчанию+двузначная дата+контрольный список] — основные расширения: контрольный список/изображение/дведата... но вы можете добавить любую комбинацию из них на карту, что-то не так с созданием расширенного класса для учета каждой комбинации... ужас дублирования кода.... - person Tey; 01.05.2015

arrow_upward
0
arrow_downward

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

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

person Tey    schedule 04.05.2015