I'm trying to retrieve a value from an input text in my jsf page, but when I change its value it doesn't change in the managed bean.
here's the input text:
<af:inputText label="Código:" id="codigo" value="#{tipoBaixaBean.codigo}"/>
and my managed bean is annotated like this:
#ManagedBean
#RequestScoped
public class TipoBaixaBean {
private long codigo;
I have the getters and setters, but the value of the property "codigo" never changes,
What would be the problem??
Thank you
Change your Bean scope to 'pageFlowScope' or 'viewScope' in adfc-config.xml . That should do.
You don't say when you are trying to get the value...on page submit or when you tab out of the field. If you want the value when you tab out (lose focus) then set the autoSubmit property on the input text field to true.
I would also suggest using a print statement in set method to make sure it's being called. The scope issue only arises if you are trying to retain the value between page requests.
Not sure how can you bind an inputText to a long object in backing bean.
Ideally it should be something like
private RichInputText codigo;
you can get the value of codigo using the getter.
getCodigo.inputValue();
I don't think scope will cause any problem. It works for the least life scope i.e. backing bean scope.
It really depends on the exact moment in which you are getting/setting the value, but if you need to do it automatically every time a change occurs, then you'll need to implement the Value Change Listener. Check this out: Value Change Listener example
Related
When a JSF form field is wired into an entity bean field (which is mapped to a DB field), each setter in the entity bean is called regardless of whether the user changed the form field value in the front end, i.e. the setters on unchanged fields are invoked the same as those that have changed but their new value is the same as the old value.
My question is simple: Is there a way to configure JSF to only call the setters mapped to the fields that have changed in the front end? The reason for this is that I have a requirement by which I have to detect deltas on every persist and log them, more about which can be read in this question.
Maybe I didn't understand you clearly, but why are you mapping directly your entity beans to a JSF view ?! IMHO it would be better if you add managed beans between your JSF pages and the entities in order to better separate your business logic from data access.
Any way, I think the easiest solution to impelement for that case is by making use of Value Change Events which are invoked "normally" after the Process Validations phase (unless you make use of the immediate attribute).
The good news about Value Change Events (regarding your example) is they are invoked ONLY after you force form submit using JavaScript or Command components AND the new value is different from the old value.
So, as an example on how to use value change listeners, you can add valueChangeListner attribute to each of your JSF tags like following:
<h:inputText id="input" value="#{someBean.someValue}"
valueChangeListener="#{someBean.valueChanged} />
Then, implement your valueChanged() method to look something like:
public void valueChanged(ValueChangeEvent event) {
// You can use event.getOldValue() and event.getNewValue() to get the old or the new value
}
Using the above implementation, may help you to separate your logging code (it will be included in the listeners) from your managed properties setters.
NB: Value Change Listeners may also be implemetend otherwise using the f:valueChangeListener Tag, but this is not the best choice for your example (you can find some examples in the section below, just in case)
See also:
Valuechangelistener Doubt in JSF
JSF 2 valueChangeListener example
When to use valueChangeListener or f:ajax listener?
I wrote two pages...one a form where data submitted and second just to confirm the transaction actually carried out some calculation.
I have a managed bean i.e. FormDataBean and a class Reservation.java from which i instantiate for each booking made. Now I have at the end of a form a submit button:
<h:commandButton value="Submit" action="confirmation"/>
in the bean I have setters and getters as usual. in a method i defined I create an instance of Reservation, then set the beans variables to the instance variabels, like
reservation.startDate = startDate;
reservation.endDate = endDate;
reservation.checkRange();
The last method, i.e. checkRange() will use the assigned values to instance variables to carry calculation. it should return a string successful or failure.
Now when I enter data in the form, and press submit, it just refreshes the page but nothing is submitted. because it doesn't go to next page :(
Any idea what is happening? I don't need to define a navigation rule, because in other project, I carry out simple calculation and display result in next page and it worsks! Please advice
Thanks,
Your are missing to tell us some of the more important details so the answer is a kind of guesswork.
As you don't use navigation rules I assume you are using JSF 2, aren't you?
With JSF 2 you can directly set the new navigation target, without navigation rules. A forward to "confirmation" should work if your outcome file is named confirmation.xhtml. Check that. With a navigation rule you could forward it do a different file.
This part should work regardless of the rest.
For the bean not getting any values make sure that you are using the correct scope either through annotation or entry in your faces-config.xml. As you have a quite unusal validation mechanism you probably have to use the session scope.
The correct way would be using an actionlistener that does your checks and then sets the navigation depending on your checks. The bean scope could be more restrictive then.
Did you try action="confirmation?faces-redirect=true"?
I have a scenario and dont have a clear idea for this to work yet.
Here's the example scenario :
I have a myView.xhtml file that can be displayed as a window popup or a primefaces dialog popup from 2 other container xhtml, let's say container1.xhtml and container2.xhtml (the myView.xhtml is included with something like this ? <ui:include src="myView.xhtml" />)
And, we also have the view-scoped beans, let's call them myViewBean, container1Bean and container2Bean
container1Bean has the property of transactionDate, and container2Bean has a property of transDate
myViewBean's #PostConstruct method will query the database based on a parameter of type date.
On container1.xhtml, if a user clicks on a button that will popup the myView.xhtml, container1Bean should be able to provide it's transactionDate to the myViewBean, and myViewBean will be able to query based on it in the #PostConstruct method.
On container2.xhtml, if a user clicks on a button that will popup the myView.xhtml, container2Bean should be able to provide it's transDate to the myViewBean, and myViewBean will be able to query based on it in the #PostConstruct method.
I was thinking about using #Inject Container1Bean and #Inject Container2Bean in the MyViewBean, so that inside MyViewBean, i can get the transactionDate of container1Bean or transDate of container2Bean. To decide which container bean is active is to check which one is not null.
But what if the container beans grows, there could be other container beans that make use of the MyViewBean, and the #Inject ContainerXXBean will grow in numbers inside the MyViewBean. There must be other solutions for this.
Please share ideas on how to accomplish this .. Thank you ! :-)
Thank you !
If you want to access only the contents of the other beans you can do that programmatic.
Get the current instance of the FacesContext inside from one bean. And using that context you can grab the instance of other beans.
See this illustration. As per the title of your question, you want to some information between beans. You can accomplish this by calling the other bean's public methods, which may be specifically created for this purpose. (setters-getters).
If container1Bean, myViewBean and container2Bean share some properties, why not putting them in a new bean ? (let's call it sharedBean, but I'm sure you'll find a better name adapted to your case). You could then inject sharedBean using #ManagedProperty in every dependent bean. Let's just try not to have circular references.
I'll also suggest to review your architecture. Are you sure you need all thoses beans, partitionned exactly like this? This sounds like something which will be difficult to maintain.
I am new to JSF and managed beans. I have a managed bean with some private property with public setter and Getter methods. Now when I add the managed bean's properties to JSF forms, should I add the private methods directly or should I use call the property by Getter methods?
For example:
<h:inputText value="#{BeanName.userName}"/>
<h:inputText value="#{BeanName.getUserName()}"/>
Which one is correct in above?
Assuming that you're using JBoss EL or EL 2.2+, both ways would work fine in the initial display. But the first one is actually more correct because the second one would only get the value, but never set the value. If you want to collect input values, you should always go for the first way. The EL (Expression Language) will then automatically locate the getUserName() and setUserName() methods whenever needed.
The second way will never work when you're using standard JSF EL implementation since it doesn't support direct method calls.
To learn more about JSF, start at our JSF wiki page.
If in your java class you have something like
....
private String coolStuff;
public String getCoolStuff() {
return coolStuff;
}
....
Then in your jsf page you access it like so:
#{myBackingBean.coolStuff}
The framework automatically looks for a method called getCoolStuff()
Hope that helps
number 1 is correct from above it is the private field that you connect if you are using EL with JSF in your form.
You still need the getter and the setter which the managed bean calls to get the values so you can save them in a database ....etc
action method is not called Please refer to this question - , One of my UICommand Component is rendered conditionally , it was said in the answer of the linked question - point 5 - that if the Component's or any of its parents rendered or disabled attributes are false - then the action method will not be called ? If thats the case- How do i achieve the same functionality? Is there a work around ? or a trick ? or any other approach ?
Thanks!
To the point, you'd like to retain the property responsible for the rendered condition in the subsequent request. There are several solutions for this problem:
Put bean in session scope. It's easy, but it hurts. It's bad for user experience since changes will be reflected in all tabs/windows the user has open in the same session.
Use <h:inputHidden> to transfer the property. In theory easy, but in practice it hurts as well. The value will namely get lost whenever a validation/conversion error has occurred in any of other inputs in the same form. This is an odditity in how JSF handles hidden input elements. A workaround is to use <h:inputHidden binding="#{bean.hidden}"> and do a hidden.getValue() and hidden.setValue() in bean.
If you're using <h:commandLink> instead of <h:commandButton>, then you can use <f:param> to transfer the property. It will be available as request parameter, you can check for it in bean's (post)constructor.
Use Tomahawk's <t:saveState>. The perfect solution as far. This will retain the value (or even a complete bean) in the subsequent request.
If you're already on JSF 2.0, the #ViewScoped would have solved this all. It behaves like the <t:saveState>.
See also:
commandButton/commandLink/ajax action/listener method not invoked or input value not updated
The trick is to have 'rendered' evaluate to true when it is time to run the action and then change the condition to false in the action method.
Let's say you have a link rendering based on a boolean in your bean called 'editing'. Then your action would look something like this:
public String myAction() {
// whatever you want your action to do
editing = false;
}
Edit: this assumes that the bean is either session scoped or the boolean get propagated between requests.
In my case, Javascript came for rescue, Which means, whatever was to be displayed conditionally , put them in a HTML Portion and don't display them display: none until the desired event occurs.
HTML Portion can have any JSF Tags(including CommandButtons) as you wish and would work (invoking the action methods and the stuff )perfectly okay.