• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

why is p:commandButton firing action method in this code called multiple time?

 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i am having a problem with  pcommandbutton's action method executing more than once. four times to be preciece.
here's is the view:



and here's the method being executed four times;



how do I solve this?
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why do you have a PropertyActionListener on the "Submit" button?
 
Victor Ade
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:Why do you have a PropertyActionListener on the "Submit" button?


to 'set' a backing bean property. bad practice? is it why submit fires four times?

 
Tim Holloway
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Terrible practice.

Backing bean properties are automatically set when an action is fired. You do not need any special tags or logic (except for the POJO set/get methods) for that to happen.

In fact, the standard JSF lifecycle works like this when a commandButton or commandLink is clicked:

1. The JSF form is submitted to the server.

2. JSF reads the input control values from that form and validates them.

3. IF AND ONLY IF ALL form input values are valid, JSF will use the backing bean's property "set" methods to update the backing bean.

4. Once the backing bean has been updated, the action method will be invoked.
 
Victor Ade
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:Terrible practice.

Backing bean properties are automatically set when an action is fired. You do not need any special tags or logic (except for the POJO set/get methods) for that to happen.

In fact, the standard JSF lifecycle works like this when a commandButton or commandLink is clicked:

1. The JSF form is submitted to the server.

2. JSF reads the input control values from that form and validates them.

3. IF AND ONLY IF ALL form input values are valid, JSF will use the backing bean's property "set" methods to update the backing bean.

4. Once the backing bean has been updated, the action method will be invoked.


here's  the idea tim[note that I am self-learning jsf]
logged-in users are permitted to comment on threads and the property setThread in the bean below is used to set the name of the thread users will be commenting on. is there a way I could have setThread other than I did?
I wish I could explain to you better but, here is the full editor view code  to get a full picture

 
Tim Holloway
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The downside of free help is that there's a limit on how closely I'm going to read any code that doesn't fit on a single screen. So I try and deduce what you're attempting based on common use cases.

I'm going to assume that you have a View with a backing bean and you want to navigate to a new View with a different backing bean. How to get a property of the first backing bean into the second backing bean?

Answer: Consider making the second bean's property a Managed Property. Managed Properties are indicated using the @ManagedProperty annotation (or its XML equivalent in faces-config). The ManagedProperty value is an EL expression, just like you code them on forms. So, for example:



There are certain considerations. For this to work properly, the injected bean must have a lifespan that includes the bean being injected into. Specifically, no RequestScope beans (Request scope is almost 100% useless in JSF anyway). Also, if the injected bean was created from a different View than the target bean, ViewScope won't work. Session and Application scope work the best.

JSF is very heavily based on Inversion of Control - the principle that stuff gets delivered to you from the framework instead of making you have to go out and get it yourself. If you don't understand IoC, then that's something you should study.
 
Victor Ade
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:The downside of free help is that there's a limit on how closely I'm going to read any code that doesn't fit on a single screen. So I try and deduce what you're attempting based on common use cases.

I'm going to assume that you have a View with a backing bean and you want to navigate to a new View with a different backing bean. How to get a property of the first backing bean into the second backing bean?

Answer: Consider making the second bean's property a Managed Property. Managed Properties are indicated using the @ManagedProperty annotation (or its XML equivalent in faces-config). The ManagedProperty value is an EL expression, just like you code them on forms. So, for example:



There are certain considerations. For this to work properly, the injected bean must have a lifespan that includes the bean being injected into. Specifically, no RequestScope beans (Request scope is almost 100% useless in JSF anyway). Also, if the injected bean was created from a different View than the target bean, ViewScope won't work. Session and Application scope work the best.

JSF is very heavily based on Inversion of Control - the principle that stuff gets delivered to you from the framework instead of making you have to go out and get it yourself. If you don't understand IoC, then that's something you should study.



Thanks tim, i'll sure readup on IOC.
to solve my p:commandButton issue i changed my method to an action event as adviced by somepeople online like so:

added the following to commaandbutton


however, i when i click  on submit button in jsf i get the following error;



what could be the cause?
 
Tim Holloway
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Get rid of the propertyActionListener. It doesn't do what you think it does.

Also, action methods should not declare Exceptions. I think they're technically allowed to throw FacesExceptions, but regardless,there's really nothing on the other side that's going to catch them meaningfully anyway.

If code in or called by an action method is going to throw exceptions, the action method is expected to catch them and handle them. Navigate to an error page or something.

And unless the PrimeFaces commandButton is different than core JSF, action methods don't expect arguments, either. The data is updated by JSF, so there's no need to send in parameters, and an action is an action is an action. Only AJAX listener methods take Event parameters.

None of the above may fix your problem, but at least you'll be closer to how JSF is intended to work.
 
reply
    Bookmark Topic Watch Topic
  • New Topic