Bypass bean validation in JSF2? - jsf

I'm wondering if it's possible to bypass bean validators for certain actions in JSF2.
I've generated entities from my DB schema using NetBeans 7, which include validation attributes.
In my JSF application I have a search screen who's backing bean uses an instance of an entity to hold the user's query parameters. I then use reflection on the entity instance to generate a dynamic query to perform the user's search. Once the user performs the search they can select an item and go off to an edit page where I'd like the validation enforced.
My problem is that on the search screen, bean validation on my entity is enforced. So if my entity has 3 required fields, and the user searches on only 1 of the 3, I get two "field is required" error messages.
I know I could get around this by creating a new class for my search backing bean that doesn't have validation annotations on it, but that doesn't seem like an ideal solution to me: I'd end up with two essentially identical classes, just with different annotations.

You could add f:validateBean with disabled="true" to your first form where you don't want them validated and then not include it on the view where you do:
<h:inputText value="#{entity.property}">
<f:validateBean disabled="#{true}"/>
</h:inputText>

for me in icefaces didnt work like that: i had to :
<f:validateBean disabled="true" >
<ice:outputText value="#{messages['busqueda.bodega.tabla.datos.etiqueta.nombre']}"/> <ice:inputText" value="#busquedaBodegaBean.busquedaBodegaBB. bodegaCriterio.nombre}">
</ice:inputText>
</f:validateBean>

Related

Bean validation using a custom #RequiredWhen validator and required field decorator in JSF

I have defined a custom jsr-303-Validator called #RequiredWhen which is like #NotNull but depending on some condition.
In JSF, whenever I annotate a managed bean property with #NotNull a component like PrimeFaces <p:outputLabel for="that property">, recognizes the property as required and marks it with an asterisk. Is it possible to implement or configure my custom Validator such that the asterisk is shown as well, if the condition in the #RequiredWhen-annotation becomes true? Thanks a lot.
I'm using,
Java EE 6
GlassFish 3.1.2
Mojarra 2.1.29
PrimeFaces 5.2
As far as I can see by now the answer is no: it's not possible to show the asterix by configuring or implementing the custom validator. Looking at the sources of primefaces the check for #NotNull is hardcoded and there is no kind of callback to check for other annotations.
As a first workaround we added a new bean that checks an input field for our custom annotations, eg
<p:inputText id="test" value="#{uiController.data}"
required="#{ContextValidatorDelegate.isRequired('data')}"/>
But after some closer look we removed that delegate. The condition in our custom validator is dependend on properties that the user can modify in the same dialog than the property that is validated. So our validator really is some class level validator. And thus we cannot use the required-attribute, which is processed in validation phase. We need the complete user-input in our model bean. Only after the update model phase a class level validation is meaningful.

pass parameter from f:selectItems in h:selectOneListbox

I have a selectOneListbox that, when clicked, should pass an additional parameter (id) to the server. As it is now, the user sees a list of names and when they select one I can get the name. But, each name also has a unique id associated with it that I don't want the user to see - how can I pass the unique id of the selected name to the backing bean without the user ever seeing it? Is it possible? I was trying to figure out how to use the f:param but I don't see how that will work here.
<h:selectOneListbox id="listBox" value="#{ScheduleMB.clients}" size="5"
rendered="#{ScheduleMB.showClients}" >
<f:selectItems value="#{ScheduleMB.clientList}" var="c"
itemLabel="#{c.lastName} #{', '} #{c.firstName}" itemValue="#{c.lastName}" />
<f:ajax event="click" listener="#{ScheduleMB.clickListener}"
render="group" />
</h:selectOneListbox>
The <f:param> serves a different purpose. Even if the <f:param> was possible, it would still end up being visible in the generated HTML output. The enduser would just do rightclick and View Source and then see the IDs being definied as option values.
Your best bet is to retrieve the ID from the DB based on a different unique identifier, perhaps the unique combination of firstname+lastname.
It does by the way not make any sense to me why you would like to hide the ID from the output. It'd be so much easier if you used that as option value, even more if you used a converter so that you can just pass the whole #{c} as option value. The enduser can't spoof/change it in any way. JSF will revalidate the submitted value against the list of available options (which are definied in server side anyway).

Passing an object stored in a session managed bean in a JSF creation form

I am working in Java EE application which supports authentication and managing some simple objects
After the user has been logged in I store it as an object in a session scoped managed bean. The logged in user can Create a new UNIT object which must be visible only to him. I am doing this using a JSF form. My problem is that I am not being able to pass the current user as the owner of the created unit.
I was trying to do something like this with the inputHidden tag in the JSF Create unit form
<h:inputHidden binding="#{unitController.selected.user}" value="#{loginController.checkedUser}"/>
but it is not working.
I also tried to add a User object as parameter in the CreateUnit method, but I was not sure how to call this method using the Java Expression Language.
Basically,
<p:commandButton value="Save Unit" action="#{unitController.create(#{loginController.checkedUser})}" update="createUnitForm :growlCreateUnit"/>
but still is not working.
Can somebody help please?
Replace
<p:commandButton value="Save Unit"
action="#{unitController.create(#{loginController.checkedUser})}"
update="createUnitForm :growlCreateUnit"/>
with:
<p:commandButton value="Save Unit"
action="#{unitController.create(loginController.checkedUser)}"
update="createUnitForm :growlCreateUnit"/>
EL expressions cannot be nested.

JSF Required=Yes not working inside a datatable?

I searched everywhere but could not find a solution to this. I am trying to used
required=yes to validate whether a value is present or not. I am using it inside inputtext.
The problem is it does not work inside a datatable. If I put the text box outside the datatable it works. I am using JSF 1.7 so I don't have the validateRequired tag from JSF 2.0.
I even used a validator class but it is still not working. Does anyone know why does required=yes or validator='validationClass' inside a inputtext inside a datatable is not working.
I appreciate the help.
Thanks.
First of all, the proper attribute values of the required attribute are the boolean values true or false, not a string value of Yes. It's an attribute which accepts a boolean expression.
The following are proper usage examples:
<h:inputText required="true" />
<h:inputText required="#{bean.booleanValue}" />
<h:inputText required="#{bean.stringValue == 'Yes'}" />
As to the problem that it doesn't work inside a <h:dataTable>, that can happen when the datamodel is not been preserved properly (the datamodel is whatever the table retrieves in its value attribute). That can in turn happen when the managed bean is request scoped and doesn't prepare the datamodel during its (post)construction which causes that the datamodel is null or empty while JSF is about to gather, convert and validate the submitted values.
You need to ensure that the datamodel is exactly the same during the apply request values phase of the form submit request as it was during the render response phase of the initial request to display the form with the table. An easy quick test is to put the bean in the session scope. If that fixes the problem, then you definitely need to rewrite the datamodel preserving logic. You could also use Tomahawk's <t:saveState> or <t:dataTable preserveDataModel="true"> to store the datamodel in the view scope (like as JSF2's new view scope is doing).
Finally, JSF 1.7 doesn't exist. Perhaps you mean JSF 1.2?

What is the JSF behaviour, if you bind the same backing bean property to two input fields in the same form?

Is there a defined behaviour in JSF, if two input fields are bound to the same session scoped Backing Bean property.
Here is my code snippet
<h:form id="myForm">
<h:inputText id="field1" value="#{TheBackingBean.theProperty}" />
<h:inputText id="field2" value="#{TheBackingBean.theProperty}" />
<h:commandButton id="continueButton" action="#{TheBackingBean.doSomething}" />
</h:form>
My question: If field1 and field2 receive different values, what will be bound to the backing bean property? Is this even allowed?
I know this is a crude scenario. My motivation is, that we have htmlunit tests running for our application. In our JSF application we want to use a cool ajaxified custom component. This doesnt work together very well with htmlunit. So my idea was, I just put in a hidden field that binds to the same property. The unit test then fills the hidden field instead of the "real" thing.
Regards
I think this kind of code is allowed, but I am not sure of the value of theProperty after the submission. What I think is that JSF will do the following:
TheBackingBean.setTheProperty(field1.value);
TheBackingBean.setTheProperty(field2.value);
However, nothing - as far as I know - specifies the order of the setter calls. Thus, after the update values JSF phase, you will not be sure if theProperty will be equal to field1.value or field2.value.
Concerning your scenario, you say that you want to bind the same property to an inputText and an hiddenText. As the hiddenText will not submit its value, unlike the inputText, this problem will not occur. Indeed, if you have this kind of JSF code:
<h:inputText id="field1" value="#{TheBackingBean.theProperty}"/>
<h:inputHidden id="field2" value="#{TheBackingBean.theProperty}"/>
then JSF will only do:
TheBackingBean.setTheProperty(field1.value);
during the submission phase.

Resources