Сколько логики необходимо вставить класс UI?
Просто решено! Кажется, что вам нужно указать варианты как пустой список или список с формой [(a, b)] (список кортежей), чтобы он работал. Я изменил код, чтобы он был похож на
default_timezone = SelectField('Default Time Zone', validators=[DataRequired()],
choices=[(x, x) for x in pytz.common_timezones])
, и это решает проблему.
8 ответов
Просто логика, имеющая дело с UI.
Иногда люди пытаются поместить даже это в уровень Business. Например, можно было бы иметь в их BL:
if (totalAmount < 0)
color = "RED";
else
color = "BLACK";
И в UI отображают totalAmount, использующий цвет - который является абсолютно неправильным. Это должно быть:
if (totalAmount < 0)
isNegative = true;
else
isNegative = false;
И это должно быть полностью до уровня UI, как totalAmount должен быть отображен, когда isNegative верен.
Я предлагаю, чтобы UI не должен был включать вид бизнес-логики. Даже проверки. Они все должны быть на уровне бизнес-логики. Таким образом Вы делаете своего независимого политика BLL UI. Можно легко преобразовать Вас приложение Windows в веб-приложение или веб-сервисы и наоборот. Можно использовать объектные платформы как Csla для достижения этого.
Как можно меньше... UI должен только иметь логику, связанную с презентацией. Мое персональное предпочтение теперь состоит в том, чтобы иметь UI/представление
- просто сгенерируйте события (с иллюстрирующими материалами) к PresenterClass, заявив, что что-то произошло. Позвольте Предъявителю ответить на событие.
- имейте методы для представления/отображения данных, которые будут представлены
- минимальный объем клиентских проверок, чтобы помочь пользователю добраться это исправляется в первый раз... (предпочтительно сделанный декларативным способом) экранирующий от недопустимых исходных данных, прежде чем это даже достигнет предъявителя, например, удостоверьтесь, что значение текстового поля в диапазоне a-b путем установки минуты и макс. свойств.
http://martinfowler.com/eaaDev/uiArchs.html описывает эволюцию дизайна UI. Выборка
Когда люди говорят о самотестировании пользовательских интерфейсов кода, быстро поднимают их голову как проблему. Многие люди находят что, тестируя графический интерфейсы пользователя, чтобы быть где-нибудь между жестким и невозможным. Это в основном, потому что UIs сильно связываются в полную среду UI и трудные дразнить независимо и протестировать в частях. Но существуют случаи, где это невозможно, Вы пропускаете важные взаимодействия, там распараллеливают проблемы, и тесты также не спешат работать.
В результате было устойчивое перемещение для разработки UIs таким способом, который минимизирует поведение в объектах, которые неудобно протестировать. Michael Feathers решительно подвел итог этого подхода в Скромном Диалоговом окне. Gerard Meszaros обобщил это понятие к идее Скромного Объекта - любой объект, который трудно протестировать, должен иметь минимальное поведение. Тот путь, если мы не можем включать его в наши наборы тестов, мы сводим к минимуму вероятность необнаруженного отказа.
Шаблоном, который Вы ищете, может быть Образцовый контроллер представления, который в основном разделяет DB (модель) от GUI (представление) и логика (контроллер). Вот Jeff Atwood, берут это. Я полагаю, что не нужно быть фанатичным ни о какой платформе, языке или шаблоне - В то время как тяжелые числовые вычисления, вероятно, не должны находиться в GUI, хорошо делать некоторый основной контроль ввода и производить форматирование там.
Контроль ввода присоединяется к управлению. Как электронные письма, возраст, блоки проверки допустимости даты с текстовыми полями
James корректен. Как показывает опыт, Ваша бизнес-логика не должна делать предположение относительно презентации.
Что, если Вы планируете отображение Ваших результатов на различных медиа? Один из них мог быть черно-белым принтером. "КРАСНЫЙ" не сократил бы его.
Когда я создаю модель или даже контроллер, я пытаюсь убедить меня, что пользовательский интерфейс будет пеной для ванн. Верьте мне, который существенно уменьшает сумму HTML в моем коде ;)
Всегда помещайте минимальное количество логики, возможной в любом слое, Вы работаете.
Этим я имею в виду, если Вы добавляете код к уровню UI, добавьте наименьшее количество суммы логики, необходимой, чтобы тот слой работал, это - UI (только) операции.
Не только делает выполнение того результата в хорошем разделении слоев... это также сохраняет Вас от чрезмерного увеличения размера кода.
Я уже записал 'совместимый' ответ на этот вопрос здесь. Правило (согласно мне), что не должно быть никакой логики в UI кроме логики UI и призывает к стандартным процедурам, которые будут управлять универсальными / конкретными случаями.
В нашей ситуации мы приехали в точку, где код формы автоматически сгенерирован из списка средств управления, доступных на форме. В зависимости от вида управления (bound text, bound boolean, bound number, bound combobox, unbound label, ...), мы автоматически генерируем ряд процедур обработки событий (такой как beforeUpdate и afterUpdate для текстовых средств управления, onClick для маркировок, и т.д.), что общий код запуска, расположенный из формы.
Этот код может затем или сделать универсальные вещи (тест, если значение поля может быть обновлено в beforeUpdate событие, закажите recordset, возрастающий/убывающий в onClick событие, и т.д.) или определенные обработки на основе формы и/или имя управления (делающий, например, некоторую работу в a afterUpdate событие, такое как вычисление значения totalAmount управляют из unitPrice и значений количества).
Наша система теперь полностью автоматизирована, и производство формы полагается на две таблицы: Tbl_Form для списка форм, доступных в приложении, и Tbl_Control для списка средств управления, доступных в наших формах
После ответа, на который ссылаются, и других сообщений в Так, некоторые пользователи попросили, чтобы я разработал на моих идеях. Поскольку предмет довольно сложен, я наконец решил открыть блог для разговора об этой логике UI. Я уже начал говорить об интерфейсе UI, но могло бы потребоваться несколько дней (.. недели!), пока я не могу конкретно достигнуть предмета, которым Вы интересуетесь.