组件绑定与findComponent()-何时使用哪个? [英] component binding vs findComponent() - when to use which?

问题描述

如此问题中所述，我尝试以备用bean端的形式执行一些字段验证.为此，我想访问违规字段以对其进行标记. 通过搜索网络，似乎有两种方法可以做到这一点:

As described in this question I try to perform some field validation in a form on the backing bean side. For this I would like to access the violating fields to mark them. From searching the web there seem to be two ways to do this:

• 将组件存储在支持bean中以进行访问，并通过binding属性在JSF页面中使用它们.
• 在JSF页面中使用标准值绑定，并且需要从Bean访问组件时，通过UIViewRoot.findComponent(String id)
查找它

• store the components in the backing bean for access and use them in the JSF pages via the binding attribute.
• Use standard value binding in the JSF pages and when needing access to a component from the bean, look it up via UIViewRoot.findComponent(String id)

据我所知，两种方式都有缺点: 组件绑定使变量和getters/setter破坏了支持bean，某些站点完全不鼓励使用组件绑定.无论如何，建议范围.另一方面，findComponent()总是遍历树，这可能会或可能不会很昂贵，对吧? (此外，目前我根本找不到我的组件，但这是另一个问题)

As far as I can see both ways have drawbacks: Component bindings blows up the backing bean with variables and getters/setters, some sites strongly discourage the use of component binding at all. In any case, a request scope is advised. On the other hand, findComponent() always traverses the tree, which may or may not be costly, right? (Plus, at the moment I can't find my component at all, but that is another problem)

走哪条路?这些替代方案是否可互换?如果不是，则根据您选择的标准?目前，我只是没有足够的洞察力做出明智的决定...

Which would be the way to go? Are these interchangeable alternatives and if not, based on what criteria do you chose? Currently I just don't have enough insight to make a decent decision...

推荐答案

首先，不管选择如何，两者都是不好的做法.另请参见 JSF的'binding'属性如何工作?何时以及如何使用?

First of all, regardless of the choice, both are a poor practice. See also How does the 'binding' attribute work in JSF? When and how should it be used?

如果必须做出选择，组件绑定肯定会更快，更便宜.从逻辑上讲，完全由UIComponent#findComponent()完成的树扫描具有性能影响.

If you had to make the choice, component bindings are definitely faster and cheaper. It makes logically completely sense that a tree scan as done by UIComponent#findComponent() has its performance implications.

实际上，必须对包含组件绑定 的后备bean进行请求范围划分，但是您可以通过@ManagedProperty轻松地注入一个包含业务逻辑的不同范围的后备bean.

Indeed, the backing bean holding the component bindings must be request scoped, but you could easily inject a different scoped backing bean holding the business logic in it by @ManagedProperty.

一种更清洁的方法是使用Map作为所有组件绑定的持有者.您只需将以下条目添加到faces-config.xml:

A cleaner approach would be to use a Map as holder of all component bindings. You only need to add the following entry to faces-config.xml:

<managed-bean>
    <managed-bean-name>components</managed-bean-name>
    <managed-bean-class>java.util.HashMap</managed-bean-class>
    <managed-bean-scope>request</managed-bean-scope>
</managed-bean>

这只能用作

<h:inputSome binding="#{components.input1}" />
<h:inputSome binding="#{components.input2}" />
<h:inputSome binding="#{components.input3}" />

这可以在其他bean中获得

And this can be obtained in other beans as

Map<String, UIComponent> components = (Map<String, UIComponent>) externalContext.getRequestMap().get("components");

这样，您无需担心指定各个属性/获取器/设置器.在上面的示例中，Map将包含三个键为input1，input2和input3的条目，每个条目均具有相应的UIComponent实例作为值.

This way you don't need to worry about specifying individual properties/getters/setters. In the above example, the Map will contain three entries with keys input1, input2 and input3, each with the respective UIComponent instance as value.

无关，与具体问题相比，在其他问题中描述的具体问题的解决方案可能比在动作方法中进行验证(实际上是错误的设计)要简单得多.我已经在那边发布了答案.

Unrelated to the concrete question, there may be a much simpler solution to the concrete problem as you described in the other question than performing the validation in the action method (which is actually Bad Design). I've posted an answer over there.

这篇关于组件绑定与findComponent()-何时使用哪个?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！