Должна ли вся логика взгляда идти в шаблонах?

Question

Например, мне нужно отключить каждый вход, если модель представления не является новой (имеет идентификатор).

я могу сделать:

if(!view.model.isNew()) { view.$('input, select, textarea').prop('disabled', true); }

или я могу пойти и сделать «если» на каждом входе у меня есть в моем шаблоне:

<input type="text" {{# if model.id }}disabled{{/ if }}/> 

Если мы следуем MVC (или MVP), я думаю, что второй подход был бы лучшим, поскольку логика представления находится в представлении. Однако, если я пойду с этим подходом и решит изменить условие, которое отключает входы, мне нужно изменить его для каждого входа в КАЖДОМ-шаблоне. Если я останусь в JS-коде, меняет только одно место.

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

Cheers!

Answer 1

Я предпочитаю делать реализовать вид логики в шаблонах:

1. Это проще изменить и читать
2. Любая зависимость к Ид, элемент и т.д. могут быть реализованы в шаблоне
3. Элемент списка
4. сложная логика может быть реализована в templateHelper марионетки или serializeData базовой линии без каких-либо зависимостей от содержимого шаблона или представления
5. вы также можете реализовать сложную логику с помощью Hand Lebar Helper

Недостатков зрения логики в коде:

1. в случае внесения изменений в селекторы (ID, классы и так), все виды должны быть изменены или рассмотрены
2. логики должен применяться еще раз, если точка зрения вновь оказывается

Answer 2

Основываясь на ваш вопрос, я бы сказал, что вы, вероятно, работает в этой общей задачи по двум взаимосвязанным причинам -

1. Вы используете основную основу исключительно, а не каркас, такой как Marionette или Chaplin.
2. Ваши взгляды «слишком велики» и пытаются включить слишком много материала в единый вид.

Я почти никогда не включаю логику в шаблоны, и это потому, что мне почти никогда не нужно. Это потому, что я написать много очень маленьких просмотров, и их вместе, чтобы сделать большие виды. Marionette'sviewclasses сделать это очень легко сделать, по subclassing the backbone view into different view types, добавив дополнительные утилиты и резкое сокращение на шаблоне. Marionette также очень хорошо справляется с вложенными представлениями, что действительно позволяет вам развернуть и создать точный инструмент просмотра, который вам нужен для конкретного варианта использования.

Невозможно определить полезный вид с помощью Marionette в 1-2 строках кода, что дает вам большую гибкость, чтобы сделать очень маленькие, эффективные виды. Недостатком создания большого количества мелких просмотров является то, что для написания кода очень много кода, и его может стать трудно поддерживать, но Marionette makes that disadvantage relatively insignificant. Мэрионетта заняла у меня всего пару дней, чтобы получить поддержку, и я настоятельно рекомендую интегрировать ее в свои приложения с базой данных именно для этой проблемы.

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

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

editableView = { //definition }} 
disabledView = { //definition }} 

if (newModel) 
    editableView.render() 
else 
    disabledView.render() 

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

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

ПРИМЕЧАНИЕ: В этом ответе я много говорил о марионетке, но я также упомянул Чаплина как еще один вариант выше. У меня нет большого опыта работы с Чаплином, но вы можете рассмотреть его как альтернативу марионетке.

Answer 3

Возможно, что вы ищете presenter (aka decorator).

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

present = function(model) { 
    return { 
    inputAttributes: model.isNew() ? 'disabled' : '', 
    id: model.id, 
    name: 'Foobar' 
    } 
} 

template(present(model)); 

затем в шаблоне:

<input type="text" {{inputAttributes}}>