I have a couple of mandatory PrimeFaces 5.2 <p:autoComplete> components in my JSF 2.2 page tied to a #ViewScoped bean. The page consists of the following mandatory elements:
Employee (p:autoComplete)
Order (p:autoComplete)
Location (p:autoComplete)
WorkingTime (p:inputText)
Description (p:inputTextArea)
DaysOfBookkeeping (custom component for a multi date picker).
When I complete the form and submit the record immediately, everything works fine. When I leave the form alone for a couple of minutes before hitting the submit button, I get validation errors for "Order" and "Location", even though the values in the form are still present and the HTTP-POST is exactly the same as during the successful submit. In the HTTP-Post I can see, that the values for "Order" and "Location" are set, just like during the succesful HTTP-POST. I never get any validation errors for "Employee", even there's no difference between the three p:autoComplete elements.
javax.faces.partial.ajax=true&javax.faces.source=NewTimesheetForm%3AsH_submit&javax.faces.partial.execute
=%40all&javax.faces.partial.render=NewTimesheetForm%3Agrowl&NewTimesheetForm%3AsH_submit=NewTimesheetForm
%3AsH_submit&NewTimesheetForm=NewTimesheetForm&NewTimesheetForm%3AMain_employeeAutoComplete_input=Sebastian
+Lang&NewTimesheetForm%3AMain_employeeAutoComplete_hinput=df27af76-9937-4e28-bee8-66a000f0ce9c&NewTimesheetForm
%3AMain_dateArray_input=&NewTimesheetForm%3AMain_dateArray_datepicker=&NewTimesheetForm%3AMain_wspOrderAutoComplete_input
=Development+(Kolibri)& NewTimesheetForm%3AMain_wspOrderAutoComplete_hinput=21c2259e-08bf-4a98-b718-8be67dba3b55&NewTimesheetForm%3AMain_locationAutoComplete_input=Wien&NewTimesheetForm%3AMain_locationAutoComplete_hinput
=15e41fee-ef98-4176-a118-032cef4e4c02&NewTimesheetForm%3AMain_workingTime=12&NewTimesheetForm%3AMain_description
=123&javax.faces.ViewState=15843050982783687%3A7588832336313498775
Any ideas what might be the reason for the validation errors?
PrimeFaces 5.2
Mojarra 2.2.10
Wildfly 9.0.1
I was using the wrong converter. This is the right way to do it: http://showcase.omnifaces.org/converters/ListConverter
Related
I have a column of checkboxes and I want to get this effect that when you select 3 of them the rest of checkboxes disables. I've tried everything but I can't make it to do it instantly after clicking on a checkbox (it happens when I reload a page). Every response for that problem is using <f:ajax> but I'm using JSF 1.2 (and I can't use JSF 2 in this project). Is there any way to get through my problem?
Thanks in advance!
I've got a very strange problem here. I have a rich:popupModal which is used to edit an entity. Some of the input fields on that modal use a validator. There is also some ajax going on which is used to update other fields on that modal. There is e.g. a 'Number of packages' field, a weight per package field and a total weight field. If you change the number of packages it will update the total weight field, etc.
Now when e.g. the user entered a value that is too high, the validation fails, an error message is shown. The user can either correct the values on the modal or press cancel.
When he cancels the entity is reset to the values it had before the edit (there were some ajax changes so I need to reset those). The modal closes and a table is showing the correct (reset) values for that entity.
Now the strange thing happens. When I edit another entity the modal is suddenly showing the old values for the previous entity (the ones that did not pass validation).
To debug this I was checking whether the correct instance of the commodity is used so I added h:outputText fields for some of the values and I am also showing the System hash of the entity on the modal.
I've got e.g.
<h:outputText value="#{backingBean.entity.description}"/> which prints 'Stuff 1'
and then
<h:inputText value="#{backingBean.entity.description}"/> which prints 'Stuff 3' (the first entity I've edited). WTH?
I've added getter and a dummy setter on the entity to return the System.identityHashCode. And h:outputText and h:inputText use indeed a different entity but how is that possible when the EL is #{backingBean.entity.hashId} in both cases?
I've used the richfaces a:log to see whether that shows any errors but it all looks okay.
I have tried to clear the modal on cancel (rerender it with no components in) but that didn't fix the problem either. I've tried it on both Chrome and Firefox. Both have the same problem.
What could be going on here?
My environment: JSF 2, Seam 2.3, RichFaces 4.3.3, JBoss EAP 6.1
Technology: Java EE 6, JSF 1.1, ajax4jsf
I'm representing a selectOneMenu to the user (dropdown-list) that is pre-filled with all the legal values the user can submit. Let's say it's datevalues:
01.01.2010
01.01.2011
01.01.2012
The selected value in the dropdown-list is bound to a property on a backing object (form.chosenDate) and the values in the list is retrieved from a list on a backing object (form.selectableDates). form.chosenDate is updated with a4j as the user selects different values.
The question is, is it possible for the user to submit the form with other values than the list was populated with (values in form.selectableDates)? If so is the case, how can this be done? In the dev-tools in Google Chrome, I can manipulate the html and change the values "runtime", but when I submit, the dropdown-list is refreshed with the original values, and I have to submit again. Is this enforced by Google Chrome or JSF?
The question also goes for radio-buttons. Please enlighten me!
Yes, it is possible for user to submit a value that is not in the dropdown. Tamper data plugin for Firefox could do this for example. However, it will fail the JSF validation as the submitted value is checked against the list to see if it is contained in it. The user will get a "form:location: Validation Error: Value is not valid" error message.
I have upgraded from JSF 1.1 to JSF 2.0. Earlier I was using f:validateLongRange or f:validateDoubleRange and the validation worked fine. However, since I have migrated to JSF 2.0 the validation message precedes with client ID which looks something like below :
FormID:ClientID:0:ComponentID in my case, the message appears as
premiumCategory:j_idt368:0:tlNewLOS: Validation Error: Specified attribute
is not between the expected values of 1 and 999,999.
There is a Jira which talks about prefixing ClientID but I dont think its of any use to me.
I learnt from the blog Communication in JSF 2.0 these tag handlers do not work correctly in JSF 2.0 thus we should create custom validators using f:validator
I followed BalusC’s answer from here; The only difference was I did not get my max and min values from the bean, I specified them in the xhtml,it still printed the validation message as stated above.
While debugging I realised that the client ID is generated as FormID:ClientID:0:ComponentID and is stored in the UIComponent instance which gets passed to the MessageFactory.getMessage method.
The same blog which I mentioned before has a topic in it saying "Ajax rendering of content outside form" which I thought would have a solution to my issue, but again no luck.
Now I have my own custom validator class which extends to DoubleRangeValidator and overrides validate method. I get the desired message. However, I am not convinced that writing a custom validator for each f:validatorXXXX component is the solution.
I am still on my learning curve, can anyone explain me why and where MessageFactory.getMessage binds these IDs to to the faces message?
Please advise,
Dakshata Gulkhobare
The label is overrideable by setting the label attribute on the input component of interest.
<h:inputText ... label="Your label" />
This way the validation message will be formatted as follows:
Your label: Validation Error: Specified attribute
is not between the expected values of 1 and 999,999
Otherwise it will indeed default to the component's client ID.
If you happen to use <h:outputLabel> already and would like to use exactly its value, but don't want to duplicate it into the label attribute of every single input component, then you may find OmniFaces <o:outputLabel> helpful.
I guess I knew the difference, but right now I find myself confused. :P
Both of them seem to be do the same thing, except that partialSubmit is used on submit buttons to submit the form using AJAX and autoSubmit is used on editable components, which submits only its own contents. Am I right in saying this?
The accepted answer isn't 100% correct for ADF. The partialTriggers attribute is involved in the lifecycle.
From Enabling Partial Page Rendering Declaratively
The autoSubmit attribute on an input component and the partialSubmit
attribute on a command component are not the same thing. When
partialSubmit is set to true, then only the components that have
values for their partialTriggers attribute will be processed through
the lifecycle. The autoSubmit attribute is used by input and select
components to tell the framework to automatically do a form submit
whenever the value changes. However, when a form is submitted and the
autoSubmit attribute is set to true, a valueChangeEvent event is
invoked, and the lifecycle runs only on the components marked as root
components for that event, and their children. For more information,
see Section 4.4, "Using the Optimized Lifecycle".
They are both AJAX enabled calls occurring from custom properties of custom JSF components. The autoSubmit essentially asynchronously postsback content specific to the component for keeping the server side managed bean values current with the content within the component on the client side.
A partialSubmit is another asynchronous AJAX call that will serve to immediately postback a component value on some kind of component event, like losing focus on an ICEFaces inputText component for example.
The interesting thing to note is that the entire ViewState is posted back on each type of asynchronous submit, so if the values of other components HAD changed on the page before the submit, the bound server side managed bean properties will have their values refreshed as well, even though the client side components MAY not be refreshed to reflect any server side data changes that may have occurred.
In fact, the entire JSF server side lifecycle occurs on each postback, read the following article on implementing a debug PhaseListener that allows you to see what Phases are occurring after each asynchronous submit operation occurs.
http://balusc.blogspot.com/2006/09/debug-jsf-lifecycle.html