pxListSubscript not working in Read-only Data Reference (25.1.1)

User Experience
,
1

Hi Team,

I’m using Pega Platform 25.1.1.

I have a property called SelectedDiscountOptions, configured as a Data Reference (List of Records). It is sourced from a Data Page and used in a partial view to display the selected records in read-only mode. The UI control is configured as a multi-select field.

Configuration:

  • Mode: Read-only

  • Display as: Simple table

  • Columns:

    • pxListSubscript (for Option No)

    • Reference name

However, the Option No column is not displaying any values when I use pxListSubscript.

Since this is rendered as a read-only Data Reference (not a Repeating Dynamic Layout bound to a Page List), pxListSubscript seems not to be resolving in this context.

My Questions:

  1. Is pxListSubscript supported in a read-only Data Reference rendered as a Simple Table?

  2. If not, is there any supported workaround to display row numbers in this configuration?

  3. Would the only option be to switch to a Repeating Dynamic Layout backed by a Page List to achieve this?

Appreciate your guidance.

Thanks.

2

Hi @MaleeshaW

I have replicated the above configuration mentioned by you and indeed pxListSubscript does not seem to work in pagelist on the UI.

Tried the below approaches in v25.1.1 and v25.1.2

  1. Used the @baseclass.pxListSubscript and declare expression for the same property directly - Din’t work
  2. Save as both the pxListSubscript property and declare expression into data class - Din’t work
  3. Created a property RecordNumber of Integer type and a declare expression for it that uses the same function @pxGetListSubscript(tools) which was used in OOTB - Worked:grinning_face:
  4. Created a property RowNumber of Text type and a declare expression for it and using the same function @pxGetListSubscript(tools) which was used in OOTB - Worked:grinning_face:

Also when i displayed the data reference in Table, Simple Table, Cards layout i see the same above mentioned behaviour.

So it seems to me that the pxListSubscript property has an issue when we use it for list to display the item number. You may want to raise an INC to pega to hear their thoughts on this one.

Finally, to answer your questions

  1. Is pxListSubscript supported in a read-only Data Reference rendered as a Simple Table ? Seems like its not supported as of now

  2. If not, is there any supported workaround to display row numbers in this configuration ? You can create your own property for the data class and use the same OOTB function in declare expression to get the row number

  3. Would the only option be to switch to a Repeating Dynamic Layout backed by a Page List to achieve this ? If you have your own property to get the row number, then you can continue with your table layout without any issue. No need to switch the layouts.

A snapshot from my POC. Hope this helps

image
image2332×416 86.2 KB

Other community members can also share their thoughts, feelings and ideas on this one.

Regards

JC

3 Likes
3

Hi,

Thank you for the detailed suggestions.

I implemented the 3rd option by creating an Integer property in the reference data class and adding a Declare Expression using:

@pxGetListSubscript(tools)

This successfully populated the serial number in the read-only Data Reference (Simple Table) configuration.

Appreciate the guidance — this approach worked perfectly.

Thanks again!

1 Like
4

Hi,

I have a follow-up question regarding this approach.

If the same Integer property (.RowNumber) in the reference data class is used by two different Data References in:

  • Case Type A

  • Case Type B

And two different users create cases from Case Type A and Case Type B at the same time:

Since .RowNumber is populated using a Declare Expression with @pxGetListSubscript(tools), will this cause any impact on the displayed row numbers?

In other words:

  • Is the computed list subscript isolated per case instance?

  • Or could concurrent case creation across different case types affect the row numbering?

Just want to confirm whether this implementation is fully safe in concurrent scenarios.

Thanks!

5

RowNumber would be isolated and unique per case instance. So you are good to go ahead with your implementation without any issue

Regards

JC

6

Interesting case and also good to know the solution for this. What i dont understand is what is the business value for the user: why does the user need to see the option number the record had had during selection?