< ui:include>带有动态src ...完全疯狂 [英] <ui:include> with dynamic src ... complete madness

查看:94
本文介绍了< ui:include>带有动态src ...完全疯狂的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在使用JSF完成极其简单的任务时,我遇到了一个大问题.问题:我有一些对象,这些对象具有聚合的属性,这些属性的类型随对象的不同而不同.根据属性的类型,我想使用一组不同的输入字段.

I'm having a massive problem getting an extremely simple task done in JSF. The problem: I have objects, who have aggregated properties that can vary in type from object to object. Depending on the type of the property, I want to use a different set of input fields.

子类型组件驻留在框架中,并按需加载.为此,我使用以下代码:

The subtype components reside in frameworks and get loaded on demand. To this end, I use the following code:

<h:panelGroup id="zusatzdaten">
    <fieldset class="clear">
    <legend>#{tickerUI.ticker.tickerDescription.label}
          (#{tickerUI.ticker.tickerDescId})
    </legend>
    <h:panelGroup rendered="#{tickerUI.editComponentName != null}">
        <ui:include src="#{tickerUI.editComponentName}"/>
    </h:panelGroup>
    </fieldset>
</h:panelGroup>

该组件的名称来自TickerUI,它是@SessionScope.现在令人眼花bit乱:当它第一次加载时,将显示正确的子组件.但是,在导航中使用链接时,应导致包含其他组件,因此不会更新内容!这会导致错误,因为数据现在是另一个子类型,但是表单组件仍来自前一个.

The name of the component comes out of TickerUI, which is of @SessionScope. Now the dazzling bit: when it first loads, the correct subcomponent is displayed. However, when using a link in the navigation, which should lead to including a different component, the content is NOT updated! This results in an error, because the data is now a different subtype, but the form components are still from the previous one.

从错误返回并再次单击链接时,将显示正确的组件.我记录了editComponentName的值,并返回了正确的值.这非常令人困惑.当getter将正确的组件名称返回到src属性时,为什么会包含错误的内容?

When going back from the error and clicking the link again, the correct component is displayed. I logged the value of editComponentName and the correct values are returned. This is very confusing. Why is including the wrong content when the getter returns the correct component name to the 's src attribute?

非常感谢您的帮助.

推荐答案

实际上,您的问题是经典的视图构建与视图渲染时间问题/误解.更具体地说,视图是在每个新请求上 build 构建的,并在回发时从先前保存的状态重构.稍后,将视图渲染以产生HTML内容.

Actually your problem is a classic view build vs view render time problem/misunderstanding. More specifically, the view is built on every new request and reconstructed from a previously saved state on postbacks. Later the view is rendered to produce HTML content.

现在,由于<ui:include>标记处理程序,或者按照官方术语,是 view构建时间标记,因此当您首次请求页面时,其value属性被评估,并且包含的​​页面进入视图.回发后,与您预期的相反,在重建的视图中,包含的内容已经存在.因此,这是预期的行为,您将获得视图的确切部分.

Now, as <ui:include> is a tag handler, or in official terms a view build time tag, when you first request the page, its value attribute is evaluated, and the included page makes its way into the view. Upon postback, contrary to what you might expect, the incuded contents are already there, in the reconstructed view. So, it is an expected behaviour that you'll have the exact part of view rendered.

对于该解决方案,您只需要简单地列出包含在有条件渲染的<ui:fragment> JSF组件中的静态包含的详尽列表.为简单起见,所有内容都可以放置在类似<h:panelGroup>的容器中,该容器始终进行渲染以简化AJAX更新.该代码可以按如下方式组装:

As to the solution, you could just simply include an exhaustive list of static includes that are wrapped in conditionally rendered <ui:fragment> JSF components. For simplicity, all content could be places within a container like <h:panelGroup> that's always rendered for ease of AJAX updates. The code could be assembled as follows:

<h:panelGroup id="ui">
    <ui:fragment rendered="#{bean.condition1}">
        <ui:include src="/path/to/file1.xhtml"/>
    </ui:fragment>
    ...
    <ui:fragment rendered="#{bean.condition_n}">
        <ui:include src="/path/to/file_n.xhtml"/>
    </ui:fragment>
</h:panelGroup>

这篇关于&lt; ui:include&gt;带有动态src ...完全疯狂的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆