Когда использовать вызовы параметризованных методов, представленные в EL 2.2 (особенно в JSF 2.x)?

В прошлом я использовал множество методов получения и установки, чтобы переместить как можно больше логической логики из файлов фейслета в компоненты поддержки JSF. Таким образом, интерфейс представления был задан методами получения и установки его вспомогательного bean-компонента, а также методами действия вспомогательного bean-компонента. Преимущество этого подхода состоит в том, что файлы фейсов не содержат логики и, следовательно, вся логика находится в поддерживающих bean-компонентах и ​​может быть протестирована на единицу.

Но с EL 2.2 стал возможен другой стиль программирования. В EL 2.2 вы можете вызывать методы с такими выражениями, как

#{bean.collection.size()},
#{bean.collection.add(elem)},
#{bean.property.substring(0, bean.property.indexOf(something))}.

Является ли сейчас хорошим стилем использование довольно сложных выражений, таких как вызов параметризованных методов, или вы не советуете использовать такие выражения? Есть ли практическое правило, когда использовать выражения вызова нового метода, а когда нет?


jsf el jsf-2
person hwaltz    schedule 11.12.2013    source источник

Ответы (3)


arrow_upward
3
arrow_downward

Основная рекомендация заключается в следующем: максимально сократить логику «модели» из представления и оставить только логику «представления». EL 2.2 сделал возможным некоторое упрощение модели и снизил потребность в создании искусственных свойств JSF-бинов. Вызов методов с параметрами также позволяет передавать необходимую информацию из представления в контроллер, что было бы утомительно без этой возможности.

Вы можете вызывать произвольные методы для доступа к модели из представления, на которое опирается часть представления, но никогда не должны вызывать методы, которые изменяют модель из представления.

Позвольте мне подробнее остановиться на этом.

Некоторые юридические примеры:

  1. evaluate non-accessor methods when building view:
    • render UI components based on some conditions like rendered="#{request.isUserInRole('administrator')}";
    • при необходимости вносить изменения в коллекцию, например <ui:repeat value="#{bean.set.toArray()}" ... >
    • условно оценивать атрибуты компонента пользовательского интерфейса / элемента HTML, например class = "# {bean.name.contains ('special')? 'special': ''}";
    • выводить данные без доступа, такие как there are #{bean.list.size()} элементов.
  2. pass information to the controller in action methods or listeners:
    • execute action methods with currently iterated variables like var="data" and action="#{bean.action(data)}" with public String action(Data data);
    • передавать дополнительные данные, такие как текущий индекс итерации, в слушателях, таких как varStatus="status" и actionListener="#{bean.action(status.index)}" с public String action(int index).

Некоторые примеры, которых следует избегать:

  1. use EL operators when possible:
    • use #{not empty bean.list} instead of #{bean.list.size() gt 0}.
  2. use method call with parameters instead of extending the model:
    • use #{bean.name.contains('special')} instead of #{bean.special} with public boolean isSpecial() {return name.contains("special");}.
  3. prefer leaving view logic in view for plain rendering of the right things and create model logic in case it applies purely to the model:
    • in case you need to perform some calculations to change the appearance of an object, do that in view directly without changing the model, in case some property is inherent to the model itself, introduce it directly in the model and refer to it from the view.

Некоторые незаконные примеры:

  1. modify the model from the view:
    • do not use EL 2.2 possibility of calling methods with parameters to break the MVC paradigm, i.e. do not call #{bean.list.add(element)} from the view side.

Конечно, все сказанное применимо к случаям, когда ваши цели не содержат таргетинга на старые серверы без поддержки EL 2.2.

В качестве более широкой картины я бы рекомендовал также увидеть объяснение BalusC что представляет собой архитектура MVC в контексте JSF.

person skuntsel    schedule 11.12.2013
comment
Хотите расширить незаконную часть? Поскольку в JSF вы не реализуете контроллер, представление имеет для изменения модели. - person mabi; 11.12.2013
comment
@mabi: что такое контроллер, зависит от точки зрения: stackoverflow.com/questions/5104094/ - person BalusC; 11.12.2013
comment
@mabi Внутри JSF фронт-контроллер «разделяет» некоторые функции с управляемыми компонентами, а именно методы действий и слушатели действий / ajax. Вы можете видеть, что они вызываются из фронт-контроллера как часть его работы, которая выполняется с помощью методов управляемого компонента. Другая часть управляемого bean-компонента - это модель, которая обычно выполняется как композиция, то есть как свойства bean-компонента. - person skuntsel; 11.12.2013
comment
@BalusC Да, но поскольку термин MVC имеет разные точки зрения, я не считаю его единственной причиной, почему мне не следует этого делать. Если это бизнес-процесс, вам все равно нужен компонент / службы поддержки для выполнения многошагового алгоритма. - person mabi; 11.12.2013
comment
О, #{bean.string.replace('old', 'new')} - плохой пример, поскольку он не изменяет модель. @mabi: представление должно просто обращаться к модели, а не изменять ее. За это отвечает только контроллер (экземпляр управляемого компонента). В противном случае модель тесно связана с представлением, и вы не можете добавить, например, регистраторы / перехватчики / предварительную постобработку и т. Д. - person BalusC; 11.12.2013
comment
@BalusC Да, неизменность, неизменность! Я попытался расширить кругозор и остановился на этом наборе примеров. Возможно, есть еще много случаев, которые нужно рассмотреть, так что, возможно, когда-нибудь мы расширим этот список. - person skuntsel; 11.12.2013

arrow_upward
0
arrow_downward

Лично я предпочитаю использовать "сложные" выражения EL, когда действительно необходимо, и беру любую битовую логику / свойство в соответствующие управляемые компоненты.
Например: первый пример, который вы помещаете, является единственным которые я иногда могу использовать напрямую, но два других должны быть для меня введены в действие методами с _1 _ / _ 2_ возвращаемым типом в соответствии с потребностями.

person Omar    schedule 11.12.2013

arrow_upward
0
arrow_downward

Используйте El 2.2, чтобы уменьшить наш код JSF, например setPropertyActionListener становится избыточным, см. Тег ядра JSF: setPropertyActionListener vs attribute vs param < / а>

person rwitzel    schedule 14.12.2013