[JBoss JIRA] Created: (RF-3618) AjaxContextImpl: Usage of @PostConstruct on decode(FacesContext context)
by Gena Batalski (JIRA)
AjaxContextImpl: Usage of @PostConstruct on decode(FacesContext context)
-------------------------------------------------------------------------
Key: RF-3618
URL: http://jira.jboss.com/jira/browse/RF-3618
Project: RichFaces
Issue Type: Bug
Affects Versions: 3.2.0, 3.2.0.SR1, 3.2.1, 3.2.2
Environment: RichFaces from SVN ~3.2.1, SAP Netweaver CE7.1
Reporter: Gena Batalski
Hello,
i've installed a Seam application with RichFaces on SAP Netweaver CE 7.1. The server rejected the richfaces-impl.jar because of usage of @PostConstruct annotation on the AjaxContextImpl.decode(FacesContext context) method. According to Javadoc, the @PostConstruct must not have any parameters. Does it have any reason to use the @PostConstruct in this case?
Since i removed this annotation, the richfaces also work in the SAP Netweaver JEE environment!
Gena
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months
[JBoss JIRA] Created: (RF-3758) add a4j:supportAll to mirror Seam's s:validateAll
by Dan Allen (JIRA)
add a4j:supportAll to mirror Seam's s:validateAll
-------------------------------------------------
Key: RF-3758
URL: http://jira.jboss.com/jira/browse/RF-3758
Project: RichFaces
Issue Type: Feature Request
Affects Versions: 3.2.1
Reporter: Dan Allen
Priority: Minor
Fix For: 3.2.2
To save the developer from having to add the <s:validate> tag to every input component, Seam introduced the <s:validateAll> tag which walks its descendents and applies the Seam model validator to the input components. The same technique could be added to Ajax4jsf to avoid the need of having to add the <a4j:support> tag to every input.
Often times you see the following markup:
<h:panelGroup id="fieldNameGroup">
<h:inputText id="fieldName" value="#{model.fieldName">
<a4j:support event="onblur" ajaxSingle="true" bypassUpdates="true" reRender="fieldNameGroup"/>
</h:inputText>
<h:message for="fieldName"/>
</h:panelGroup>
It sure would be nice to be able to simplify this to the following:
<h:panelGroup id="fieldNameGroup">
<a4j:supportAll event="onblur" ajaxSingle="true" bypassUpdates="true" reRender="fieldNameGroup">
<h:inputText id="fieldName" value="#{model.fieldName}"/>
</a4j:supportAll>
<h:message for="fieldName"/>
</h:panelGroup>
At first, you may think to yourself what the difference is. Well, a Facelet template can accomodate the second example to eliminate the need to specify the <a4j:support> tag. The first example cannot since there is no way to add a child element to a component passed into a template. So you could reduce this to:
<s:decorate id="fieldNameDecorate" template="layout/edit.xhtml">
<ui:param name="reRender" value="fieldNameDecorate"/>
<h:inputText id="fieldName" value="#{model.fieldName}"/>
</s:decorate>
We could even modify Seam to make the id of the decorate component available to the template so that the reRender parameter is not necessary. The template would look like the second example above, except that the input component would be replaced with <ui:insert/> and the value of reRender would be set to #{reRender}. The other benefit, of course, is that it is easy to turn on and off Ajax4jsf.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months