I am using the jsf along with primefaces. I want to call reset functionality when my form loads. But so far i am unable to achieve it.
<script type="text/javascript">
function reset(){
alert("dsdsd");
document.getElementById('A1938:create-ticket').reset();
}
window.onload=function(){reset();};
</script>
<h:form id="create-ticket">
<p:dialog id="dialog" header="Select different user" widgetVar="dlg" modal="true">
<ui:include src="searchpopup.xhtml" />
</p:dialog>
which definately not gona work as jsf translates the page in different way. Any idea.
The alert is getting called.So again i want the form to reset itself when it gets loaded similar to form.reset()
thanks,
Cyd
Calling reset when the page loads makes no utter sense. Perhaps you misunderstood the meaning of reset(). The form.reset() does not clear the input fields, instead it resets the input values to their initial values. I.e. when you get a form with prefilled inputs and then change them, then the reset() would reinitialize them with initial values as it was when the page was loaded. So, the form would only be cleared out on reset() when the initial values are already empty by itself.
So, to achieve your concrete functional requirement, you need to clear out the bean properties directly instead of fiddling with form.reset() which doesn't do what you think it does. Or, better, put the bean in the request or view scope and make sure that the form is opened by a fresh new GET request.
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 currently try to implement a website, where an dialog, opened from an carousel, changes something in the database and the result is shown on the screen. For that, I try to update an area in the dialog. Unfortunately, updating things in an carusell does not seem to work.
I shortened the code to an minimal example, so with the following code:
<p:carousel id="page" value="#{pagebean.pages}"
var="item" numVisible="1">
<h:form id="dlg_2_form">
<h:outputText id="test_2" value="#{pagebean.value}" />
<p:remoteCommand name="update_2" update="test_2" />
Increment
</h:form>
</p:carousel>
the function pagebean.value is not called after I click on Increment, but therefore the constructor of pagebean is called when I click on Increment. So it seems like the carousel makes it impossible to update something in it.
Does anyone know, if there is an possibility to update something which is in a carousel, or if there is a workaround for this problem?
EDIT: After the discussion below, I know that Increment does work, if the scope of the corresponding bean is set to #ViewScoped. I could also trigger this button by giving it a widgetVar and accessing its click function, so this would work. Unfortunately, the Bean I want to use is SessionScoped, and with this kind of view it does not work. Has anybody an hint how to solve this problem? I could copy everything into a second Bean, which is ViewScoped, but this is not a very nice solution.
I'm working on building a web page and notice now that I have to press the command button twice. Any command button has the same problem, so I figured I would add and action listener on one of them to see if I could see something.
<h:form id="formP">
<p:commandButton id="temp" value="photos" actionListener="#{viewBacking.debugBreakpoint()}" action="userPhoto" />
</h:form>
The backing bean has
public void debugBreakpoint() {
int i = 0;
i++;
}
Unfortunately, this does help. It hits my breakpoint only after the second press. I suspect that some field somewhere isn't passing validation but I would like some method of detecting what exactly is going wrong - why do I need the second push? Is there some option I can turn on in Glassfish, or something else where I can look at a dump of debug information? I can ignore the dump until everything is stable and then see what exactly is happening when I press the button for the first time.
Is there any such tool which I can use?
That can happen when a parent component of the given <h:form> has been rendered/updated by another command button/link with <f:ajax>. The given form will then lose its view state which it would only get back after submitting the form for the first time. Any subsequent submits will then work the usual way. This is caused by a bug in JSF JS API as descibred in JSF issue 790 which is fixed in the upcoming JSF 2.2.
You need to fix the another command button/link with <f:ajax> to explicitly include the client ID of the given <h:form> in the render.
<f:ajax render=":somePanel :formP" />
Another way is to replace this <f:ajax> by a PrimeFaces <p:commandLink> or <p:commandButton> so that you don't need to explicitly include the client ID of all the forms. PrimeFaces's own JS API has namely already incorporated this fix.
add event="onclick" in your p:commandbutton
I guess that will sort it out.
or you can add this ajax="false" property in your commandButton
<p:commandButton ajax="false" action="#{userController.create}" value="#{bundle.CreateUserSaveLink}"></p:commandButton>
I ran into the same issue. The solution was simple, instead of having both an actionListener and an action, just convert the actionListener method to return a string to where you want to navigate to and use it as the method for the action (and don't have an actionListener).
In simple terms: only use an action (do not use an actionListener on a commandButton that is submitting a form).
Please check your binding with bean.
bean fields should be String or non primitive.
I am trying to popup a window when someone clicks a button on the data table.
<h:commandButton
action="#{cacheController.popupDetails}"
immediate="false"
onclick="popup()"
value="View Details"
styleClass="submit">
</h:commandButton>
The associated popup function is
function popup() {
window.open('RDDetails.jsf','popupWindow', 'dependent=yes, menubar=no, toolbar=no, height=500, width=400');
}
Now in the new 'RDDetails.jsf" file, I am trying to access the same managedBean cacheController. But the problem is, the pop-up window and JSF lifecycle is not in sync. As a result, the popup first displays blank and when I refresh, it pulls out the proper data.
Is there anyway I can click on a button which will do some processing in the managed bean and then opens a pop up which rerieves the processed data from the managed bean.
I am using JSF 1.1.
You're here basically firing two independent requests: one associated with the form submit and other which opens the RDDetails.jsf in a popup. You'll need to combine this in one request. You can achieve this in basically two ways:
Get rid of the onclick and just add target="_blank" to the <h:form> so that it get submitted into a new window/tab.
Block the default action by adding return false; to the onclick and do the business logic in the constructor of the bean associated with RDDetails.jsf. The only (major) caveat is here that the model won't be updated with the form fields. Thus, you'll need to pass the form fields as request parameters of the popup URL manually with help of JavaScript. You can then make use of managed property entries in the faces-config.xml to inject the GET request parameters into the model.
First way is obviously the easiest, but this doesn't give you a "fullworthy" popup/modal dialog. The second way is a bit harder (unless you've already a good grasp on both JavaScript and JSF). I would then consider to look for a component library which provides a ready-to-use popup component.
See my example:
<h:commandLink action="#{controller.myAction}" onmousedown="document.forms['idform'].target='_blank';">
I'm using jsf 1.1
Hopefully the title isn't too cryptic ...
The problem we have is that we generate a bunch of input controls (h:inputOneMenu, h:inputText etc) from some Java List.
Works fine EXCEPT the requirement is that these inputs validate on the fly. Again not so hard except that as there controls were generated in a loop the only possible reRender action is basically the entire form or an a4j:outputPanel around each loop iteration which is basically the same thing.
Now the above two solutions technically work but they have the nasty side effect of reRendering all the page controls which makes the page feel really twitchy and clunky. We'd like to stop this from happening so ideally the only control that gets reRendered is the control that send the ajax update/validation.
Basically this is our page code:
<ui:repeat value="#{seam-outjected-list}" var="item">
<a4j:outputPanel selfRendered="true">
<h:inputText value=#{item.value}>
<a4j:support event="onblur" ajaxSingle="true" />
</h:inputText>
</a4j:outputPanel>
</ui:repeat>
I've left out a bit of stuff that just renders different controls depending on the item.
As you can see we're currently using the a4j:outputPanel solution so every time any loop generated control is updated all the controls are reRendered.
Thanks in advance if anyone has any thoughts.
My first thought is that you should try replacing your <ui:repeat> with an <a4j:repeat> and take advantage of the ajaxKeys attribute to only reRender certain rows.
From the Richfaces Docs:
The main difference of this component
from iterative components of other
libraries is a special "ajaxKeys"
attribute. This attribute defines row
keys that are updated after an Ajax
request. As a result it becomes easier
to update several child components
separately without updating the whole
page.