I have created a form using Primefaces 6.0 and in the bean I have used constrained validators like #NotNull and #NotEmpty in the bean fields. However the asterisk near the label of the input text are not automatically rendered. The asterisk is only displayed when I set and an inputText as "required=true". My problem is that I would like to use the validation messages provided by the bean validation JSR so I would not like to put "required"to the input texts. I have also read that after primefaces 5.0 the validation constraints are automatically detected and the asterisk is rendered automatically. Has anyone faced a similar problem? Have I missed any configuration?
i think whatever you want is possible by some custom code, use CSS for asterisk (*) in read color, do not put required=true use custom validate. have look https://www.primefaces.org/showcase/ui/csv/custom.xhtml
if you did not put required=true your form will submmited to bean and you have to check and bean level for validation.
That is a nice to have feature that doesn't exist (yet).
If you want it implemented, log an enhancement feature.
Or extend bean validation component ;-)
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 am dynamically generating some Primefaces input and output components, and I need to be able to disable validation on these components in certain use cases, while still updating the model. (Like a save button). It looks like the proper way to do that in xhtml would be to use <f:validateBean disabled="#{myBean.someCondition}/>
However, I cannot figure out how to create this component dynamically. I searched through the javax.faces package and could not find any validateBean component. I thought maybe it would be a property that I need to set on the UIInput component, but none of the methods outlined in that API seem to what I need.
Is this possible?
Edit:
As a reference, here is the component I am creating:
UIInput input = new InputText();
input.setId(field.getFieldKey());
input.setValueExpression("value", expressionFactory.createValueExpression(elContext, field.getFieldValue(), String.class));
input.addClientBehavior("blur", ajaxBehavior);
input.addValidator(new BeanValidator());
You might want to explore these paths :
Set immediate to true on your input.
input.setImmediate(true);
Extend BeanValidator with an empty validate method and pass an instance to your input.
input.addValidator(new DummyBeanValidator());
Hope this helps.
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.
The scenario is the following:
A managed bean uses as attributes another managed bean, like customerBean.current.customerAgreement. When I display the data on a pge the expression #{customerBean.current.customerAgreement.agreementTitle} is filled and shows the expected output.
However in an inputText the value is only changed on the screen, not in the value I get back in the managedBean. Is there a limitation on how deep such a structure can be constructed?
No, there is basically no limitation in how deep you can nest beans.
Your problem is caused by something else. Perhaps you are not preserving the same parent beans in the request of the form submit as it was during the request of the form display. Hard to tell without further detail about your code. All what I can suggest is to try making CustomerBean a view scoped bean.
I'm loving the jsf 2.0 composite component setup. One other thing I love is prependId="false" on forms. Is there an equivalent that can be defined in cc:interface or cc:implementation that will prevent jsf from creating a j_id to prepend to the ids defined within the composite component?
That's not possible. Just give the component a fixed id instead letting JSF autogenerate one. The same applies on forms by the way. This way you can still select them using CSS selectors.
Or better, just give them a styleClass so that you don't need to select by ID, for the case that this aversion was actually caused by inability to select components/elements by client ID (I don't see other feasible reasons).