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.
Related
I am a JSF beginner. I have a question about managed bean.
Step 0:
There is a managed bean BeanA, scope is request. And BeanA instance1.propertyA = "0";
Step 1:
using ajax to change country, then in BeanA.countryChanged method, change managed bean BeanA.propertyA = "A".
<t:selectOneMenu id="Country" required="true" valueChangeListener="#{BeanA.countryChanged}">
<a4j:support event="onchange" limitToList="true" ajaxSingle="true" />
<f:selectItems value="#{BeanA.countries}" />
</t:selectOneMenu>
Step2:
submit form to do validate a text input
<h:inputText id="street" required="#{BeanA.propertyA == "A"}"
I expect that in step2 the value propertyA of BeanA instance2 should be "A" in JSF validate phase, but actually it is "0". I don't know how does JSF load BeanA instance property values to create new BeanA instance. And what should I do, the value will changed to "A"? Thanks,
The symptoms indicate that your bean is request scoped. This means that it's reconstructed on every single HTTP request. You probably didn't realize that every single ajax request also counts as a separate HTTP request. In effects, you're not reusing the same bean instance across ajax postbacks on the same view. Every time a brand new instance is been created, with all its properties set to default.
JSF 2.0, which is designed with ajax in mind, has solved it with the new view scope in the standard API.
In JSF 1.x, you need to fall back to 3rd party component libraries. In your particular case, given that you're using both Tomahawk and Ajax4jsf, you've 2 options:
Use <t:saveState>.
<t:saveState value="#{BeanA}" />
Or, use <a4j:keepAlive>.
<a4j:keepAlive beanName="BeanA" />
I'm trying to pass an object to another site. So i have my Gallery.xhtml where I set an object as current and redirect to another page:
<h:form>
<a4j:commandButton value="Edit Skin"
action="#{helloBean.setCurrentSkin(skin)}"
onclick="window.location.href = 'resources/html/Editor.xhtml';" />
</h:form>
But when the getter on the second page is called, the current object is null again.
Is the bean generated for each page? How could I achieve this?
My Problem was that I declared my bean as #ViewScoped, but the proper Tag is #SessionScoped. This makes sure that the Bean holds its values for the whole session and not only one view.
I know there is a property in asp.net (probably this EnableEventValidation of "<%# Page%> tag) .Which, once caused problem when i try to add select items to a component using javascript ,I want to know how jsf handling this. That is,
if i send a h:select* like below and client add a new item "option3 " to item list, is jsf detect this automaticly before update model values .
<h:selectOneMenu id="type"
value="#{foo.value}"
required="true"
requiredMessage="Type is required"
style="width:100px">
<f:selectItem value="option1}"/>
<f:selectItem value="option2}"/>
</h:selectOneMenu>
I think what you need to understand regarding JSF is that the client/server parts of the components are tightly coupled together. You are probably better off thinking of them strictly as one entity, and forget about fiddling with one side only, reverting to custom Javascript when that is the only solution left.
The other way to think of it is that the server side renders the client side, not vice versa! So whenever you need to update a component the update must be done on the server side first, which will propagate to the client side (the browser).
In your example the proper way to add and element to the select* items is to store the selectable items in a data structure within a bean (probably #ViewScoped), and then do a partial update via AJAX for the select* component or its container component, when the server side gets the chance to become aware of the changes and can update the client side properly as well.
Sure, you can hack your way through Javascript only, but then why use JSF? The whole point of JSF is to avoid the need for hacks like this.
Remember, JSF is not JSP, which is basically a println macro for html output. JSF stores the page components' representation on the server side, mirroring the browser's representation.
Check the Primefaces showcase for examples on how to do partial updates. More specifically this is the example you could be looking for. This is available in standard JSF2, for JSF 1.2 you must use a component library to get AJAX support.
You should not add the new option by JavaScript, but you should add the new option by JSF. JSF needs to know about the new option somehow in order to allow the submitted value. The new option really needs to be served by <f:selectItem(s)>. Otherwise you will face Validation error: Value not valid all the time when submitting the option value which is added by JS. This is after all just a safeguard of JSF to prevent clients from manipulating the request and submitting values which they are not supposed to submit.
The following kickoff example should work:
<h:form>
<h:selectOneMenu id="menu" value="#{bean.item}">
<f:selectItems value="#{bean.items}" />
</h:selectOneMenu>
<h:inputText id="newItem" value="#{bean.newItem}" />
<h:commandButton value="add" action="#{bean.addNewItem}">
<f:ajax execute="#this newItem" render="menu" />
</h:commandButton>
<h:commandButton value="submit" action="#{bean.submit}" />
</h:form>
with a #ViewScoped managed bean something like follows:
private String item;
private List<String> items = Arrays.asList("option1", "option2");
private String newItem;
public void addNewItem() {
items.add(newItem);
}
// ...
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>
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.