I've did a page via JSF where the user can enter some values in a form. If the user is fine with the input, he can click a submit-button which updates the Model with the new values.
What I'm trying to achieve is: I want that the validation of the input is triggered every time, the user enters a sign into the input field. But at this time, the model should NOT be updated. The model should only be updated, if the user clicks the submit-button. I want this behaviour for a better userexperience. The user should have the ability e.g. to press the Back-Button in the browser and his changes are not attached to the model. Also I want the user to see at inputtime, if he enters some bullshit.
Currently my JSF-File looks like this:
<h:inputText
required="true"
requiredMessage="Please enter a value."
id="input_value" value="#{myBean.myValue}"
styleClass="input"
validatorMessage="Please enter a value." >
<f:ajax
event="keyup"
execute="input_value"
render="input_value"/>
</h:inputText>
This triggers the validation everytime the user enters a sign into the input field. But it also updates the model. And thats not what I want.
This is not possible. At least not without hacking in the JSF impl.
Fortunately you mentioned the X of your XY-problem so this can be reasonably answered:
I want this behaviour for a better userexperience. The user should have the ability e.g. to press the Back-Button in the browser and his changes are not attached to the model
To solve that, just instruct the browser to never cache dynamic pages. Detail can be found in this Q&A: Avoid back button on JSF web application. You also need to make sure that you choose the right bean scope for the data it holds. I.e. do not put view scoped data in a session scoped bean. Those form beans must be at most view scoped. See also How to choose the right bean scope?
Related
I have a login form that has both touchOnBlur and touchOnChange set to false. In basic user flows, the Fields are all getting marked as touched when the user clicks the login button. That's great.
In more complex user flows, like when the user opens the forgot password modal and then closes it, Fields no longer get marked as touched. This is causing my validation errors to be hidden (because we check for meta.touched before drawing errors).
So I'd like to know exactly what sets touched to true on my Fields when the form is submitted.
I'm using version 7.2.1.
I’m struggling to get my bean to update with the new page values. I have two submit buttons on my page and I toggle which one displays based on a Boolean value for what mode my page is in. When my page is in update only (no validation) I show the submit button that has immediate=”true”. When the page is in process mode (validate) I show the submit button that does not have immediate=”true”.
The problem I’m running into is when I am in update mode (no validation) the values in the input fields are not being set in the bean. All I want to do when in this mode is save the page as is and exit. No validation is needed because the information on that page is not ready to process or “really use” if you will. That said, if I have my page in process mode (validate) then everything works as intended. Values are submitted and saved.
I’m not posting any code yet as there is nothing special about what I’m trying to do. I simply have a value binding that points to simple getter / setter. My bean is in #ViewScope.
I’ve tried using the examples by BalusC in his excellent blogspot post: debug-jsf-lifecycle.
Putting immediate=”true” on the input fields has no affect when clicking on the submit button with immediate="true". All and all though, the way I understand it is immediate=”true” on the UICommand is what tells the application to skip validation or not. Putting it on the input fields simply makes validation happen sooner. Am I missing something?
Any ideas? Any and all help with this is most appreciated!
App specifics:
JSF 2.0.3
Tomcat 6.0.14
The immediate="true" is not intented to disable validation. It's intented to either prioritize validation or to skip processing of the input altogether. See also the summary at the bottom of the article.
You need to disable validation by setting required="false", or <f:validator disabled="true">. Here's an example which assumes that you've a boolean process property which represents the form's state:
<h:inputText value="#{bean.value1}" required="#{bean.process}" />
<h:inputText value="#{bean.value2}" required="#{bean.process}">
<f:validator validatorId="someValidatorId" disabled="#{!bean.process}" />
</h:inputText>
...
This way the fields aren't required and won't be validated when process evaluates false.
Here is the issue, JSF validation keeps flipping a field back to the last known value.
We are editing a page where the backing bean already has values.
(frequency = "weekly")
And we are required to show the default value of "please select.." even though that value will not pass validation (yes, I just want to leave the user on the page with the error message).
Is there any way to allow the user to choose "Select.." and not reset it to the last good value?
The user wont be allowed to save obviously, but we want to leave their invalid value selected.
User adds new object, selecting proper value from drop down
User saves successfully.
User Clicks "edit" and displays object with known value ("weekly")
User changes "weekly" to "select"
User clicks save
Validation message is shown (good) but frequency goes back to last value "weekly" (bad, I need it to stay on "Please select.." and let the user fix the drop down manually.
immediate="true" does not work on inputComponents, only commandComponents.
I recognize this, I've reported this more than one year ago as JSF issue 1299. This is still not resolved since it has a low priority. This is not specific to all UIInput components, but to MenuRenderer which is responsible for rendering the HTML <select> elements. All other HTML input elements behave as you would expect, the submitted value will be redisplayed (well, which is actually nothing as well).
Since you're already on JSF 2.0, I suggest you to solve this with a little help of f:ajax so that the dropdown won't be re-rendered and thus keeps its selection.
<h:selectOneMenu id="frequency" value="#{bean.frequency}" required="true">
<f:selectItems value="#{bean.frequencies}" />
<f:ajax render="frequencyMessage" />
</h:selectOneMenu>
<h:message id="frequencyMessage" for="frequency" />
The additional benefit is that the enduser has instant feedback and this is better for user experience.
Currently, a spring application I am working on has several wizards that it is using with Spring's AbstractWizardFormController. During the early stages of development(pre-design phase), the type of "next" button did not matter.
Just to refresh, the Next and Back button are submit buttons with target attributes. So a next button on the first page of a wizard would look like the following.
<input type="submit" name="_target1" value="Next"/>
This is the standard way Spring does wizards on the view. This works fine, given that you want your Next button to be a standard HTML submit button. Otherwise, in my case, If I want a custom button, I am not sure how to do this. I know it is possible, but haven't found any documentation.
I imagine I will need to do a javascript submit, but I am not sure how to set the name of the button, of if something else needs to be done.
I just need to know how I can still extend AbstractWizardFormController, and use custom buttons.
When clicked, HTML submit button submits a form with additional parameter {name}={value}, that is _target1=Next. I guess the value doesn't matter here, controller looks at the name. So, if you want to emulate this with Javascript, you may, for example, dynamically add a hidden field with name = "_target1" before submit.
I'm currently working on a JSF 1.2 project (IBM implementation and a "company layer").
PROBLEM
Here's the situation (numbers of items are just for the example), simple CRUD
List item
I have a list of items
I click on item 2 to see detail
I click on modify, the modification page displays values of item 2
Back to the list with a button "Back" and immediate="true" (because we don't want to submit the modifications)
Detail of item 4
Modify item 4 > Values of item 2 are displayed
BUT
if I set the "immediate" attribute of the "Back" button to false, values of item 4 are OK.
if I set the "disabled" attibute of an inputText component to true, value of item 4 is OK.
if I use <h:outputText value="#{item4.myValue}/> (UIOutput) instead of <h:inputText value="#{item4.myValue}/> (UIInput)
Also, I checked in debug mode that the bean I wanted to display was "item 4" and it was.
WHAT I FOUND
After some research on Google I found that this problem comes from the lifecycle of JSF, although the documentation and solutions found are for specific implementations of JSF.
So I guess it's because the value is populated with "localValue" instead of "submittedValue" (#see EditableValueHolder interface could help understanding), and there are some solutions from these pages
Apache wiki
IceFaces forum
RESULT
It doesn't work (I wouldn't be here, I swear ^^).
The "Refresh" solution is ineffective.
The "Erase input" is scary. I can't admit that I need to reference every input field! Plus I didn't find the setSubmittedValue() method on the UIInput in my IBM JSF.
The "Clear" method is ineffective. I tried on one element, and on the complete component tree with this code
public void cleanAllChildren(List<UIComponentBase> list){
for(UIComponentBase c : list){
this.cleanAllChildren(c.getChildren());
c.getChildren().clear();
}
}
But without success. So here I am.
Did I miss something? is there a nice tricky solution I didn't see? I'm not really familiar with the JSF lifecycle.
Put the bean with request scoped data in request scope, not in session scope.
You probably have the entire list in session to "save" DB calls and all the work to retain values in the subsequent requests inside the same session. You can use a separate session scoped bean for that, e.g. DataManager. Then you should have a request scoped bean to represent the selected item, e.g. DataItem. You can familarize the both beans with help of managed property injection.