[JBoss JIRA] (RF-13452) UIDataAdaptor must not register as listener for PostAddToViewEvent in its constructor
by Lutz Ulrich (JIRA)
[ https://issues.jboss.org/browse/RF-13452?page=com.atlassian.jira.plugin.s... ]
Lutz Ulrich updated RF-13452:
-----------------------------
Environment: Mojarra 2.1.?? - 2.1.28 (was: Mojarra 2.1.?? - 2.1.26)
> UIDataAdaptor must not register as listener for PostAddToViewEvent in its constructor
> -------------------------------------------------------------------------------------
>
> Key: RF-13452
> URL: https://issues.jboss.org/browse/RF-13452
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: compatibility
> Affects Versions: 4.3.4
> Environment: Mojarra 2.1.?? - 2.1.28
> Reporter: Lutz Ulrich
> Labels: UIDataAdaptor, UIDataTable, dynamical-add
> Fix For: 5-Tracking
>
>
> Whenever a component which is based on {{org.richfaces.component.UIDataAdaptor}} is added dynamically, NPE occurs in the next RESTORE_VIEW Phase when using Mojarra 2.1.x.
> My first guess was, that this would be an error in Mojarra (issue 2152, see https://java.net/jira/browse/JAVASERVERFACES-2152?page=com.atlassian.jira... ),
> which occurs whenever a sub-class of {{UIComponent}} registers itself as {{javax.faces.event.SystemEventListener}} for
> {{javax.faces.event.PostAddToViewEvent}} in ist constructor, just like {{UIDataAdaptor}} does.
> Now, Manfred Riem of Mojarra argues (in the very issue named above), that registering for PostAddToView in the constructor is a design flaw in itself.
> Note that the error occurs with every UIComponent which is added dynamically and which registers itself as PostAddToView listener in its constructor. For the Mojarra issue, I provided a simple component which extends the standard JSF HtmlOutputText and registers itself in its constructor, too. Baam - same error. So maybe more components of RichFaces are affected - not just those based on {{UIDataAdaptor}}.
> For completion, here is a stack trace:
> {quote}
> Schwerwiegend: java.lang.NullPointerException
> at javax.faces.component.UIComponent$ComponentSystemEventListenerAdapter.processEvent(UIComponent.java:2526)
> at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106)
> at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2163)
> at com.sun.faces.application.ApplicationImpl.invokeComponentListenersFor(ApplicationImpl.java:2111)
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:289)
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:247)
> at javax.faces.component.UIComponentBase.publishAfterViewEvents(UIComponentBase.java:2203)
> at javax.faces.component.UIComponentBase.doPostAddProcessing(UIComponentBase.java:1885)
> at javax.faces.component.UIComponentBase.setParent(UIComponentBase.java:405)
> at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:2637)
> at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:2609)
> at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreDynamicAdd(FaceletPartialStateManagementStrategy.java:421)
> at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreDynamicActions(FaceletPartialStateManagementStrategy.java:247)
> at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreView(FaceletPartialStateManagementStrategy.java:570)
> at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:138)
> at com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:123)
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:653)
> at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:142)
> at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:301)
> at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:301)
> at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:192)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-13452) UIDataAdaptor must not register as listener for PostAddToViewEvent in its constructor
by Lutz Ulrich (JIRA)
[ https://issues.jboss.org/browse/RF-13452?page=com.atlassian.jira.plugin.s... ]
Lutz Ulrich updated RF-13452:
-----------------------------
Workaround Description:
When you create a UIDataAdaptor dynamically, replace the UIDataAdaptor by your own ComponentSystemEventListener. Unsubscribe UIDataAdator from itself: {{dataAdaptor.unsubscribeFromEvent(PostAddToViewEvent.class, dataAdaptor)}}.
Create your own ComponentSystemEventListener and register it:
{{dataAdaptor.subscribeToEvent(PostAddToViewEvent.class, new MyListener())}}
In your {{MyListener}}'s implementation of {{processEvent(ComponentSystemEvent)}}: unsubscribe the UIDataAdaptor,too, but delegate to it:
{{event.getComponent().unsubscribeFromEven((PostRestoreStateEvent.class, event.getComponent());}}
{{event.getComponent().processEvent(event);}}
Workaround: Workaround Exists
> UIDataAdaptor must not register as listener for PostAddToViewEvent in its constructor
> -------------------------------------------------------------------------------------
>
> Key: RF-13452
> URL: https://issues.jboss.org/browse/RF-13452
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: compatibility
> Affects Versions: 4.3.4
> Environment: Mojarra 2.1.?? - 2.1.26
> Reporter: Lutz Ulrich
> Labels: UIDataAdaptor, UIDataTable, dynamical-add
> Fix For: 5-Tracking
>
>
> Whenever a component which is based on {{org.richfaces.component.UIDataAdaptor}} is added dynamically, NPE occurs in the next RESTORE_VIEW Phase when using Mojarra 2.1.x.
> My first guess was, that this would be an error in Mojarra (issue 2152, see https://java.net/jira/browse/JAVASERVERFACES-2152?page=com.atlassian.jira... ),
> which occurs whenever a sub-class of {{UIComponent}} registers itself as {{javax.faces.event.SystemEventListener}} for
> {{javax.faces.event.PostAddToViewEvent}} in ist constructor, just like {{UIDataAdaptor}} does.
> Now, Manfred Riem of Mojarra argues (in the very issue named above), that registering for PostAddToView in the constructor is a design flaw in itself.
> Note that the error occurs with every UIComponent which is added dynamically and which registers itself as PostAddToView listener in its constructor. For the Mojarra issue, I provided a simple component which extends the standard JSF HtmlOutputText and registers itself in its constructor, too. Baam - same error. So maybe more components of RichFaces are affected - not just those based on {{UIDataAdaptor}}.
> For completion, here is a stack trace:
> {quote}
> Schwerwiegend: java.lang.NullPointerException
> at javax.faces.component.UIComponent$ComponentSystemEventListenerAdapter.processEvent(UIComponent.java:2526)
> at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106)
> at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2163)
> at com.sun.faces.application.ApplicationImpl.invokeComponentListenersFor(ApplicationImpl.java:2111)
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:289)
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:247)
> at javax.faces.component.UIComponentBase.publishAfterViewEvents(UIComponentBase.java:2203)
> at javax.faces.component.UIComponentBase.doPostAddProcessing(UIComponentBase.java:1885)
> at javax.faces.component.UIComponentBase.setParent(UIComponentBase.java:405)
> at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:2637)
> at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:2609)
> at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreDynamicAdd(FaceletPartialStateManagementStrategy.java:421)
> at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreDynamicActions(FaceletPartialStateManagementStrategy.java:247)
> at com.sun.faces.application.view.FaceletPartialStateManagementStrategy.restoreView(FaceletPartialStateManagementStrategy.java:570)
> at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:138)
> at com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:123)
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:653)
> at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:142)
> at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:301)
> at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:301)
> at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:192)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-13537) Autocomplete: onbegin attribute ignored
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13537?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak updated RF-13537:
-------------------------------
Summary: Autocomplete: onbegin attribute ignored (was: Autocomplete: onbegin attribute igniored)
> Autocomplete: onbegin attribute ignored
> ---------------------------------------
>
> Key: RF-13537
> URL: https://issues.jboss.org/browse/RF-13537
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.5
> Reporter: alexey plotnikov
> Fix For: 4.3.6
>
>
> "onbegin" attribute of rich:autocomplete is always ignored!
> I suggest next fix:
> In file Autocomplete.js:
> {code}
> var callAjax = function(event, callback) {
> ...
> this.isFirstAjax = false;
> //caution: JSF submits inputs with empty names causing "WARNING: Parameters: Invalid chunk ignored." in Tomcat log
> var params = {};
> params[this.id + ".ajax"] = "1";
> rf.ajax(this.id, event, {parameters: params, error: ajaxError, complete:ajaxSuccess});
> }
> {code}
> for fixing, we must replace on
> {code}
> var callAjax = function(event, callback) {
> ...
> this.isFirstAjax = false;
> //caution: JSF submits inputs with empty names causing "WARNING: Parameters: Invalid chunk ignored." in Tomcat log
> var params = {};
> params[this.id + ".ajax"] = "1";
> var parameters_extended = {parameters: params, error: ajaxError, complete:ajaxSuccess};
> if (this.options.onbegin != undefined) {
> parameters_extended.begin = this.options.onbegin;
> }
> rf.ajax(this.id, event, parameters_extended);
> }
> {code}
> I can create pull request if everything ok.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-12865) Correct deferred partial response ending by leveraging PVC wrapper chain
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-12865?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak updated RF-12865:
-------------------------------
Labels: jsf (was: jsf needs-qe)
> Correct deferred partial response ending by leveraging PVC wrapper chain
> ------------------------------------------------------------------------
>
> Key: RF-12865
> URL: https://issues.jboss.org/browse/RF-12865
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core, third-party
> Affects Versions: 4.3.1
> Environment: weblogic 10.3.4, Myfaces 2.1.10, Richfaces 4.3.1, OmniFaces1.3
> Reporter: blam lam
> Assignee: Lukáš Fryč
> Labels: jsf
> Fix For: 5.0.0.Alpha3
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> After submit from a a4j:commandButton, it fail to re-render / update other component on the page.
> This problem only appear in MyFaces. It does not happens in Mojarra.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-13160) Refactor the InputNumber* components into abstract classes
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/RF-13160?page=com.atlassian.jira.plugin.s... ]
Michal Petrov reassigned RF-13160:
----------------------------------
Assignee: Michal Petrov
> Refactor the InputNumber* components into abstract classes
> ----------------------------------------------------------
>
> Key: RF-13160
> URL: https://issues.jboss.org/browse/RF-13160
> Project: RichFaces
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: component-input
> Reporter: Brian Leathem
> Assignee: Michal Petrov
> Fix For: 4.5.0.Alpha3, 5.0.0.Alpha2
>
> Original Estimate: 1 hour, 30 minutes
> Remaining Estimate: 1 hour, 30 minutes
>
> The InputNumberSpinner and InputNumberSlider components are generated via xml in a faces-config.xml file. While this is clever, it means we have two components that are created differently from all the others, making them harder to manage. Additionally the xml is not conducive to refactoring, and the method relies on an xml format for shared attribute definitions, making it difficult to move forward with RF-12952.
> I propose re-implementing those components as Abstract components, like the majority of other RichFaces CDK components.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-13595) rich:validator doesn't work when loaded via ajax (re-render)
by Michael B (JIRA)
[ https://issues.jboss.org/browse/RF-13595?page=com.atlassian.jira.plugin.s... ]
Michael B updated RF-13595:
---------------------------
Description:
When loading input components with a rich:validator via ajax (re-render), client side validation bridge breaks due to a missing JS function av_xxxxxxxxx.
As already described in further detail in a comment to this JIRA here:
https://issues.jboss.org/browse/RF-12031
I've created a very basic example project to reproduce the problem for a single input field which becomes visible (re-rendered) when you click on an a4j:commandButton.
Please note that this is a minimum example only. The problem is also reproducable for other input components besides h:inputText - like for example rich:calendar.
The workaround described in the referenced JIRA creates other problems in client JS when combined with other components like rich:focus and is also not applicable for other input components besides h:inputText.
We think the problem is located in the way JS functions are optimized for being re-used as well as in the way they are (not) being added on the client side when a component becomes visible on ajax response re-rendering.
Please use attached eclipse project to easily reproduce the problem => open Firefox => Firebug console to see the error about the missing JS function av_xxxxxxx ...
was:
When loading input components with a rich:validator via ajax (re-render), client side validation bridge breaks due to a missing JS function av_xxxxxxxxx.
As already described in further detail in a comment to this JIRA here:
https://issues.jboss.org/browse/RF-12031
I've created a very basic example project to reproduce the problem for a single input field which becomes visible (re-rendered) when you click on an a4j:commandButton.
Please note that this is a minimum example only. The problem is also reproducable for other input components besides h:inputText - like for example rich:calendar.
The workaround described in the referenced JIRA creates other problems in client JS when combined with other components like rich:focus and is also not applicable for other input components besides h:inputText.
We think the problem is located in the way JS functions are optimized for being re-used as well as in the way they are (not) added on the client side when a component becomes visible on ajax response re-rendering.
Please use attached eclipse project to easily reproduce the problem => open Firefox => Firebug console to see the error about the missing JS function av_xxxxxxx ...
> rich:validator doesn't work when loaded via ajax (re-render)
> ------------------------------------------------------------
>
> Key: RF-13595
> URL: https://issues.jboss.org/browse/RF-13595
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.3.5
> Environment: RF 4.3.5
> Mojarra 2.1.27
> Java 7 Update 51 x64
> Tomcat 7.0.52
> Firefox 28.0 + Firebug
> Reporter: Michael B
> Attachments: validationTest.zip
>
>
> When loading input components with a rich:validator via ajax (re-render), client side validation bridge breaks due to a missing JS function av_xxxxxxxxx.
> As already described in further detail in a comment to this JIRA here:
> https://issues.jboss.org/browse/RF-12031
> I've created a very basic example project to reproduce the problem for a single input field which becomes visible (re-rendered) when you click on an a4j:commandButton.
> Please note that this is a minimum example only. The problem is also reproducable for other input components besides h:inputText - like for example rich:calendar.
> The workaround described in the referenced JIRA creates other problems in client JS when combined with other components like rich:focus and is also not applicable for other input components besides h:inputText.
> We think the problem is located in the way JS functions are optimized for being re-used as well as in the way they are (not) being added on the client side when a component becomes visible on ajax response re-rendering.
> Please use attached eclipse project to easily reproduce the problem => open Firefox => Firebug console to see the error about the missing JS function av_xxxxxxx ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (RF-13595) rich:validator doesn't work when loaded via ajax (re-render)
by Michael B (JIRA)
[ https://issues.jboss.org/browse/RF-13595?page=com.atlassian.jira.plugin.s... ]
Michael B updated RF-13595:
---------------------------
Description:
When loading input components with a rich:validator via ajax (re-render), client side validation bridge breaks due to a missing JS function av_xxxxxxxxx.
As already described in further detail in a comment to this JIRA here:
https://issues.jboss.org/browse/RF-12031
I've created a very basic example project to reproduce the problem for a single input field which becomes visible (re-rendered) when you click on an a4j:commandButton.
Please note that this is a minimum example only. The problem is also reproducable for other input components besides h:inputText - like for example rich:calendar.
The workaround described in the referenced JIRA creates other problems in client JS when combined with other components like rich:focus and is also not applicable for other input components besides h:inputText.
We think the problem is located in the way JS functions are optimized for being re-used as well as in the way they are (not) added on the client side when a component becomes visible on ajax response re-rendering.
Please use attached eclipse project to easily reproduce the problem => open Firefox => Firebug console to see the error about the missing JS function av_xxxxxxx ...
was:
When loading input components with a rich:validator via ajax (re-render), client side validation bridge breaks due to missing JS function av_xxxxxxxxx.
As already described in further detail in a comment to this JIRA here:
https://issues.jboss.org/browse/RF-12031
I've created a very basic example project to reproduce the problem for a single input field which becomes visible (re-rendered) when you click on an a4j:commandButton.
Please note that this is a minimum example only. The problem is also reproducable for other input components besides h:inputText - like for example rich:calendar.
The workaround described in the referenced JIRA creates other problems in client JS when combined with other components like rich:focus and is also not applicable for other input components besides h:inputText.
We think the problem is located in the way JS functions are optimized for being re-used as well as in the way they are (not) added on the client side when a component becomes visible on ajax response re-rendering.
Please use attached eclipse project to easily reproduce the problem => open Firefox => Firebug console to see the error about the missing JS function av_xxxxxxx ...
> rich:validator doesn't work when loaded via ajax (re-render)
> ------------------------------------------------------------
>
> Key: RF-13595
> URL: https://issues.jboss.org/browse/RF-13595
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.3.5
> Environment: RF 4.3.5
> Mojarra 2.1.27
> Java 7 Update 51 x64
> Tomcat 7.0.52
> Firefox 28.0 + Firebug
> Reporter: Michael B
> Attachments: validationTest.zip
>
>
> When loading input components with a rich:validator via ajax (re-render), client side validation bridge breaks due to a missing JS function av_xxxxxxxxx.
> As already described in further detail in a comment to this JIRA here:
> https://issues.jboss.org/browse/RF-12031
> I've created a very basic example project to reproduce the problem for a single input field which becomes visible (re-rendered) when you click on an a4j:commandButton.
> Please note that this is a minimum example only. The problem is also reproducable for other input components besides h:inputText - like for example rich:calendar.
> The workaround described in the referenced JIRA creates other problems in client JS when combined with other components like rich:focus and is also not applicable for other input components besides h:inputText.
> We think the problem is located in the way JS functions are optimized for being re-used as well as in the way they are (not) added on the client side when a component becomes visible on ajax response re-rendering.
> Please use attached eclipse project to easily reproduce the problem => open Firefox => Firebug console to see the error about the missing JS function av_xxxxxxx ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (RF-13595) rich:validator doesn't work when loaded via ajax (re-render)
by Michael B (JIRA)
[ https://issues.jboss.org/browse/RF-13595?page=com.atlassian.jira.plugin.s... ]
Michael B updated RF-13595:
---------------------------
Description:
When loading input components with a rich:validator via ajax (re-render), client side validation bridge breaks due to missing JS function av_xxxxxxxxx.
As already described in further detail in a comment to this JIRA here:
https://issues.jboss.org/browse/RF-12031
I've created a very basic example project to reproduce the problem for a single input field which becomes visible (re-rendered) when you click on an a4j:commandButton.
Please note that this is a minimum example only. The problem is also reproducable for other input components besides h:inputText - like for example rich:calendar.
The workaround described in the referenced JIRA creates other problems in client JS when combined with other components like rich:focus and is also not applicable for other input components besides h:inputText.
We think the problem is located in the way JS functions are optimized for being re-used as well as in the way they are (not) added on the client side when a component becomes visible on ajax response re-rendering.
Please use attached eclipse project to easily reproduce the problem => open Firefox => Firebug console to see the error about the missing JS function av_xxxxxxx ...
was:
When loading input components with a rich:validator via ajax (re-render), client side validation bridge breaks due to missing JS function av_xxxxxxxxx.
As already described in further detail in a comment to this JIRA here:
https://issues.jboss.org/browse/RF-12031
I've created a very basic example project to reproduce the problem for a single input field which becomes visible (re-rendered) when you click on an a4j:commandButton.
Please note that this is a minimum example only. The problem is also reproducable for other input components besides h:inputText like for example rich:calendar.
The workaround described in the referenced JIRA creates other problems in client JS when combined with other components like rich:focus and is also not applicable for other input components besides h:inputText.
We think the problem is located in the way JS functions are optimized for being re-used as well as in the way they are (not) added on the client side when a component becomes visible on ajax response re-rendering.
> rich:validator doesn't work when loaded via ajax (re-render)
> ------------------------------------------------------------
>
> Key: RF-13595
> URL: https://issues.jboss.org/browse/RF-13595
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.3.5
> Environment: RF 4.3.5
> Mojarra 2.1.27
> Java 7 Update 51 x64
> Tomcat 7.0.52
> Firefox 28.0 + Firebug
> Reporter: Michael B
> Attachments: validationTest.zip
>
>
> When loading input components with a rich:validator via ajax (re-render), client side validation bridge breaks due to missing JS function av_xxxxxxxxx.
> As already described in further detail in a comment to this JIRA here:
> https://issues.jboss.org/browse/RF-12031
> I've created a very basic example project to reproduce the problem for a single input field which becomes visible (re-rendered) when you click on an a4j:commandButton.
> Please note that this is a minimum example only. The problem is also reproducable for other input components besides h:inputText - like for example rich:calendar.
> The workaround described in the referenced JIRA creates other problems in client JS when combined with other components like rich:focus and is also not applicable for other input components besides h:inputText.
> We think the problem is located in the way JS functions are optimized for being re-used as well as in the way they are (not) added on the client side when a component becomes visible on ajax response re-rendering.
> Please use attached eclipse project to easily reproduce the problem => open Firefox => Firebug console to see the error about the missing JS function av_xxxxxxx ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (RF-12031) rich:validator does not work after re render (ajax)
by Michael B (JIRA)
[ https://issues.jboss.org/browse/RF-12031?page=com.atlassian.jira.plugin.s... ]
Michael B commented on RF-12031:
--------------------------------
I've filed a new issue which can be found here:
https://issues.jboss.org/browse/RF-13595
> rich:validator does not work after re render (ajax)
> ---------------------------------------------------
>
> Key: RF-12031
> URL: https://issues.jboss.org/browse/RF-12031
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.2.0.Final
> Environment: browsers: Firefox, Chrome
> Reporter: Andries Ehlers
> Assignee: Lukáš Fryč
> Priority: Minor
>
> When you have a simple inputText component with rich:validator inside, validation works perfectly when you move focus away from the component - validation messages display, e.g:
> {code:xml|borderStyle=solid}
> <h:inputText id="mytest1" value="#{profileBean.profileUser.firstName}">
> <rich:validator/>
> </h:inputText>
> <rich:message for="mytest1"/>
> {code}
> If the above code resides in a panel, which is conditionally rendered, then <rich:validator> ceases to function when you re-render the panel with ajax, eg:
> {code:xml|borderStyle=solid}
> <h:form id="dummyForm" prependId="false">
> <h:commandButton value="Toggle" actionListener="#{profileBean.toggleRender}">
> <f:ajax execute="@form" render="@form"/>
> </h:commandButton>
> <!--This will toggle on/off as you click the button above-->
> <h:panelGroup layout="block" rendered="#{profileBean.mustRenderThePanel}">
> <br/>
> <h:inputText id="mytest1" value="#{profileBean.profileUser.firstName}">
> <rich:validator/> <!--this fails to work when you move focus away -->
> </h:inputText>
> <rich:message for="mytest1"/>
> </h:panelGroup>
> </h:form>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (RF-13595) rich:validator doesn't work when loaded via ajax (re-render)
by Michael B (JIRA)
[ https://issues.jboss.org/browse/RF-13595?page=com.atlassian.jira.plugin.s... ]
Michael B edited comment on RF-13595 at 4/1/14 5:06 PM:
--------------------------------------------------------
This is a minimal eclipse project to reproduce the problem.
Add RF 4.3.5 jars and dependencies to WEB-INF/lib folder as well as javax.faces-2.1.27.jar to run the project against tomcat.
was (Author: michaelb80):
This is a minimal eclipse project to reproduce the problem.
Add RF 4.3.5 jars to WEB-INF/lib folder as well as javax.faces-2.1.27.jar to run the project against tomcat.
> rich:validator doesn't work when loaded via ajax (re-render)
> ------------------------------------------------------------
>
> Key: RF-13595
> URL: https://issues.jboss.org/browse/RF-13595
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.3.5
> Environment: RF 4.3.5
> Mojarra 2.1.27
> Java 7 Update 51 x64
> Tomcat 7.0.52
> Firefox 28.0 + Firebug
> Reporter: Michael B
> Attachments: validationTest.zip
>
>
> When loading input components with a rich:validator via ajax (re-render), client side validation bridge breaks due to missing JS function av_xxxxxxxxx.
> As already described in further detail in a comment to this JIRA here:
> https://issues.jboss.org/browse/RF-12031
> I've created a very basic example project to reproduce the problem for a single input field which becomes visible (re-rendered) when you click on an a4j:commandButton.
> Please note that this is a minimum example only. The problem is also reproducable for other input components besides h:inputText like for example rich:calendar.
> The workaround described in the referenced JIRA creates other problems in client JS when combined with other components like rich:focus and is also not applicable for other input components besides h:inputText.
> We think the problem is located in the way JS functions are optimized for being re-used as well as in the way they are (not) added on the client side when a component becomes visible on ajax response re-rendering.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months