defaultvalue in inputText overwritten when disabled? - xpages

I don't know if this is a feature or a bug: In an inputText control, bound to an item of a notes document, the value is overwritten each time the xpage is reopened and saved by the defaultvalue when the inputText control is flagged as disabled:
<xp:inputText
value="#{fback.EmployeeIDCreator}" id="EmployeeIDCreator1"
defaultValue="#{javascript:sessionScope.meUser.EmployeeID}"
style="width:94px" disabled="true" />
I expected the same behaviour as in "normal" (=enabled) items:
defaultValue assigned when document/xpage is new and the item is created,
field value when xpage is reopened and reedited.
Is this the "wished" behaviour?
thx in advance, Uwe

We'd run into this problem with fields that were marked 'readonly' as well. Set the style on the inputText to "display:none;" and have a separate control that displays the value. That way, your default value is saved in the field, but the user cannot edit it.

Looks to be a bug. Reproducible on R9.0.1: disabled state of edit field resets its binded value to default value on save.

We have a ticket open with HCL for this in 11.0.1 - CS0306235
The initial HCL response was "working as expected"
Subsequently someone in HCL raised this "Aha!" ticket because they disagreed - go vote for the "idea" - https://domino-ideas.hcltechsw.com/ideas/DDXP-I-980
In our case the workaround is to include .isNewNote() in an if statement as a condition of the default value.
<xp:this.defaultValue><![CDATA[#{javascript:if (document1.isNewNote()){
var addQText = getDbSettingsValueBlk('Configurable Additional Questions Text') ;
if (addQText==''){
// do nothing
}else {
return addQText;
}
}}]]></xp:this.defaultValue>

Related

lit-element v2 clearing text fields with null properties

I have lit-element based forms that are reused for editing entities.
As an example consider a name form with the following fields
<mwc-textfield id="first-name" label="First name" value="${this.firstName ?? ''}"></mwc-textfield>
<mwc-textfield id="middle-name" label="Middle name" value="${this.middleName ?? ''}"></mwc-textfield>
<mwc-textfield id="last-name" label="Last name" value="${this.lastName ?? ''}"></mwc-textfield>
The user selects an entity from some list and I fill the properties firstName, middleName, lastName
with the corresponding values. The user then may edit the values and press a save button which reads
the values of the text fields with something like
this.firstName = this.shadowRoot.getElementById("first-name").value;
and writes them back to the database. This all works well except for one case:
when the user edited the fields but then decides to not save the changes and instead
load another entity, the data binding seems to be somehow broken for empty properties.
So, f.e. assume the user selected 'Fred Krueger' (firstName=Fred, middleName=null, lastName=Krueger),
then typed a middle name 'Jacob' into the field but then decides to not save it and load
'Sarah Mueller' instead. Since her middle name is null, the text field should be cleared.
What happens instead is that 'Jacob' remains in the field!
It seems as if a null value will not clear a text field that was edited by the user and not synchronized
to the bound property. Note that properties that are not null do always update the fields!
The problem can be resolved by adding a change and keyup handler to each and every textfield in my form
to synchronize the corresponding properties.
Question:
Is this really the only way to do it?
Why does a property with value null not update the field when it has been edited before?
(Edit: changing the binding from value to .value does not fix this!)
This is due to the value property on the DOM being changed by the user input and Lit can't tell the DOM element needs to change. As you've noticed, using an event listener to keep the DOM value and Lit property always in sync is one way to avoid this, and this is often preferable since the Lit components will always have the latest value without needing to look it up from the DOM node.
Alternatively, using the live directive can force Lit to check against the current live value on the DOM node and properly update it.
import {live} from 'lit/directives/live.js';
<mwc-textfield id="first-name" label="First name" value="${live(this.firstName ?? '')}"></mwc-textfield>
<mwc-textfield id="middle-name" label="Middle name" value="${live(this.middleName ?? '')}"></mwc-textfield>
<mwc-textfield id="last-name" label="Last name" value="${live(this.lastName ?? '')}"></mwc-textfield>

Is there a way to have a new PXDBDecimal field show null

I have added PXDBDecimal user fields to an existing screen in the form section. When creating a new record, these immediately show as '0.00' - I'd like to know if there's a way for it to just show empty / null. I have no PXDefault attribute, so it's not set to default to 0.00.
See the answer here: (Presumably this is the same case with PXDBInt and PXDBDecimal)
Default [PXDBInt] data field to Null value?

Refresh edit box after information change

I have edit box which has validation- it is required field and it has range of values validation as well. The validation works ok, but the problem is that error message does not dissapear when I replace the values in edit box with valid ones. I tried to add full update on onchange event but this is not a option for me since this changes other fields in my xpage as well. The partial update on the field does not work. Any advice how to refresh the field so that error message dissapears?
Create a wrapper panel or div around BOTH the field and the error message control and set it's ID to the one that should be partially refreshed. I assume you use
XSP.partialRefreshGet("#{id:idOfYourField}")
in the onblur client event!? So just change the ID name here.

Null value submitted for a conditionally disabled field in a reusable JSF popup

I have a popup dialog developed in IceFaces 1.8.x (JSF 1.2).
The dialog is reusable (used for account creation as well as modification) and has a cancel button with immediate = true (to avoid validations). This dialog suffered a problem in the past ,where old values were rendered on re-opening the dialog, but that problem is now fixed as directed here (by setting submittedValue to null etc.).
The problem that I am facing now is specific to a conditionally disabled input field (<ice:inputText>) and here is what happens:
The popup is first opened (say for account creation) and this field
is NOT disabled.
User then cancels this dialog and, as we have incorporated the fix mentioned above (setSubmittedValue(null)), the submittedValue for this field is set to null (along with other fields).
Now the user opens "modify account" dialog, where in this field IS disabled. Everything seems to be rendered fine until user makes any changes to the form.
When user changes some field (say name) in the form, a partial submit happens for the name field as expected, but along with it null value is submitted for this disabled field.
This problem can be worked around by adding a null check in the setter method for the field in question, but this is not the desired solution for the project - as there are multiple places where this could be needed and doesn't seem like a very intuitive thing to do.
So I need to understand:
Why is the setter for this disabled field getting called in the
first place? and that too with a null value. The setter is not
called for any other enabled fields.
More importantly, is there any way to fix this (other than adding null check in the setter)?
You must be using rendered attribute to show/hide the dialog
<ice:panelPopup modal="true" rendered="#{bean.enabled}">
When dialog is reopened, it is coming up with some residual values from previous instance
The solution (or workaround) is to use <c:if> instead of rendered attribute, this way the DOM is completely destroyed when dialog closes and created from scratch when dialog opens
<c:if test="#{bean.enabled}">
<ice:panelPopup modal="true">
...
</ice:panelPopup>
</c:if>
This way you even would not need the fix to set submittedValue to null

xpages passing the UNID to other field

I have an input field:
<xp:inputText value="#{Cdoc.txt_UNID}" id="txt_UNID1"></xp:inputText>
The field txt_UNID is computed having the value: #Text(#DocumentUniqueID).
What I noticed is that even I just compose the xpage containing the document content the inputText already contains some UNID even if the xpage containing the doc content wasn't saved.
There is a button which is showing a dialog containing a field. I want this field to have the value of txt_UNID
Cdoc.save(); // I must save first the Cdoc datasource ?
getComponent('exampleDialog').show()
And the code for the field:
<xp:inputText value="#{Pdoc.txt_CompanieUNID}"
id="txt_CompanieUNID1" defaultValue="#{Cdoc.txt_UNID}">
</xp:inputText>
Thanks for your time.
If your question is whether or not you must first save the document in order to get the UNID, my answer is yes. In my tests, the UNID has changed from a new document to a freshly saved document. So, yes if the current document is new, save before getting the UNID. At least when it was a NotesXspDocument.
I also generally use JavaScript for this,
cdoc.getDocument().getUniversalId();
Otherwise, I am unsure what you are asking.
If PDoc is available at the same level of the hierarchy as CDoc, e.g. both are datasources assigned to the XPage / Custom Control or the same Panel, you could update PDoc on save, using PDoc.replaceItemValue("txt_CompanieUNID",Cdoc.getDocument().getUniversalID()). setValue should also work. Then you would not need the default value.
It just helps keep all business logic in one place. You could also check whether a value has already been set.

Resources