Including Additional Column Values in a Page DataSource Load on a Creatio Page

When a Freedom UI page loads it’s datasource for the list or edit page, it will only load the values bound to that page or list. This is something that is different for edit pages in Freedom UI. A classic edit page would load all data for the record, so it was all available. On a Freedom UI page, you only have access to the columns bound to the page. This is because those columns are the only ones included in the datasource load. For a list page in Freedom UI this is the case as well (this was also the case for classic sections and detail lists). For this article, we’ll be adding some custom values to be loaded with the datasource.

In this scenario, I’ll am adding some custom row actions to a section list menu.  I’ll want to pass some columns to my request handler that aren’t bound as columns in the list. So, I’ll need to add these columns to the datasource for the list. Then they’ll be available.

Note, the equivalent of this on a classic list would be to add them using something like this (there were a few other ways to add columns to the request for the list as well):

initQueryColumns: function(esq) {
    this.callParent(arguments);
    if (!esq.columns.contains("UsrSomeField")) {
        esq.addColumn("UsrSomeField");
    }
}

For a Freedom UI list, we’ll add the following to include a column named “UsrSomeField” to the datasource:

/**SCHEMA_VIEW_CONFIG_DIFF*/,
viewModelConfigDiff: /**SCHEMA_VIEW_MODEL_CONFIG_DIFF*/[
    {
        "operation": "merge",
        "path": [
            "attributes",
        ],
        "values": {
            "Items": {
                "viewModelConfig": {
                    "attributes": {
                        "PDS_UsrSomeField": {
                            "modelConfig": {
                                "path": "PDS.UsrSomeField"
                            }
                        }
                    }
                }
            }
        }
    }
]/**SCHEMA_VIEW_MODEL_CONFIG_DIFF*/,

In the above, we’re merging the column so it will be requested with the other data. A couple of points to make about this. First of all, the attribute name, in this case “PDS_UsrSomeField” can be whatever you want, however, it’s a good idea to name it so it’s prefixed with the name of the datasource it’s from (a page can have multiple data sources). This brings us to the second point, the name of the datasource. The column name must prefix the column name so it knows where this is coming from. For section list pages, the datasource is often “PDS”, but not always. The datasource is defined in the modelConfigDiff. It will look something like the following (below, the datasource is named “PDS”):

modelConfigDiff: /**SCHEMA_MODEL_CONFIG_DIFF*/[
	{
		"operation": "merge",
		"path": [],
		"values": {
			"dataSources": {
				"PDS": {
					"type": "crt.EntityDataSource",
					"hiddenInPageDesigner": true,
					"config": {
						"entitySchemaName": "Account",
						"attributes": {
							"Name": {
								"path": "Name"
							},
							// etc
						}
					},
					"scope": "viewElement"
				}
			}
		}
	}
]/**SCHEMA_MODEL_CONFIG_DIFF*/,
Want content like this delivered to your inbox? Sign up for our newsletter!
ABOUT THE AUTHOR

Ryan Farley

Ryan Farley is the Director of Development for Customer FX and creator of slxdeveloper.com. He's been blogging regularly about SalesLogix, now Infor CRM, since 2001 and believes in sharing with the community. His new passion for CRM is Creatio, formerly bpm'online. He loves C#, Javascript, web development, open source, and Linux. He also loves his hobby as an amateur filmmaker.

2 Comments

  1. Something to note for users (and to check if you know which version(s) this works for, Ryan) is that in some previous versions of Creatio (we were on 8.1.0) this doesn’t work, at least for Lists. This is because when figuring out which data to load, the page would “trim down” any columns that were in the viewModelConfig not being shown in the list, so that if the user removed the column from the list in their setup, it didn’t load that additional data. Hopefully this is now resolved though, as we had Creatio support take a look and they couldn’t advise a workaround for it at the time.

    Reply
    • This is true. Also, an issue is that if you had the column in the list layout originally, in the default layout for the list, and the user has changed their layout and removed the column, the page will merge in a remove into the page attributes for the column, removing it from the request. I’ve yet not tested to see if I name my column attribute differently if it still gets added to the request. This might have possibly changed in recent versions, not sure.

Submit a Comment

Your email address will not be published. Required fields are marked *