[Trinidad} Issue with ValueChangeListener

2010-09-28 Thread Seema Richard (UST, IND)
Hi,

 

We are using Trinidad 1.2 with facelets.There are multiple checkboxes in
our form and we require to call an ActionListener every time a checkbox
is selected/deselected. 

 

Below is the code:

tr:form

tr:selectBooleanCheckbox autoSubmit=true

id=quantity1
valueChangeListener=#{simpleBackingBean.processValueChange}/

tr:selectBooleanCheckbox autoSubmit=true

id=quantity2
valueChangeListener=#{simpleBackingBean.processValueChange}/

tr:selectBooleanCheckbox autoSubmit=true

id=quantity3
valueChangeListener=#{simpleBackingBean.processValueChange}}/

/tr:form

What happens here is every time the checkbox is selected/deselected the
listener method is invoked 3 times, one for each component having the
valuechangeListener attribute. We have tried to remove the autoSubmit
attribute from the check box components but then nothing happens on
selection / deselection.

 Is there a way by which we can get just the changed checkbox value when
it is clicked?

Thanks,

Seema

 

 



Re: [Trinidad} Issue with ValueChangeListener

2010-09-28 Thread Cédric Durmont
Hi,

What's the scope of the bean ? If it's a request bean, then this is normal...
Otherwise, the valueChangeListener is not called until the new value
differs from the old one.
Try to put a breakpoint in simpleBackingBean.processValueChange and
compare old and new value as given in the event object.
Maybe the values are roughly the same but oldValue.equals(newValue)
returns false for a reason or another. Or, something else changes the
value in between.
Hope this may lead you to your problem...

Regards,
Cedric

2010/9/28 Seema Richard (UST, IND) seema.rich...@ust-global.com:
 Hi,



 We are using Trinidad 1.2 with facelets.There are multiple checkboxes in
 our form and we require to call an ActionListener every time a checkbox
 is selected/deselected.



 Below is the code:

 tr:form

 tr:selectBooleanCheckbox autoSubmit=true

 id=quantity1
 valueChangeListener=#{simpleBackingBean.processValueChange}/

 tr:selectBooleanCheckbox autoSubmit=true

 id=quantity2
 valueChangeListener=#{simpleBackingBean.processValueChange}/

 tr:selectBooleanCheckbox autoSubmit=true

 id=quantity3
 valueChangeListener=#{simpleBackingBean.processValueChange}}/

 /tr:form

 What happens here is every time the checkbox is selected/deselected the
 listener method is invoked 3 times, one for each component having the
 valuechangeListener attribute. We have tried to remove the autoSubmit
 attribute from the check box components but then nothing happens on
 selection / deselection.

  Is there a way by which we can get just the changed checkbox value when
 it is clicked?

 Thanks,

 Seema








Re: [tobago] Validation in Popups

2010-09-28 Thread Udo Schnurpfeil

 Hello Michael,

please try to put the form outside of the command tag, which opens the 
popup. This should solve your problems.


The background is: The popup must be inside the form to consider it was 
already active.


Regards,

Udo

Am 23.09.10 22:29, schrieb Michael Kakuschky:
 Hello, I have a form in a popup. Now it works fine and I add some 
validators to it. I checked that they are executed and throws the 
ValidatorException if the input does not match the requirements.


In case of exceptions the action behind the popup form is not executed 
but unfortunately the popup is closed without any notification about 
the wrong input. Is there a way to keep the popup open so that the 
user is informed about the wrong input?


thanks regards Michael



AW: Bean Validation (JSR 303)

2010-09-28 Thread Matthias Niehoff
Thanks for your help. I solved the problem. After I fixed a version mismatch
in SLF4J Bean Validation was enabled. Maybe the initialization checks the
logger?

Regards

-Ursprüngliche Nachricht-
Von: Jan-Kees van Andel [mailto:jankeesvanan...@gmail.com] 
Gesendet: Montag, 27. September 2010 21:55
An: MyFaces Discussion
Betreff: Re: Bean Validation (JSR 303)

Yeah, but there is more. First, did you package the myfaces jars in the
application or in a shared library or something? And the same question for
the validation api and impl jars

And this Class.forName check is not the complete check. After Class.forName,
we completely initialize the bean validation framework, using the default
factory. If this fails, I decided to disable bean validation. But in this
case, you should see more logging. For example the error message, explaining
why the beanval initialization failed.

You can set the logger for javax.faces.validator to fine to see the
error message, if any. Otherwise, putting a breakpoint in the
javax.faces.validator.BeanValidator.createValidatorFactory() method and
stepping into _ExternalSpecifications.isBeanValidationAvailable() would also
be a very good first step.

@Committers: I decided to log it as fine a year ago, because I can't decide
whether or not the exception is important. I didn't want to irritate and
scare developers when there is no issue. But we might be better off logging
it as info, for cases like this one. Or maybe a second catch clause for
specific bean validation exceptions that logs its messages as info. But then
again, not every exception thrown by the buildDefaultValidatorFactory has to
be that type. For example, NoClassDefFoundErrors could also occur. What do
you think?

Regards,
Jan-Kees

2010/9/27 Jakob Korherr jakob.korh...@gmail.com

 Hi,

 That's weird, because ExternalSpecifications does this:

 beanValidationAvailable =
 (Class.forName(javax.validation.Validation) != null);

 Thus it will be true if javax.validation.Validation is on the classpath!

 Regards,
 Jakob

 2010/9/27 Matthias Niehoff niehoff.matth...@googlemail.com:
  Hey,
 
  I get this message:
  27.09.2010 15:57:32 org.apache.myfaces.util.ExternalSpecifications
  isBeanValidationAvailable
  INFO: MyFaces Bean Validation support disabled I double checked the 
  classpath. javax.validation.Validation is on it.
 
  Regards
 
  Matthias
 
  -Ursprüngliche Nachricht-
  Von: Jan-Kees van Andel [mailto:jankeesvanan...@gmail.com]
  Gesendet: Montag, 27. September 2010 13:52
  An: MyFaces Discussion
  Betreff: Re: Bean Validation (JSR 303)
 
  Hey,
 
  If you specify javax.faces.VALIDATE_EMPTY_FIELDS=auto, MyFaces will 
  look
 for
  a class named javax.validation.Validation on the classpath. If it is
 found,
  it will try to initialize it, using:
  Validation.buildDefaultValidatorFactory().getValidator();
 
  This call may fail, for instance, because of a configuration error 
  in
 your
  bean validation code. And if it does, MyFaces will catch this error 
  and
 log
  an error message: Error initializing Bean Validation (could be normal)
 
  Afterwards, you should see a message in the log: MyFaces Bean 
  Validation support enabled or MyFaces Bean Validation support 
  disabled, depending
 on
  whether initalization succeeded or not.
 
  Do you see those log messages?
 
  Regards,
  Jan-Kees
 
 
  2010/9/27 Matthias Niehoff niehoff.matth...@googlemail.com
 
  Yes, using Hibernate Validator 4.1.0 Final and Validation API 1.0.0.
  Is there anything else to configure?
 
  Regards
  Matthias
 
  -Ursprüngliche Nachricht-
  Von: Michael Kurz [mailto:michi.k...@gmx.at]
  Gesendet: Montag, 27. September 2010 13:33
  An: users@myfaces.apache.org
  Betreff: Re: Bean Validation (JSR 303)
 
  Do you have a bean validation implementation like Hibernate 
  Validator on your classpath?
 
  regards
  Michael
 
  Am 27.09.2010 13:21, schrieb Matthias Niehoff:
   Hi,
  
   I'm trying to realize Bean Validation. I annotated my attributes 
   and set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
true.
   Furthermore I added a h:message tag in my form. When I test the 
   validation nothing happens. The input is accepted (and in my case
  persisted).
   Relevant parts of the Code:
  
   Web.xml
  
context-param
  
   param-namejavax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_A
   S_N
   UL
   L/par
   am-name
param-valuetrue/param-value
/context-param
  
context-param
param-namejavax.faces.VALIDATE_EMPTY_FIELDS/param-name
param-valueauto/param-value
/context-param
  
   User.java
  
   import javax.validation.constraints.NotNull;
   import org.hibernate.validator.constraints.Email;
  
   public class User {
 @NotNull
 private String nachname;
 @NotNull
 private String vorname;
 @NotNull
 private String userID;
 @NotNull
 private String password;
 

Re: Bean Validation (JSR 303)

2010-09-28 Thread Jan-Kees van Andel
Great!

I guess the logger version mismatch causes a noclassdeffounderror or
something inside beanval. I guess we need to implement some additional
logging inside myfaces to debug such issues...

Regards,
Jan-Kees


2010/9/28 Matthias Niehoff niehoff.matth...@googlemail.com

 Thanks for your help. I solved the problem. After I fixed a version
 mismatch
 in SLF4J Bean Validation was enabled. Maybe the initialization checks the
 logger?

 Regards

 -Ursprüngliche Nachricht-
 Von: Jan-Kees van Andel [mailto:jankeesvanan...@gmail.com]
 Gesendet: Montag, 27. September 2010 21:55
 An: MyFaces Discussion
 Betreff: Re: Bean Validation (JSR 303)

 Yeah, but there is more. First, did you package the myfaces jars in the
 application or in a shared library or something? And the same question for
 the validation api and impl jars

 And this Class.forName check is not the complete check. After
 Class.forName,
 we completely initialize the bean validation framework, using the default
 factory. If this fails, I decided to disable bean validation. But in this
 case, you should see more logging. For example the error message,
 explaining
 why the beanval initialization failed.

 You can set the logger for javax.faces.validator to fine to see the
 error message, if any. Otherwise, putting a breakpoint in the
 javax.faces.validator.BeanValidator.createValidatorFactory() method and
 stepping into _ExternalSpecifications.isBeanValidationAvailable() would
 also
 be a very good first step.

 @Committers: I decided to log it as fine a year ago, because I can't decide
 whether or not the exception is important. I didn't want to irritate and
 scare developers when there is no issue. But we might be better off logging
 it as info, for cases like this one. Or maybe a second catch clause for
 specific bean validation exceptions that logs its messages as info. But
 then
 again, not every exception thrown by the buildDefaultValidatorFactory has
 to
 be that type. For example, NoClassDefFoundErrors could also occur. What do
 you think?

 Regards,
 Jan-Kees

 2010/9/27 Jakob Korherr jakob.korh...@gmail.com

  Hi,
 
  That's weird, because ExternalSpecifications does this:
 
  beanValidationAvailable =
  (Class.forName(javax.validation.Validation) != null);
 
  Thus it will be true if javax.validation.Validation is on the classpath!
 
  Regards,
  Jakob
 
  2010/9/27 Matthias Niehoff niehoff.matth...@googlemail.com:
   Hey,
  
   I get this message:
   27.09.2010 15:57:32 org.apache.myfaces.util.ExternalSpecifications
   isBeanValidationAvailable
   INFO: MyFaces Bean Validation support disabled I double checked the
   classpath. javax.validation.Validation is on it.
  
   Regards
  
   Matthias
  
   -Ursprüngliche Nachricht-
   Von: Jan-Kees van Andel [mailto:jankeesvanan...@gmail.com]
   Gesendet: Montag, 27. September 2010 13:52
   An: MyFaces Discussion
   Betreff: Re: Bean Validation (JSR 303)
  
   Hey,
  
   If you specify javax.faces.VALIDATE_EMPTY_FIELDS=auto, MyFaces will
   look
  for
   a class named javax.validation.Validation on the classpath. If it is
  found,
   it will try to initialize it, using:
   Validation.buildDefaultValidatorFactory().getValidator();
  
   This call may fail, for instance, because of a configuration error
   in
  your
   bean validation code. And if it does, MyFaces will catch this error
   and
  log
   an error message: Error initializing Bean Validation (could be
 normal)
  
   Afterwards, you should see a message in the log: MyFaces Bean
   Validation support enabled or MyFaces Bean Validation support
   disabled, depending
  on
   whether initalization succeeded or not.
  
   Do you see those log messages?
  
   Regards,
   Jan-Kees
  
  
   2010/9/27 Matthias Niehoff niehoff.matth...@googlemail.com
  
   Yes, using Hibernate Validator 4.1.0 Final and Validation API 1.0.0.
   Is there anything else to configure?
  
   Regards
   Matthias
  
   -Ursprüngliche Nachricht-
   Von: Michael Kurz [mailto:michi.k...@gmx.at]
   Gesendet: Montag, 27. September 2010 13:33
   An: users@myfaces.apache.org
   Betreff: Re: Bean Validation (JSR 303)
  
   Do you have a bean validation implementation like Hibernate
   Validator on your classpath?
  
   regards
   Michael
  
   Am 27.09.2010 13:21, schrieb Matthias Niehoff:
Hi,
   
I'm trying to realize Bean Validation. I annotated my attributes
and set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
 true.
Furthermore I added a h:message tag in my form. When I test the
validation nothing happens. The input is accepted (and in my case
   persisted).
Relevant parts of the Code:
   
Web.xml
   
 context-param
   
param-namejavax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_A
S_N
UL
L/par
am-name
 param-valuetrue/param-value
 /context-param
   
 context-param
 param-namejavax.faces.VALIDATE_EMPTY_FIELDS/param-name
 

commandbutton does not call the backend bean

2010-09-28 Thread Xiaobo Yang
Hi all,

I'm using MyFaces 1.1.5 and Tomahawk 1.1.6 in an application and got a
problem with a button. When I clicked the button, it did not call the
backend bean but stayed in the same page. I noticed the lines below in
the log file.

org.apache.myfaces.lifecycle.LifecycleImpl - exiting from
lifecycle.execute in PROCESS_VALIDATIONS(3) because getRenderResponse
is true from one of the after listeners
org.apache.myfaces.lifecycle.LifecycleImpl - entering
RENDER_RESPONSE(6) in org.apache.myfaces.lifecycle.LifecycleImpl

Could anybody explain what are the possible reasons to cause
PROCESS_VALIDATIONS to stop?

Many thanks,
Xiaobo


Re: Bean Validation (JSR 303)

2010-09-28 Thread Jakob Korherr
Great to hear!

+1 on the additional logging if bean validation is there but fails to
initialize!

Regards,
Jakob

2010/9/28 Jan-Kees van Andel jankeesvanan...@gmail.com:
 Great!

 I guess the logger version mismatch causes a noclassdeffounderror or
 something inside beanval. I guess we need to implement some additional
 logging inside myfaces to debug such issues...

 Regards,
 Jan-Kees


 2010/9/28 Matthias Niehoff niehoff.matth...@googlemail.com

 Thanks for your help. I solved the problem. After I fixed a version
 mismatch
 in SLF4J Bean Validation was enabled. Maybe the initialization checks the
 logger?

 Regards

 -Ursprüngliche Nachricht-
 Von: Jan-Kees van Andel [mailto:jankeesvanan...@gmail.com]
 Gesendet: Montag, 27. September 2010 21:55
 An: MyFaces Discussion
 Betreff: Re: Bean Validation (JSR 303)

 Yeah, but there is more. First, did you package the myfaces jars in the
 application or in a shared library or something? And the same question for
 the validation api and impl jars

 And this Class.forName check is not the complete check. After
 Class.forName,
 we completely initialize the bean validation framework, using the default
 factory. If this fails, I decided to disable bean validation. But in this
 case, you should see more logging. For example the error message,
 explaining
 why the beanval initialization failed.

 You can set the logger for javax.faces.validator to fine to see the
 error message, if any. Otherwise, putting a breakpoint in the
 javax.faces.validator.BeanValidator.createValidatorFactory() method and
 stepping into _ExternalSpecifications.isBeanValidationAvailable() would
 also
 be a very good first step.

 @Committers: I decided to log it as fine a year ago, because I can't decide
 whether or not the exception is important. I didn't want to irritate and
 scare developers when there is no issue. But we might be better off logging
 it as info, for cases like this one. Or maybe a second catch clause for
 specific bean validation exceptions that logs its messages as info. But
 then
 again, not every exception thrown by the buildDefaultValidatorFactory has
 to
 be that type. For example, NoClassDefFoundErrors could also occur. What do
 you think?

 Regards,
 Jan-Kees

 2010/9/27 Jakob Korherr jakob.korh...@gmail.com

  Hi,
 
  That's weird, because ExternalSpecifications does this:
 
  beanValidationAvailable =
  (Class.forName(javax.validation.Validation) != null);
 
  Thus it will be true if javax.validation.Validation is on the classpath!
 
  Regards,
  Jakob
 
  2010/9/27 Matthias Niehoff niehoff.matth...@googlemail.com:
   Hey,
  
   I get this message:
   27.09.2010 15:57:32 org.apache.myfaces.util.ExternalSpecifications
   isBeanValidationAvailable
   INFO: MyFaces Bean Validation support disabled I double checked the
   classpath. javax.validation.Validation is on it.
  
   Regards
  
   Matthias
  
   -Ursprüngliche Nachricht-
   Von: Jan-Kees van Andel [mailto:jankeesvanan...@gmail.com]
   Gesendet: Montag, 27. September 2010 13:52
   An: MyFaces Discussion
   Betreff: Re: Bean Validation (JSR 303)
  
   Hey,
  
   If you specify javax.faces.VALIDATE_EMPTY_FIELDS=auto, MyFaces will
   look
  for
   a class named javax.validation.Validation on the classpath. If it is
  found,
   it will try to initialize it, using:
   Validation.buildDefaultValidatorFactory().getValidator();
  
   This call may fail, for instance, because of a configuration error
   in
  your
   bean validation code. And if it does, MyFaces will catch this error
   and
  log
   an error message: Error initializing Bean Validation (could be
 normal)
  
   Afterwards, you should see a message in the log: MyFaces Bean
   Validation support enabled or MyFaces Bean Validation support
   disabled, depending
  on
   whether initalization succeeded or not.
  
   Do you see those log messages?
  
   Regards,
   Jan-Kees
  
  
   2010/9/27 Matthias Niehoff niehoff.matth...@googlemail.com
  
   Yes, using Hibernate Validator 4.1.0 Final and Validation API 1.0.0.
   Is there anything else to configure?
  
   Regards
   Matthias
  
   -Ursprüngliche Nachricht-
   Von: Michael Kurz [mailto:michi.k...@gmx.at]
   Gesendet: Montag, 27. September 2010 13:33
   An: users@myfaces.apache.org
   Betreff: Re: Bean Validation (JSR 303)
  
   Do you have a bean validation implementation like Hibernate
   Validator on your classpath?
  
   regards
   Michael
  
   Am 27.09.2010 13:21, schrieb Matthias Niehoff:
Hi,
   
I'm trying to realize Bean Validation. I annotated my attributes
and set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
 true.
Furthermore I added a h:message tag in my form. When I test the
validation nothing happens. The input is accepted (and in my case
   persisted).
Relevant parts of the Code:
   
Web.xml
   
     context-param
   
param-namejavax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_A
S_N
UL
L/par
am-name
   

Re: commandbutton does not call the backend bean

2010-09-28 Thread Christian Kaltepoth
Seems like the validation failed for some reason. Did you add a
h:messages to the page? You could also try to skip the model update
(and valdiation) by setting the immediate attribute of the button to
true.

Christian


2010/9/28, Xiaobo Yang xiaobo.y...@gmail.com:
 Hi all,

 I'm using MyFaces 1.1.5 and Tomahawk 1.1.6 in an application and got a
 problem with a button. When I clicked the button, it did not call the
 backend bean but stayed in the same page. I noticed the lines below in
 the log file.

 org.apache.myfaces.lifecycle.LifecycleImpl - exiting from
 lifecycle.execute in PROCESS_VALIDATIONS(3) because getRenderResponse
 is true from one of the after listeners
 org.apache.myfaces.lifecycle.LifecycleImpl - entering
 RENDER_RESPONSE(6) in org.apache.myfaces.lifecycle.LifecycleImpl

 Could anybody explain what are the possible reasons to cause
 PROCESS_VALIDATIONS to stop?

 Many thanks,
 Xiaobo



-- 
Christian Kaltepoth
Blog: http://chkal.blogspot.com/
Twitter: http://twitter.com/chkal