How to make popUp not submit form on startup? - jsf

I am using JDeveloper 11.1.2.3.0,
I have a createInsert button that has ShowPopUp Behavior operation included. In the popUp I have inserted a form whose attributes will be clean from the createInsert operation. When I click the button the popUp shows up all right but showing an error about the mandatory fields of the form. The fields of the form of course are empty because I just opened it. So I think that the popUp is autoSubmiting the form at the starting point.
Does anyone have an idea how to stop it from doing this?
I have changed the createInsert button PartialSubmit property to false but nothing changed.

Ok found the solution. The popUp was not submitting anything actually but during the CreateInsert operation the iterator opens a new row in every related component within that page (form, table etc). So when my popUp opened up with the new form fields, a new row was being created in the back-stage in my read-only table. I changed the iterator in a new one from another Application Module for each case and everything is fine now.

Related

How to change xpage form for new document?

Right now I am working on a Xpage which displays data from a domino document. Based on the form of the document different fields will be displayed.
Now I want to create a "New" function. My idea here is to set the view I am previously using in edit mode.
Additionally, I want to add a radio button which enables a user to choose the form of the document he wants to create.
Based on this radio button the document form should change which should result in the elements displayed on the page changing too.
Overall if I switch between the radio button options and hit save, a new document will be created with the right form.
Yet my problem is that my elements in my view won't change dynamically. So if I switch my form there will still be elements/controls displayed for the default option but not the selected form.
My idea was to create an onChange-event for my Radio Button Group.
My questions here would be: How can I change my formValue for the Xpage (new document) and then reload it with the new set value?
Thanks for your explanation.
I understand you have one XPage suitable for multiple forms, I assume using a Switch control and custom controls per form. About the New button, you could try first to have 3 New buttons, each for a separate form, and you create a URL like yoursite.com/xpage.xsp?action=newdocument&form=someform
When the user clicks the button, your page can read the parameters (param.action and param.form) and act accordingly. Or do you intend to update the current page using partial refresh, as a single page approach?

Have to push button twice to get partial refresh to work

Background: Xpage with multiple data sources. Each row of tabbed table contains an edit panel bound to a different data source than the main page. Each page contains a table to enter new documents. These documents are children of the main document. There is a view control that shows the user created documents immediately. The button in the table saves the document in addition to adding some control fields. It does a partial refresh of the editPanel.
Recently I added validation to the fields in the entry table. I use a function, and prevent updating from anything but the button. I am using Tommy Valand's method from this blog post: http://dontpanic82.blogspot.com/2010/03/xpages-making-validation-behave.html. If I don't use Tommy's method, then the validators fire when switching tabs, and are useless.
All of this works sort of, but I am experiencing the following issues.
1) I have to push the button twice to get the partial refresh to fire. Not only that, but the validation messages to not fire until the button is pushed twice. The first part was still an issue prior to adding the validation.
2) The table values do not clear after the refresh does happen. This used to work prior to adding the validation. The only way to get the values to clear now, is to do a full refresh (F5).
I really just need partial refresh to behave like it should. Any help is greatly appreciated.
I am answering my own question because I think that I might have found out why the partial refresh was acting so flaky. Here is what I did that solved my issues: Each tab had an editPanel. If I make the edit panel do a partial refresh to itself then the buttons on that panel seems to behave as you would expect them to.
When I create a new core control panel, the default in No submission. I do not know whether this issue manifests itself only when using multiple data sources and/or tabbed tables. Hopefully this fix will be of use to someone down the road. It is worth a try if you are having issues with partial refresh working correctly.

JSF: Create a "dummy" button which does nothing?

In our JSF web application, we have an input field where the user can enter a numeric ID, which is then looked up by the app. To help the user, the lookup is bound to "onchange", thus it will be triggered as soon as the user tabs out of the field or clicks elsewhere.
So, user enters "123", presses tab (or clicks), lookup runs. This works fine; however, for usability reasons, we also want to provide a button that users can click on, for users who will otherwise wonder "where should I click to trigger a lookup?". To do this, we'd like to provide something that looks and feels like a HTML / JSF button, but does nothing (as the click will trigger the "onchange" event anyway).
Is there a way to make a JSF button that does nothing? I tried using h:commandButton without the "action" attribute, but it still fires a request.
p:commandButton type="button" will just provide a push button.
Since you tagged this question also as a usability issue, I would advise against a button in the first place if the onchange already triggers the lookup.
From a user's perspective it is confusing whether or not clicking the button is mandatory. After they have entered the field and skipped to the next, they see the lookup occur without clicking the button. If there is a button they will assume it's there for a reason.
The option that I favour in these cases is a onkeypress handler with a timeout of half a second, after which the value is looked up.

XPages remove documents on server and trigger partial refresh

I am struggling with the following.
On my XPage I have a viewpanel component, but it is not bound to a notesview datasource, but to a hashmap stored in viewScope. Reasons for this is beyond scope of my question.
Since the lines in my view are not actually linked to the documents I cannot use the standard checkboxes and the related getSelectedDocIds. I do however want a way to remove the selected documents. I have a column with checkboxes containing the unid of the corresponding row.
So long story short. I have an array of unids and want to perform an action that does the following:
Display a dijit.Dialog asking for confirmation
If OK clicked call a function that does the following:
Remove the documents based on the unids
Refresh the viewpanel
I am thinking of the following 2 solutions, but in doubt what would be best (maybe a third, even simpler solution?)
Have the OK button of the dojo dialog call a function that does an XmlHttpRequest to an XAgent or plain old LS agent
Have the OK button trigger an eventhandler that runs on the server as described by JeremyHodge here. But how would I pass the unids as parameter and refresh the view afterwards?
Thanks!
Cant you just make use of the extension library dialog with the dialog button control. In this button control you can then
A third option would be to add a column to your datatable/view which contains checkboxes. On the onchange event of these boxes you add an eventhander which adds the value to a viewScope variable.
A button on the bottom (or top.) of the page you add the code you need to remove the selected items from the hashmap, delete the documents associate with the selected id's. this button can be a ordinary button with a partial refresh on the viewpanel. When you run into the bug that you cant use buttons in a dialog please use the extension library dialog control because this fixes that issue for you.
If the current user does not have the correct access level to delete documents you could use the sessionAsSigner global (assuming the signer of the design element has the correct access levels).
This way you dont need to go call an xAgent by xmlthttprequest and can stay with the default xpage methodology.
I hope this helps in some way
I would second #jjbsomhorst in the use of the extension library for the dialog box - if you use one at all. Usually users don't read dialog boxes. So the approach would be add the column with the checkboxes, but don't bother with an event handler, but bind them ALL with their value to ONE scopeVariable. On submission that variable will then hold an array with the selected UNID.
Then render a page that lists these documents and have a confirm button. While the new page affords a server round-trip the likelihood, that users actually pay attention is way higher. What you can do:
Have the normal page that renders the dialog with editable checkboxes and when the user clicks "Delete" you set something like viewScope.confirmDeleteMode=true; and use that as condition for the checkboxes and make them read-only AND set the class of the selected rows to "morituri" which in your CSS would have something like .morituri { color: white; background-color : red; font-weight: bold } and a new button "Confirm Delete" (and hide the Delete button).
This way you only have one page to deal with.
I went for option 2, which has the possibility to provide the partial refresh id. I passed the unids as a submitvalue like:
function doRemove(unids){
XSP.executeOnServer(ISP.UI.removeEventID, ISP.UI.removeRefreshID, {
params: {
'$$xspsubmitvalue': unids
},
onComplete : function() {
//alert('test')
}
});
}
The ISP.UI.removeEventID performs the following code:
var unids = context.getSubmittedValue();
removeDocuments(unids); //SSJS function performing the actual delete
viewScope.reload = 'reload' //triggers the hashmap to be rebuild based on new documentcollection

Best practice in dealing with xpages extensions dialog box?

I have an extension pages dialog box that I placed in a custom control. The dialog box is used to search for cost centers and return information such as market, cost center number, cost center name etc.
A "Select" button is pressed and the dialog box appears. The user searches for and selects their cost center. The OK button is pressed and it closes the dialog box and updates the various fields on the xPage.
A couple of questions.
Currently the "Select" button on the CC needs to know and refer to the name of the dialog box control within the CC. Seems to me that this is not the best practice. My end user programmer needs to know the ID of that dialog box control within the CC. Is there any way for my "Select" button could "show" the CC and the CC would actually show the dialog box control?
My CC makes use of custom properties to store the various document fields from the selected cost center. The OK button then uses these properties to set the various fields on the xPage. This again does not seem to be a best practice. If I wanted to use that CC in another application then I might need to edit the code in the OK button. Is there a better way to deal with this? Like I can set properties for a CC when I drop it on my xPage, is there a way I can tell it the code that I want to execute when the OK button is pressed?
One thing I thought was to have properties for the fields that need to be updated by the OK button but that does not seem to be so flexible.
For the issue of needing to know the id not sure if theres a typo but I don't understand why its bad that a select button inside a cc needs to no the id of the dialog to open it? did you mean the select is outside the cc? either way have you tried anything like creating a property on the custom control so that from outside it you can set something maybe
<xc:mycustomControl showDialog="false">
and then when something outside it happens change showDialog and refresh the cc, then inside the cc you can have a before / after page load to determine what happens when showDialog is true / false.
For your second issue it sounds to me like this should be using a domino document structure. Rather than the dialog pulling out each piece and the ok button updating, what I would do is have a domino doc data source on the page. when something is selected through the dialog I would update the document this source is pointing to and have all the fields bound to what ever fields they need to be. This way after something is selected the fields will just update to what ever the document contains, and it will be much more re useable so long as the domino docs have the same field names

Resources