Jsf 2 Facelets复合组件接口的多种实现

我正在开发一个JSF2应用程序，它由一个核心组件组成，可以通过（通常是特定于客户端的）代码进行扩展。一般来说：应用程序的扩展部分优先于核心部分

对于Java代码，这是通过使用传统机制来完成的。对于表示层，我们使用了一个

javax.faces.view.facelets.resourcesolver

实现，它首先尝试在使用核心资源之前在扩展jar中查找资源

我们使用许多复合组件来进行可重用标记。考虑显示地址、工资等的组件

当涉及到应用程序的可扩展性时，Facelets引起了很大的麻烦，我开始怀疑是否有解决我们遇到的问题的方法

我们想要实现的是，为复合组件提供一个标准接口，但通过解析多个实现，以某种方式覆盖实现，其中扩展实现应先于核心实现

当然，核心定义了应用程序的标准布局/模板，扩展定义了特定于客户端的格式化选项，或者隐藏/显示应用程序所做的部分托管模型

例如：

<ui:composition 
    xmlns="http://www.w3.org/1999/xhtml" 
    xmlns:cc="http://java.sun.com/jsf/composite"
    xmlns:ui="http://java.sun.com/jsf/facelets" 
    xmlns:pui="http://java.sun.com/jsf/composite/pui">

    <cc:interface>
        <cc:attribute name="saveButtonLabel" />
        <cc:attribute name="saveButtonIcon" />
        <cc:attribute name="saveButtonIconPosition" />
    </cc:interface>

    <cc:implementation>
        <pui:pension_plan_custom_state pensionPlanBean="#{pensionPlanBean}" />
        <pui:pension_plan_general pensionPlanBean="#{pensionPlanBean}" />
        <pui:pension_plan_pension_plan pensionPlanBean="#{pensionPlanBean}" />
        <pui:pension_plan_salary pensionPlanBean="#{pensionPlanBean}" />
        <pui:pension_plan_investments pensionPlanBean="#{pensionPlanBean}" />
        <pui:pension_plan_benefit_types benefitTypes="#{pensionPlanBean.benefitTypesViewData}" />

        <div class="buttons">
            <!-- Irrelevant -->
        </div>
    </cc:implementation>
</ui:composition>

我们的想法是，

javax.faces.view.facelets.resourcesolver

将拯救我们

这“有点可行”，但取决于我们必须为复合组件编写的实现，我们在JSF生命周期中臭名昭著的build，-vs rendertime部门遇到了各种各样的问题。它基本上不像我们期望的那样工作

现在的大问题是：

有没有一种方法可以让我们既有一个稳定的契约/名称空间，又有多个动态解析的实现？

希望有人能对此有所启发，谢谢你的投入

亲切问候,

---

Rens

这种情况在JSF2.2中通过资源库契约特性得到了解决。有了这个特性，就可以根据同一个复合组件的本地化和活动契约实现多个组件。请注意，每个视图的本地化/合同都处于活动状态

但可能更适合您的选择是使用：

<ui:include src="#{...}">

或

---

并从托管bean或复合组件类本身（cc:interface componentType=…）提供模板名称。在本例中，我建议使用MyFaces Core的最新版本，因为它的算法已经针对这些情况进行了专门优化（视图状态大小小，性能快）。我认为您不需要在这里处理ResourceResolver逻辑。

我们扩展了

ResourceHandlerWrapper

，在请求加载

WEB-INF/resources

中的xhtml资源时（首先）会扫描类路径

---

通过在

MANIFEST.MF

文件中定义显式类路径，我们可以让扩展jar文件优先于标准实现。通过这样做，我们还可以以编程方式生成附加内容，这些内容可以在UI中显示给开发人员（在开发模式下运行时），让他/她知道可以在扩展项目中编写“重写”实现。

已经“过了一段时间”，同时，事情已经以另一种方式解决了。我们通过编写一个

resourcesolver

来处理我们的特定需求，从而解决了部分问题。我不确定我们是否尝试过你提出的建议，但我所知道的是，混合构建、（

）和渲染时间花费了我们很多时间。最后，它就是不能可靠地工作。我无法确认你的建议是否是解决方案，所以接受你的答案会很奇怪。那么我自己来结束这个话题。也许未来的读者可以试试你的解决方案：）无论如何，谢谢！

<ui:include src="#{...}">

<ui:decorate template="#{...}">