Chr*_*kov 20 forms ajax jsf naming-containers
我对这个事实背后的想法有一个疑问,即只有UIForm属性prependId.为什么NamingContainer界面中没有指定属性？你现在可能会说这是因为后向兼容性但我宁愿打破兼容性并让实现该接口的用户也实现prependId的方法.
从我对UIForm组件中的prependId的观点来看,主要的问题是它会破坏findComponent()
我希望如果我使用prependId,那么NamingContainer行为会改变,不仅与渲染有关,而且在想要在组件树中搜索组件时也是如此.
这是一个简单的例子:
<h:form id="test" prependId="false">
<h:panelGroup id="group"/>
</h:form>
现在,当我想获得panelGroup组件时,我希望将字符串传递"group"给方法findComponent(),但它不会找到任何东西,我必须使用"test:group".
具体问题是,当使用ajax时prependId="false".ajax标记在属性更新和处理中期望值关注命名容器.有点奇怪的是,当我使用它时prependId="false",我必须指定完整的id或路径,但没关系.
<h:form id="test" prependId="false">
<h:panelGroup id="group"/>
</h:form>
<h:form id="test1" prependId="false">
<h:commandButton value="go">
<f:ajax render="test:group"/>
</h:commandButton>
</h:form>
那么这段代码将呈现没有问题,但它不会更新panelGroup,因为它无法找到它.在PartialViewContext将只包含ID "group"为renderIds的元素.我不知道这是否是预期的,可能是但我不知道代码.现在我们到了方法findComponent()无法找到组件的位置,因为作为参数传递的表达式是"group"方法期望"test:group"找到组件的位置.
一种解决方案是编写自己的解决方案,findComponent()这是我选择处理此问题的方式.在这个方法中,我处理一个组件,它是一个NamingContainer并且具有属性prependId像正常一样设置为false UIComponent.我将不得不为每个UIComponent提供prependId属性的事情做到这一点,这很糟糕.反射将有助于绕过类型的静态定义,但它仍然不是一个非常干净的解决方案.
另一种方法是在NamingContainer接口中引入prependId属性,并改变行为,findComponent()如上所述.
最后提出的解决方案是改变ajax标记的行为以传递整个id,但这只能解决ajax问题而不是findComponent()实现背后的程序问题.
你怎么看待这个以及它为什么会这样实现呢？我不能成为第一个遇到这个问题的人,但是我找不到相关的主题？!
Bal*_*usC 18
实际上,UIComponent#findComponent()正如<f:ajax render>使用时失败所做的那样<h:form prependId="false">.这个问题是众所周知的,并且是"无法修复":JSF规范问题573.
在我看来,他们应该永远不会在JSF 1.2时代添加prependId属性UIForm.仅仅是为了让j_security_check用户满意,他们希望将JSF表单与JSF输入组件一起使用(j_security_check需要精确的输入字段名称j_username,j_password并且无法通过配置进行修改).但他们没有完全意识到在JSF 1.2期间引入了另一项改进,使您能够继续使用<form>而不是坚持使用<h:form>.然后CSS/jQuery纯粹主义者开始滥用prependId="false"以避免:在他们选择不当的CSS选择器中转义分隔符.
只是不要使用prependId="false",永远.
对于j_security_check,只需使用<form>或新的Servlet 3.0 HttpServletRequest#login().另请参阅使用j_security_check在Java EE/JSF中执行用户身份验证.
对于CSS选择器,如果您绝对需要ID选择器(因此不是更可重用的类选择器),只需将感兴趣的组件包装在纯HTML <div>或<span>.
| 归档时间： |
|
| 查看次数： |
8446 次 |
| 最近记录： |