В моей предыдущей статье я ссылался на блог Кая, где различные члены сообщества хотели использовать более простой API привязки данных и просили дать комментарии.
Этот блог предназначен для сбора различных предложений по упрощению привязки данных в одном месте, чтобы мы могли обсудить их относительные достоинства.
Сначала я изложу свои личные предубеждения.
-
Хотя я нахожу это немного многословным, мне все еще очень нравится существующий API привязки
данных . Это потому, что любой другой
API, который я пробовал, налагал предположения о том, что я хотел сделать, что в конечном итоге слишком ограничивало меня.
-
Учитывая предыдущее, я предпочитаю сохранить существующий
API и рассматривать его как язык ассемблера для привязок.
-
Легко представить себе удобный слой, добавленный поверх существующего кода; Таким образом, если вам нужна полная мощность привязки данных, вы переходите на более низкий уровень абстракции.
Во-вторых, каковы различные способы повышения уровня абстракции?
Имеет два набора виджетов интерфейса: несвязанные и связанные виджеты
Сами привязываемые виджеты обладают интеллектом, необходимым для их связывания.
Мне не нравится этот подход по нескольким причинам.
-
С точки зрения сообщества это вынуждает авторов виджетов SWT создавать две версии каждого виджета: обычную и привязываемую.
-
Привязываемый виджет почти всегда делает предположения о видах вещей, которые вы можете захотеть связать с ним. Например, элементы управления таблицами в мире Microsoft, по крайней мере, раньше предполагали, что вы привязывались к курсору базы данных. Android (который также использует подход связываемых виджетов) несколько решает эту проблему, позволяя вам реализовать свой собственный курсор базы данных.
-
В конце концов, это не похоже на оптимальное разделение интересов. При чтении
API для элемента управления вы должны иметь в виду, что API для работы с самим элементом управления смешиваются с API для привязки к нему. Результатом является менее намеренный
API в самом элементе управления.
Слой внешнего DSL поверх привязки данных
Это подход таких вещей, как Beans Binding, а также несколько известных языков сценариев, таких как Perl и Ruby.
Люди хотели бы написать что-то вроде:
String someOutput = "Hello, my name is ${person.firstName} ${person.lastName}";
Или (из ошибки 195222 ):
BeanObservables.observeValue(person,"parents[@mother=true]/person/name");
Моя личная мысль здесь такова:
-
Это было бы очень приятно
-
Было бы трудно правильно кодировать
-
В идеале вам нужна поддержка IDE, расширяющая проверку статических типов Java на этот встроенный язык запросов на основе строк.
В принципе, мне это нравится, но это звучит как большая работа.
Реализация внутреннего DSL для упрощения привязки
Используя шаблон Builder, можно легко представить что-то вроде:
IValueProperty objectAddressStreet = BeanPropertyBuilder.value("address").value("street").build();
Больше мыслей в этом направлении — ошибка 195222 и ошибка 194734
Открытые вопросы
Кто-то из списка разработчиков E4 (извините, мне лень искать, кто это сказал) пожаловался, что проблема привязки данных заключается в том, что она связывает поток данных с рабочим процессом пользователя.
Другими словами, это непосредственно представляет поток данных в наблюдаемых и привязке:
dbc.bind(SWTObservables.observeText(txtFirstName, SWT.FocusOut),
BeansObservables.observeProperty(person, "firstName"), null, null);
Но если вам нужно изменить рабочий процесс пользователя, например, с помощью проверки, тогда этот код проверки становится сквозной задачей для всех ваших привязок.
Однако, если кто-то не использует что-то вроде AspectJ, это кажется мне существенной сложностью.
Кто-нибудь, пожалуйста, докажите, что я не прав.
От http://www.coconut-palm-software.com/the_new_visual_editor/doku.php?id=blog