JavaFX FXML, для чего Controller?

#java #javafx #controller #fxml

В уроках об FXML говорится об пользе и преимуществах разделения интерфейса и логики
в программах, но есть ещё непонятный мне класс "Controller" (помимо классов логики
и интерфейса) . В чём его идея, какую функцию он выполняет? В чём преимущество такого
подхода? 
    

Ответы

Ответ 1

Возможно, Вам будет интересно мое мнение:

Лично я считаю, что термин "controller" в документации FXML следует воспринимать
не более, чем то, что в других технологиях называется "code behind".

То есть это просто дополнительный код для выполнения задач связанных с отображением
"вида" (view). (Под "видом" я здесь имею в виду конкретный участок пользовательского
интерфейса).

FXMLLoader с помощью инъекций связывает объект контроллера с деревом объектов,
которое он нагенерил по fxml-разметке. А также предоставляет некоторые другие 
возможности, например, одностороннюю привязку ("${expression}") атрибутов-свойств
и прочее.

Но вот, к примеру, двусторонняя привязка ("#{...}") FXMLLoader'ом так до сих пор
не реализована,
и класс контроллера — это как раз подходящее место для ее описания.

Без сомнения, то, что будет в этом "code behind" полностью зависит от вашего подхода
и самодисциплины.
Как со стороны размещения бизнес-логики, так и со стороны разделения зон ответственности
программиста и дизайнера.

Именно Вам решать, будет ли этот класс толстым носителем логики, или лишь тонкой
прослойкой между моделью и видом.

При этом, даже, если вы будуте использовать какой-то определенный фреймворк (например,
mvvmFx),
то это не спасет вас от возможности ошибочно разместить часть бизнес-логики модели
в "code behind"
определенного вида (эта ошибка может и обнаружится, когда такая функциональность
потребуется в другом месте).

С другой стороны, помня о том, что css-стили (кроме USER_AGENT) имеют определенное
преимущество над JavaFx-свойствами узлов, 
в контроллере имеет смысл описывать настройки интерфейса с помощью JavaFx-свойств,
а не заданием css-стилей —
для того, чтобы дизайнер впоследствии смог исправить интерфейс указанием css-стилей.
И даже в этом случае программист может сказать свое "последнее слово", восстанавливая
значение свойства в обработчике изменения этого свойства ;)



Под словами "определенное преимущество" я имею ввиду то, что 
css-стиль перекрывает соответствующее ему свойство. Но только в момент
перепроверки стилей. А до этой перепроверки будет действовать свойство.
Например, можно установить какое-либо свойство узлу (в обработчике нажатия другой
кнопки) и это будет отражено на экране, но при наведении на узел курсора мыши, узлу
устанавливается
псевдокласс hover и выполняется переустановка его стилей в соответствии
с псевдоклассом, тем самым свойство будет заменено стилем. После того, 
как курсор мыши будет убран с узла, у него будет также убран псевдокласс hover. Это
изменение псевдоклассов опять повлечет переустановку стилей узла, но в этих стилях
не указано то изменение, которое делалось для свойства в обработчике. Поэтому свойство
на экране отражено не будет, хотя оно и работало вначале некоторое время.