1

I have a field in my Xpage that I want to be readOnly and submitted to the database upon Save. This field gets a value from a Ajax call

Setting the property ReadOnly to true creates a <span> instead of a readonly field.

Setting the property "Show disabled control for readonly" creates a input text field with the property readonly=readonly.

<input type="text" class="xspInputFieldEditBox" readonly="readonly" name="view:_id1:_id2:_id3:_id28:callbackFieldControlSet:InstrumentShort" id="view:_id1:_id2:_id3:_id28:callbackFieldControlSet:InstrumentShort">

It will not be saved to the database.

According to my knowledge readonly fields are submitted but not disabled.

What I'm I doing wrong here?

/M

Mikael Andersson Wigander
  • 661
  • 8
  • 33

2 Answers2

5

You can add the readonly attribute with the attr-property:

<xp:inputText id="inputText2" value="#{document1.ReadOnly}">
   <xp:this.attrs>
      <xp:attr name="readonly" value="true" />
   </xp:this.attrs>
</xp:inputText>

Btw: The behaviour of the disabled and the readonly property is correct, because this is a definition on the server side. You want to edit the component with a value, that is why it must be allowed to accept values. Just disabling it on the client side has technically no effect.

Sven Hasselbach
  • 10,455
  • 1
  • 18
  • 26
  • What version is this? On 8.5.2, when I use this snippet, I get the following error: "Unknown property this.attrs. It is not defined on tag xp:inputText." – rfk Sep 06 '13 at 06:24
  • @rfk: The attrs attribute was introduced in 8.5.3. That's why it is not working with 8.5.2 or lower. – Sven Hasselbach Sep 06 '13 at 09:40
0

I think this is a bug. You are right, the read only field should get saved. In version 8.5.1 when the property of "Show disabled control for readonly" was not present I used to set the field as readonly through JavaScript. Here's the code snippet:

<xp:scriptBlock id="scriptBlock1">
    <xp:this.value><![CDATA[function makeFieldReadOnly() {
    document.getElementById("#{id:inputText2}").readOnly = true;
}
window.onload = makeFieldReadOnly;]]></xp:this.value>
</xp:scriptBlock>

In the above snippet the function makeFieldReadOnly marks the edit box inputText2 as readonly when page is loaded.

Naveen
  • 6,786
  • 10
  • 37
  • 85
  • The link only describes that a *readonly* component should be *submitted* in the form data. It describes the client side only. – Sven Hasselbach Feb 01 '13 at 10:59
  • @SvenHasselbach: Oh... Just saw the description on hover of Read-only checkbox in Domino Designer - "Prohibits changes by the user, and the value is **not** saved when submitted...". Any ideas why IBM decided to do that, as saving the value of read only field would be standard behavior? – Naveen Feb 01 '13 at 11:50
  • I agree with Sven. Readonly setting in server side should mean it. – Panu Haaramo Feb 01 '13 at 12:20
  • As far as I remember this is part of the JSF specs. A *readonly* component does not need to be validated or converted, you cannot inject values, the setter of managed beans are not called... I can not see any reason to **allow** an update for a readonly component. What is the use case? To display a value to the enduser that he should not change (but easily can)? – Sven Hasselbach Feb 01 '13 at 12:25
  • 1
    @SvenHasselbach: I used the script block to make the date fields readonly so that we would be able to force the user to make date selection only via picker. Also in extension library I use it to make the text fields associated with name picker & value picker as readonly so that user selects value (via picker) rather than entering them. Is there a better way to do this? – Naveen Feb 01 '13 at 12:46
  • The use case in my example is when adding values to a form via an Ajax request (type ahead). User types a value, say a license plate and gets back the model and the owner of the car. These values gets stored in their own readonly fields since they are not meant to be manually changed. I solved my case with CSJS but I find it strange to have the control rendered as a readonly field with the correct properties but then it won't save due to JSF… The reason for having these options is then not so obvious – Mikael Andersson Wigander Feb 01 '13 at 13:47
  • Why not just use computed fields and a partial refresh and write the values to the backend in your Save routine – RoyRumaner Feb 01 '13 at 14:57
  • @MikaelGrevsten: Is it strange that a read only component is read only? What you are describing is a perfect scenario for a read only example: it is not allowed to change the values in these fields. So why allow it? It would be a data integrity problem, if you set these values from client side w/o validation. And a security issue too. You don't have any control about data in the client... – Sven Hasselbach Feb 01 '13 at 18:57
  • @Naveen: This is an example I can unterstand. But dont forget the serverside validation! – Sven Hasselbach Feb 01 '13 at 18:58
  • @SvenHasselbach I can see the security risk but that risk is present on any field whether it is readonly or not. I just question the rendering of the control, it is an input field with readonly property set to "readonly" which is the correct implementation of such a field. If it is a security risk according to JSF specs why have it as a choice? – Mikael Andersson Wigander Feb 01 '13 at 21:06
  • 1
    @MikaelGrevsten: No. If I have some fields in an application, and the fields are not allowed to get changed (whyever), it is a security problem to trust the "readonly" property of a HTML input field. The server does not know who sends the request (a browser, a tool,...). Same problem with clientside validation. To your example: I dont know what you are doing with the Model and the Owner, but what if the Typeahead fails (connectivity Problem f.e.)? it could happen that you store a license plate with the wrong Car and Owner informations. You need to validate the informations on the serverside... – Sven Hasselbach Feb 02 '13 at 07:33