[JBoss JIRA] (RF-12041) BeanValidator: no way to use BeanValidation with a custom config
by Markus Staab (JIRA)
Markus Staab created RF-12041:
---------------------------------
Summary: BeanValidator: no way to use BeanValidation with a custom config
Key: RF-12041
URL: https://issues.jboss.org/browse/RF-12041
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.3.3.Final
Environment: Liferay 5.2.4, Portlet 2.0, JSF 1.2
Reporter: Markus Staab
The BeanValidator class bootstraps a whole new BeanValidation context in its constructor:
{code}
BeanValidator() {
// Enforce class to load
ValidatorFactory.class.getName();
// Check Factory, to avoid instantiation errors
// https://jira.jboss.org/jira/browse/RF-7226
validatorFactory = Validation
.buildDefaultValidatorFactory();
validatorContext = validatorFactory.usingContext();
MessageInterpolator jsfMessageInterpolator = new JsfMessageInterpolator(
validatorFactory.getMessageInterpolator());
validatorContext.messageInterpolator(jsfMessageInterpolator);
}
{/code}
because of this, there is no way to use the programmatic configuration feature of BeanValidation.
I tried to pre-configure a custom MessageInterpolator with
{code}
Configuration<?> config = Validation.byDefaultProvider().configure();
config.messageInterpolator( new MyInterpolator() );
{/code}
but this configuration change is not taken into account by the BeanValidator of Richfaces.
ATM the only way to achive this sort of customization is to use a META-INF/validation.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (RF-12065) Continuous event polling in available.js
by Nicholas Oxhøj (JIRA)
Nicholas Oxhøj created RF-12065:
-----------------------------------
Summary: Continuous event polling in available.js
Key: RF-12065
URL: https://issues.jboss.org/browse/RF-12065
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.3.3.Final
Reporter: Nicholas Oxhøj
Priority: Minor
In available.js there is two functions activatePolling() and stopPolling(), used to wait for a specific DOM element becoming available.
But while activatePolling() starts observing the events "*mousemove*", "focus", and "focusin", stopPolling() stops observing the events "*mouseover*", "focus", and "focusin" - which means that it will _keep_ calling onEvent() on every "mousemove", even when the relevant element has already been found...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (RF-11971) rich:menuItem onclick return value ignored
by Brendan Healey (JIRA)
Brendan Healey created RF-11971:
-----------------------------------
Summary: rich:menuItem onclick return value ignored
Key: RF-11971
URL: https://issues.jboss.org/browse/RF-11971
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.2.0.Final
Environment: Chrome / glassfish 3.1.1 / mojarra 2.1.6
Reporter: Brendan Healey
My expectation was that using rich:menuItem onclick="if(!confirm('#{msgs.playerConfirmDelete}')) return false;"
(and selecting cancel) would prevent any action routines being called, as is common
with components such as h:commandButton. As it stands the return value is ignored and
processing continues with return true or return false.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months