I'm using a <h:selectOneMenu> with an valueChangeListener attribute attached to it. The listener invokes some business code (eg. DB query) to load additional data based on the new selected value. I noticed that when an (unexpected) exception happens in that code, a AbortProcessingException wraps the original exception, which is followed by a log but without notifying the user that something went wrong.
Is there a way to notify the user that something unexpected went fatally wrong when invoking a listener ?
I know from Differences between action and actionListener that an action would be more appropriate for such an expression, however I cannot set an action in <h:selectOneMenu>, but only a listener. How shall I change my page so that a "real business action" (one that is allowed to fail) gets invoked when the selected item changes ?
JSF has a concept of FacesMessages. These are rendered with the help of the <h:messages /> tag. What is often done, is to catch any Exceptions and add a javax.faces.application.FacesMessage to the FacesContext, giving the user informations he needs (see also "catch exception in managed bean and show message on screen in jsf2").
FacesContext.getCurrentInstance().addMessage(
null,
new FacesMessage(Severity.INFO, <see details for possible fills>)
);
There are also the way to introduce an own ExceptionHandlerFactory - like mentioned in the article "Global handling of all unchecked / unexpected exceptions in JSF 2"- have you checked this possibility? (see also this answer/comment to BalcusCs article )
As possibility two, you can e.g. use an ajax-request after the selectOneMenu got changed and trigger another Listener with that (it is executed later then the ValueChangedListener and gives the AjaxBehaviorEvent as parameter, what I find to be more helpful on BL - side). Here is some meta-code ...
<h:selectOneMenu ...>
<f:selectItems ... />
<f:ajax render="..." execute="..." listener="..." />
</h:selectOneMenu>
Hope it helps...
Related
Is it possible to have a commandButton that executes a method of a certain backing bean and then also navigates to a different page?
I know that I could return a String in the method that the commandButton calls, but the method is also used on the target-page, meaning it's often called from that same page.
So for calls that come from the same page, the redirect would be unnecessary and I would like to avoid that.
The options that I have in mind right now:
Create a separate method for the "remote" call of the method that does the same logic and also redirects to the page
Use an additional h:button and use JavaScript so that if the commandButton is pressed, the h:button is pressed at the same time (Probably bad practice tho)
Any option I am missing? Is there any way to tell the commandButton itself that it's supposed to navigate somewhere or do I have to implement this in the backing-beans?
Your title and first sentence are 'dangerous' and sort of not on topic since to both, the answer is yes and you sort of describe (= answer) that in your second paragraph already yourself.
The real question further on effectively asks about conditional navigation. But let me state first that your solution of two methods is also not wrong if you just make sure you don't do actual work in the bean (which you should not).
Now conditional navigation is by itself not difficult
returning null (to stay on the same page) without a refresh, "" to stay on the same page with a refesh,
return the new page (with redirect).
All basic JSF which I assume you are already aware of and this just requires something to do one or the other
So then the question remains if you can
detect the page you are on when the method is executed or
pass on a parameter to the action
which in turn can be used to return null or the other new page in an if/else.
Page1:
<h:commandButton action="#{mybean.action(true))" />
Page2:
<h:commandButton action="#{mybean.action(false))" />
Bean:
public String action(boolean navigate) {
doWork();
if (navigate) {
return "page2.xhtml?faces-redirect=true";
} else {
return null;
}
And if you'd want it, you could even pass null or the page name as a parameter to the method call.
Implementing detection of the source page of the action has the advantage that in the UI you do not need any knowledge on how to navigate, you always call the same method without any parameters and each new page you'd use this action on navigates to the right page without the developer needing any knowledge.
So take you pick.
I'm not completely sure if I got you right, but you could do something like this:
<h:commandButton value="Click" action="otherPage.xhtml?faces-redirect=true">
<f:actionListener binding="#{bean.method}" />
</h:commandButton>
Keep in mind that actionListener will be fired first and after that action from commandButton. Hope it helps.
Update:
Due to the fact that there was no further thinking you can use commandButton with or without redirect.
<h:commandButton value="Click" action="{bean.method}"/>
I have a datatable in which the first column contains some links to display the details for each item. I am using f:ajax to send the request to the action listener.
While it does work for the first time (when I click the first link or any link) but after that it stops working and no request is sent to the actionlistener.
<h:commandLink value="#{inquiry.myObject.property}"
actionListener="#{myBean.getDetail}">
<f:param name="someName" value="#{someBean.someName}"/>
<f:ajax
render=":#{p:component('infoDisplay')}
:#{p:component('addFieldSet')} :#{p:component('myDetailsId')}" />
</h:commandLink>
How do I make sure that the request is generated for every link and not just for the first attempt ?
UPDATE---
here is the action listener
public void getDetail(ActionEvent event) {
String xyz=context.getRequestParameterMap().get("someName").toString();
//some task
}
I have set a breakpoint on the first line of this function. This function gets called only once (for the first time).
After the first successful ajax call, I can see the below error in developer tools.
customer?p_p_id=account_WAR_XXX&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-1&p_p_col_count=6&p_p_col_pos=1&_account_WAR_XXX_javax.faces.resource=primefaces.js&_account_WAR_XXX_ln=primefaces&v=4.0:5 Uncaught TypeError: Cannot read property 'source' of undefined
replaced <f:ajax render> with <p:ajax update>. I no longer see the javascript bug on the developer tools and all the functionality seems to work as expected.
I am trying to execute a JSF2 bean method and show a dialog box after completion of the method on click of PrimeFaces <p:commandButton>.
<p:commandButton id="viewButton" value="View"
actionlistener="#{userBean.setResultsForSelectedRow}" ajax="false"
update=":selectedRowValues"
oncomplete="PF('selectedRowValuesDlg').show()">
</p:commandButton>
<p:dialog id="selectedRowValues" widgetVar="selectedRowValuesDlg" dynamic="true">
<h:outputText value="#{userBean.selectedGroupName}" />
</p:dialog>
When I click on the command button, the bean action listener method setResultsForSelectedRow executes properly, but it does not show the dialog box when the method completes. If I remove actionlistener, it shows the dialog box. I do not know what is going wrong.
What is the execution order of events? Is it possible to execute actionlistener and oncomplete simultaneously?
It failed because you used ajax="false". This fires a full synchronous request which in turn causes a full page reload, causing the oncomplete to be never fired (note that all other ajax-related attributes like process, onstart, onsuccess, onerror and update are also never fired).
That it worked when you removed actionListener is also impossible. It should have failed the same way. Perhaps you also removed ajax="false" along it without actually understanding what you were doing. Removing ajax="false" should indeed achieve the desired requirement.
Also is it possible to execute actionlistener and oncomplete simultaneously?
No. The script can only be fired before or after the action listener. You can use onclick to fire the script at the moment of the click. You can use onstart to fire the script at the moment the ajax request is about to be sent. But they will never exactly simultaneously be fired. The sequence is as follows:
User clicks button in client
onclick JavaScript code is executed
JavaScript prepares ajax request based on process and current HTML DOM tree
onstart JavaScript code is executed
JavaScript sends ajax request from client to server
JSF retrieves ajax request
JSF processes the request lifecycle on JSF component tree based on process
actionListener JSF backing bean method is executed
action JSF backing bean method is executed
JSF prepares ajax response based on update and current JSF component tree
JSF sends ajax response from server to client
JavaScript retrieves ajax response
if HTTP response status is 200, onsuccess JavaScript code is executed
else if HTTP response status is 500, onerror JavaScript code is executed
JavaScript performs update based on ajax response and current HTML DOM tree
oncomplete JavaScript code is executed
Note that the update is performed after actionListener, so if you were using onclick or onstart to show the dialog, then it may still show old content instead of updated content, which is poor for user experience. You'd then better use oncomplete instead to show the dialog. Also note that you'd better use action instead of actionListener when you intend to execute a business action.
See also:
Understanding PrimeFaces process/update and JSF f:ajax execute/render attributes
Differences between action and actionListener
I just love getting information like BalusC gives here - and he is kind enough to help SO many people with such GOOD information that I regard his words as gospel, but I was not able to use that order of events to solve this same kind of timing issue in my project. Since BalusC put a great general reference here that I even bookmarked, I thought I would donate my solution for some advanced timing issues in the same place since it does solve the original poster's timing issues as well. I hope this code helps someone:
<p:pickList id="formPickList"
value="#{mediaDetail.availableMedia}"
converter="MediaPicklistConverter"
widgetVar="formsPicklistWidget"
var="mediaFiles"
itemLabel="#{mediaFiles.mediaTitle}"
itemValue="#{mediaFiles}" >
<f:facet name="sourceCaption">Available Media</f:facet>
<f:facet name="targetCaption">Chosen Media</f:facet>
</p:pickList>
<p:commandButton id="viewStream_btn"
value="Stream chosen media"
icon="fa fa-download"
ajax="true"
action="#{mediaDetail.prepareStreams}"
update=":streamDialogPanel"
oncomplete="PF('streamingDialog').show()"
styleClass="ui-priority-primary"
style="margin-top:5px" >
<p:ajax process="formPickList" />
</p:commandButton>
The dialog is at the top of the XHTML outside this form and it has a form of its own embedded in the dialog along with a datatable which holds additional commands for streaming the media that all needed to be primed and ready to go when the dialog is presented. You can use this same technique to do things like download customized documents that need to be prepared before they are streamed to the user's computer via fileDownload buttons in the dialog box as well.
As I said, this is a more complicated example, but it hits all the high points of your problem and mine. When the command button is clicked, the result is to first insure the backing bean is updated with the results of the pickList, then tell the backing bean to prepare streams for the user based on their selections in the pick list, then update the controls in the dynamic dialog with an update, then show the dialog box ready for the user to start streaming their content.
The trick to it was to use BalusC's order of events for the main commandButton and then to add the <p:ajax process="formPickList" /> bit to ensure it was executed first - because nothing happens correctly unless the pickList updated the backing bean first (something that was not happening for me before I added it). So, yea, that commandButton rocks because you can affect previous, pending and current components as well as the backing beans - but the timing to interrelate all of them is not easy to get a handle on sometimes.
Happy coding!
Just when I thought I had understood immediate... *sigh*
Consider the following JSF page:
<h:inputText value="#{testBean.text}" required="true" />
<h:commandButton actionListener="#{testBean.doFoo}" value="Do Foo" />
<h:commandButton immediate="true" actionListener="#{testBean.doBar}" value="Do Bar" /><br />
<h:outputText value="#{testBean.didSomething}" />
And this backing bean:
public class TestBean {
private String didSomething = "Nothing done yet";
// + getter
public void doFoo() {
didSomething = "Did foo!";
}
public void doBar() {
didSomething = "Did bar!";
}
From all I read about immediate I would expect the following:
When trying to do foo while not providing a value for the input field, the action is never executed because during processValidationsPhase an error occurs, resulting in the page to be re-rendered directly after this phase with an error message. The value of the didSomething remains unchanged. (This works as expected)
When trying to do bar while not providing a value for the input field, the action is executed during applyRequestValuesPhase because of the immediate attribute. The variable didSomething is changed. (This works as expected)
On what happens next, this description states:
"A null return value (as outcome of the action method) causes processing to continue as normal, ie non-immediate components are validated then update-model is executed (if no validation errors occurred). For an action listener method that returns void, it is necessary to call facesContext.renderResponse(); if the normal flow is not desired."
From this I had the idea that processing continues as normal (as my action method does neither return an outcome nor force renderResponse()), resulting in the same validation error. Only difference would be that it occurs after setting didSomething. However, this does not happen. Instead, it feels like the site still skips all remaining phases, with the input field not being touched. It re-renders without error message.
Can someone explain to me where my understanding of how this works is amiss?
With immediate="true" on the button, the action is indeed invoked during apply request values phase and all the remaining phases are skipped. That's also the sole point of this attribute: process (decode, validate, update and invoke) the component immediately during apply request values phase.
All inputs which do not have immediate="true" are ignored anyway. Only inputs which do have immediate="true" are also processed, but this happens also during apply request values phase. Why should the remaining phases be invoked if everything has already taken place in the apply request values phase?
In the Debug JSF lifecycle article you can find the following summary which should enlighten when to (not) use the immediate"true":
Okay, when should I use the immediate attribute?
If it isn't entirely clear yet, here's a summary, complete with real world use examples when they may be beneficial:
If set in UIInput(s) only, the process validations phase will be taken place in apply request values phase instead. Use this to prioritize validation for the UIInput component(s) in question. When validation/conversion fails for any of them, the non-immediate components won't be validated/converted.
If set in UICommand only, the apply request values phase until with update model values phases will be skipped for any of the UIInput component(s). Use this to skip the entire processing of the form. E.g. "Cancel" or "Back" button.
If set in both UIInput and UICommand components, the apply request values phase until with update model values phases will be skipped for any of the UIInput component(s) which does not have this attribute set. Use this to skip the processing of the entire form expect for certain fields (with immediate). E.g. "Password forgotten" button in a login form with a required but non-immediate password field.
See also:
Why was "immediate" attribute added to the EditableValueHolders?
I have the following situation:
after clicking a button, some business logic is done and after it is done, a new tab with a report should be visible.
<p:commandButton value="this button" update="growlMain"
actionListener="#{myBean.businesslogic}"
onstart="ajaxDialog.show();"
oncomplete="ajaxDialog.hide();"
onsuccess="window.open('./report.jsp', '_newtab');" />
This does not work :(
If the business logic only lasts some milliseconds, the following works:
<p:commandButton value="this button" update="growlMain"
actionListener="#{myBean.fastbusinesslogic}"
onclick="window.open('./report.jsp', '_newtab');" />
the onclick opens a new tab, also things like onstart but it doesn't work with onsuccess or oncomplete. Why? And is there a solution for business logic that lasts some seconds?
onclick is called before the ajax request is even created (pure client side) while oncomplete and onsuccess are executed after the server responded to the ajax request. So, if you need to execute some business logic before showing a dialog, for example, you want to go with oncomplete. That's what I always use.
You can also condition your javascript inside oncomplete to perform only if there's no validation errors. Intuitively I think onsuccess would behave like that and only execute when there's no validation errors, but that's not how it goes. I don't really know the difference between them. I assume there's a way to flag success=false in the backing beans, but I couldn't really find it in the documentation.
If you want to check for validation in your oncomplete attribute, this is how you'd do:
oncomplete="if (!args.validationFailed){someDialog.hide()}"
In this case, you would only close the dialog if the fields are properly validated. You can actually inject parameters from the backing bean and use them in the javascript after the request has been served. In your backing bean you can do something like this:
RequestContext.getCurrentInstance().addCallbackParam("showDialog", false);
And you can access the parameter like this in your incomplete attribute:
oncomplete="if (args && args.showDialog){someDialog.show()}else{ alert('the bean didnt let me open the dialog')}"
Anyway, I hope that helps.
I have noticed that onsuccess for PrimeFaces command button does not work. The oncomplete however works and does the needful even if there is an error , such as in my case shows a success dialog even if there is an error in my business logic. Tried to use onsuccess but doesn't work.
You could try oncomplete as below:
<p:commandButton value="this button" update="growlMain"
actionListener="#{myBean.businesslogic}"
onstart="ajaxDialog.show();"
oncomplete="ajaxDialog.hide(); window.open('./report.jsp', '_newtab');"/>
You can see the difference here:
Primefaces and ajax onsuccess event
or with onsuccess you can do something before full loading DOM