I'm trying to make a JSF reload the locale (which is defined in the view)
<f:view locale="#{admin.userLocale}">
<h:commandButton image="images/ukflag.gif" action="#{admin.returnToEnglish}" immediate="true" onclick="window.location.reload()" />
<h:commandButton value="1" action="#{admin.returnToEnglish}" immediate="true" onclick="window.location.reload()" />
<h:commandButton value="2" action="#{admin.returnToEnglish}" immediate="true" onclick="history.go(0)" />
<h:commandButton value="3" action="#{admin.returnToEnglish}" immediate="true" onclick="window.location.href=window.location.href" />
<h:commandLink value="4">
<a4j:support event="onclick" reRender="GeneralConfigForm" action="#{admin.returnToEnglish}" />
</h:commandLink>
</f:view>
I tried all of the above buttons.
They all do the same thing - They call the method the changes the locale, the page reloads but the new locale labels are not loaded correctly.
At this point, if I reload again the changes catch up and the locale is shown correctly.
How do I make the buttons update the local earlier so the page will show the new locale when it is brought up?
Thanks!
P.S - On JSF 1.2
I'm not sure how you got it to work after a refresh. Is the #{admin.userLocale} stored in the request scope instead of the session scope? The first four buttons won't invoke any JSF action at all. The JS function in the onclick get executed first and it changes the current page and hereby the default action is totally aborted. The fifth seem to be the only which should work, although a <h:form> is missing for all those buttons, but I'll bet that it's just the oversimplification of the code example.
Regardless, the usual practice is to store the user-specified locale in the session scope. When you want to change it by a JSF action method, then you need to send a redirect afterwards so that a new view will be created with the desired locale. Otherwise the initial locale will indeed be used in the response and thus you have to change it in the current view yourself by
FacesContext.getCurrentInstance().getViewRoot().setLocale(newLocale);
in the action method.
Related
I have a popup defined within my XHTML which gets shown conditionally depending on what selections the user makes in the main screen rendered by default:
<p:dialog id="commentDialogID" header="Enter comment" widgetVar="commentDialog" modal="true" resizable="true" height="auto">
<h:form id="commentForm">
<h:outputLabel for="comment" value="Comment:"/>
<p:inputTextarea id="comment" title="Comment"
rows="6" cols="33"
value="#{managedBean.activeItem.comment}"
required="true">
<f:ajax render="comment"/>
</p:inputTextarea>
<h:commandButton id="commentSubmit" value="Submit" action="#{managedBean.proceed}" onclick="PF('commentDialog').hide();">
<f:ajax render="commentSubmit"/>
</h:commandButton>
</h:form>
</p:dialog>
The problem is that, once this dialog/popup is closed, the container (JBoss) or the framework (JSF/Primefaces), not sure which, thinks that the whole view has been closed and therefore on the next request that triggers an appearance of this popup, it re-invokes the backing bean's #PostConstruct method. The backing bean is #ViewScoped. I really don't want it to do that, instead, I want it to treat the dialog/popup as a div in the page whose closure does not affect the view state.
The first time the dialog is brought up, the #PostConstruct is not invoked as the initial view from rendering the page, which called the #PostConstruct, is still active. However, on the second appearance, it is reinvoked, which leads me to believe it is because it was closed after the first time, which either the container of the framework or both mistake as needing to reload the bean.
What can I do to prevent the backing bean from going into the #PostConstruct after this dialog has been closed?
I know what the problem is..
You are using h:commandButton to submit the form and to close the dialog.
Lets look at your code:
<h:commandButton id="commentSubmit" value="Submit" action="#{managedBean.proceed}" onclick="PF('commentDialog').hide();">
<f:ajax render="commentSubmit"/>
</h:commandButton>
In the above code As soon as you clikc Submit button:
1. Your action will get triggred to call ManagedBean method managedBean.proceed.
2. since you have bound onclick JS event, your dialog gets closed.
After your action="#{managedBean.proceed} comes back it has to update the button with id commentSubmit since you have used render="commentSubmit".
But by the time your action="#{managedBean.proceed} comes back to render="commentSubmit" the disloag in which your button commentSubmit is placed is closed. so this might the reason for re initializing the ManagedBean.
To Avoid this you ca use Primefaces p:commandButton which has oncomplete attribute which is helpfull in this scenario.
<p:commandButton id="commentSubmit" value="Submit" action="#{managedBean.proceed}" update="commentSubmit" oncomplete="PF('commentDialog').hide();" />
So in the above case p:dialog will close after the action is completed.
Is it possible to reset the value of an inputText after clicking on the commandButton in JSF? The inputText UIElement provides the method ResetValue so I tried something like this:
<h:inputText id="measurementadd" binding="#{inputTextMeasurement}">
<f:validateRegex pattern="[a-zA-Z ]*"/>
<f:ajax event="keyup" render="measurementaddmessage submit" execute="#this"/>
<h:inputText>
<p:commandButton id="submit" action="#{Bean.addMeasurement(inputTextMeasurement.value)}"
value="submit" update="dataTable measurementadd measurementaddmessage"
disabled="#{empty inputTextMeasurement.value or facesContext.validationFailed }" >
<f:ajax event="mouseup" execute="#{inputTextMeasurement.resetValue()}" />
</p:commandButton>
<h:messages for="measurementadd" id="measurementaddmessage"/>
But after clicking the Button the inputTextMeasurement doesn't reset it's value.
Does someone know a good workaround for this?
I'm searching for a solution without JS and JAVA, so a realization in JSF would be very cool.
Your mistake is here in the execute attribute:
<f:ajax event="mouseup" execute="#{inputTextMeasurement.resetValue()}" />
The execute attribute should represent a space separated collection of client IDs to include in the process/decode of the ajax request. However, you specified a listener method there.
You need the listener attribute instead:
<f:ajax listener="#{inputTextMeasurement.resetValue()}" />
(and I omitted event as it defaults here to click which is already the right one)
Interesting detail is that the other <f:ajax> in the same piece of code used the exeucte attribute the right way.
Unrelated to the concrete problem, have you looked at <p:resetInput>? This saves an ajax listener method in the bean. Replace the whole <f:ajax> with
<p:resetInput target="measurementadd" />
Why dont we just use
<input type="Reset"/>
This one is works fine for me! ???
I have solved my problem as below
<p:commandButton id="submit" action="#{Bean.addMeasurement(inputTextMeasurement)}">
Sending back bean UIInput component. Get and Reset value in back bean.
public void addMeasurement(UIInput
String msr = (String) inputTextMeasurement.getValue()
inputTextMeasurement.resetValue();
}
I need to show the response page depending on some of the input fields. E.g. the tabid inputHidden below:
#{controllerBean.tabId}
...
<h:form id="edit">
<h:inputHidden value="#{controllerBean.tabId}" id="tabid" />
<h:inputText value="#{controllerBean.name}" id="name" />
</h:form>
But when some other input in the same form has validation error (e.g. the "name" inputText). The "controllerBean.tabId" value will not be assigned because JSF returns at validation stage.
I still need the tabId to show the page correctly and having 2 ideas in mind:
#{param['edit:tabid']}
or use binding:
#{tabId.value}
<h:inputHidden value="#{controllerBean.tabId}" id="tabid" binding="tabId" />
My question is, which of these 2 is the better or Best Practice? Or there are even better ways to do this?
update:
Note. In my specific case, the tabid is set by client javascript.
Server reply with a few items in the html.
Javascript put these items into different tabs on the page.
One of the tabs POST data to server with the current tabid in the form.
So my server need to know the tabid to show the response page with the correct tab selected.
You can add a lifecycle event listener to the component and pick the value from it. I'm going to recommend the preValidate listener:
<h:form id="edit">
<h:inputHidden value="#{controllerBean.tabId}" id="tabid">
<f:event type="preValidate" listener="#{controller.grabTabId}"/>
</h:inputHidden>
<h:inputText value="#{controllerBean.name}" id="name" />
</h:form>
This registers the listener to fire just before the validation phase of the request. You'll now have a listener defined in your backing bean to look like:
public void grabTabId(ComponentSystemEvent cse){
//obtain a reference to the component
HtmlInputHidden hiddenElement = (HtmlInputHidden)cse.getComponent();
//get the value from the component.
String hiddenValue = hiddenElement.getValue();
}
<h:form id="edit">
<h:inputHidden value="#{controllerBean.tabId}" id="tabid" />
<h:inputText value="#{controllerBean.name}" id="name" >
<p:ajax process="tabid" immediate="true" event="keyup" />
</h:inputText>
</h:form>
The above code will do is when the user put some value the value will be processed and will be set the managedBean. that what you want I think.
Another non-perfect way of accomplishing this is to move the validation logic to your action method. If validation fails, you just stop processing (and add an applicable FacesMessage). You just need to be aware that all model values will have been updated, and you can clear them if necessary.
Since updating model values on failed validation goes against the JSF lifecycle, I think any solution will be somewhat of a hack.
The title says almost all. Just an important precision: the menu is in a template and so is shared by several pages and I don't know the page from which the user will choose the menu item.
I tried with a h:commandLink but I have a problem with the redirection to the same page. Perhaps there is a another kind of solution?
Just make it an asynchronous submit instead of a synchronous submit. Nest in a <f:ajax>.
<h:commandLink ...>
<f:ajax />
</h:commandLink>
If you intend to execute or render some specific parts, specify them accordingly in the execute and/or render attribute of <f:ajax>. They both defaults to #this and #none respectively. E.g.
<h:commandLink ...>
<f:ajax execute="#form" render="#form" />
</h:commandLink>
This JSF1 code has me totally puzzled for hours. The basic setup is this page displayed with Seam2:
<h:form encType="multipart/form-data">
<rich:dataTable value="#{results}">
...
</rich:dataTable>
<h:selectOneMenu value="#{contact.type}">
<s:selectItems value="#{contactTypes}" var="t" label="#{t.label}" />
<s:convertEntity />
<a4j:support event="onchange" reRender="submitControls" />
</h:selectOneMenu>
<h:selectOneMenu value="#{template}">
<s:selectItems value="#{allTemplates}" var="t" label="#{t.label}" />
<s:convertEntity />
<a4j:support event="onchange" reRender="submitControls" />
</h:selectOneMenu>
<a4j:outputPanel id="submitControls" layout="block">
<a4j:outputPanel rendered="#{null != results and results.size gt 0 and ('ONE' == contact.type.label or template != null)}">
<h:commandButton value="submit" action="#{manager.generate}" />
</a4j:outputPanel>
<h:outputText value="Search first" rendered="#{results == null or results.size == 0}" />
<h:outputText value="Select template first" rendered="#{'ONE' == contact.type.label and template == null}" />
</a4j:outputPanel>
</h:form>
Obviously, the original page is a bit larger. What has me scratching my head is that if I don't change contact.type (leave it at a default selected by the backing bean) the form submits fine. If I switch the type to ONE this correctly renders the "Select template first" text instead of the submit control. Restoring the submit button by selecting another type re-produces the <input> BUT without the onclick handler that was there when the form was first rendered.
Now a click on the <h:commandButton> sends a request to the server but does NOT trigger the associated action. However, it now restores the onclick handler and a second click triggers a proper submit.
I'm at a loss why this is so. Any suggestions?
EDIT: moving the rendered attribute to the button results in the same behavior (even if it did work, the original panels contain more controls that share the same condition, so they do serve a purpose)
EDIT2: I've just tested that simply re-adding the "lost" onclick handler (via firebug) that gets rendered on the submit button makes the action work as intended. I'm beginning to suspect a bad interaction between richfaces and the trinidad libs also included in this project (but not used on this page).
It's a safeguard against tampered/hacked requests. Otherwise a hacker would be able to invoke actions s/he isn't allowed to invoke by just editing the sent HTTP request parameters accordingly that the non-rendered (e.g. due to missing "ADMIN" role) command button will be invoked.
You need to make sure that you prepare the same model (managed bean instance with all properties responsible holding the conditions behind rendered attribute) during the HTTP request of processing the form submit as it was during the HTTP request of displaying the form. In JSF2, this is easy achievable by placing the bean in the view scope instead of the request scope. The view scope lives as long as you're interacting with the same view. In JSF1, you'd need to grab a 3rd party framework tag like Tomahawk's <t:saveState> or RichFaces' <a4j:keepAlive> in order to simulate the JSF2 view scope.
<a4j:keepAlive beanName="results" />
The same story applies to disabled attribute by the way.
See also:
commandButton/commandLink/ajax action/listener method not invoked or input value not updated
JSF 1.2: How to keep request scoped managed bean alive across postbacks on same view?
I think that with the rendered attribute and anything inside you have to take care that the evaluation of it is the same on the initial request AND the submit. It may change just before the render phase but if its not the same during application invoke it will most likely ignore the action if in this phase the button would not be rendered.
As far as i remember this happend for me mostly when the rendered expression uses something like an entity attribute that will be changed during the apply request values phase already.