Custom Datasets

...set() but to no end.

Thanks.

You should be able to specify the data directly on the grid. Instead of setting the data to local!datasubSet.data.field, instead call the local!Dvalues. There are two caveats to this though:

1) local!Dvalues should have the same length as your datasubset, or this can cause some problems
2) Sorting will not work very well with this

If you want to have your data line up properly with a sort, then you would most likely have to create a view to query instead, or have some complex logic to sort your local!Dvalues in the appropriate order.

@karlg I believe you may do something as follows in order to accomplish the requirement:

1. Update the data. Either you can generate the cdt using a combination of apply and merge or update the existing data using updatecdt() function at http://bit.ly/28MEhax.

local!datasubSet: a!queryEntity(
entity: cons!entity,
query: a!query(
selection: a!querySelection(columns: {
a!queryColumn(field: "A"),
a!queryColumn(field: "B"),
a!queryColumn(field: "C"),
}),
logicalExpression: local!logicalExpression,
pagingInfo: local!pagingInfo
)
),
\t
local!updatedData: apply(
\t/*You can go ahead with the usage of existing CDT provided if you have a field in your CDT that matches the data type of D and is not being used in the current implementation. Or have a look at 'CDT Manipulation' plugin at http://bit.ly/28MEhax to see how to add a new field to CDT without actually creating a formatted CDT. Creation of formatted CDT or array of label-value pairs is also another option though and this way you can refrain from usage of plugin.*/
\ttype!myCdt(
\ tA:_,
\ tB:_,
\ tC:_,
\ tD:_
\t),
\tmerge(
\ tlocal!datasubSet.data.A,
\ tlocal!datasubSet.data.B,
\ tlocal!datasubSet.data.C,
\ tindex(local!D,local!pagingInfo.startIndex+enumerate(local!pagingInfo.batchSize),{})
\ t/*Assuming that local!D has got the exact values as many as totalCount in the local!datasubSet. Or you may need to handle this, for instance you may fill the array with default values in case if it's length doesn't match the totalCount of queried datasubset or a rule that will return a null value when a value doesn't exist while we are forming the CDT list.*/
\t)
),

2. Update the DataSubset.

local!updateDataSubset: a!dataSubset(
startIndex: local!pagingInfo.startIndex,
batchSize: local!pagingInfo.batchSize,
sort: local!pagingInfo.sortInfo,
totalCount: local!datasubSet.totalCount,
data: local!updatedData,
identifiers: index(local!datasubSet.data,"A",{})
)

As mentioned above you can do this directly on the grid but the value lengths must be the same and sorting wont work. A solution is to create a CDT only for display purposes which has the fields "A", "B", "C", and "D" then cast your local!datasubset and local!Dvalues to this new CDT. That way you can have variable length values and sorting.

As brettf mentionned in his #2 he's spot on my actual true problem. I finally made it work by creating a datasubset A with the query, then a local!Dvalues : (get values whatsoever) and finally doing a datasubset B with the data property as such :

data :
{
A : local!datasubSet.data.A,
B : local!datasubSet.data.B,
C : local!datasubSet.data.C,
D : local!DValues
}

And use the datasubset B for the grid not A. Quite messy to get my sort to work but a WHOLE lot less messy than to modify the data structure behind to add a D in the view and such!

Thanks for the tips.

Well in the end my bad still doesn't work with my idea, my data structure created is not correct. Perhaps a CDT afterall and populate it as mentionned. I'm appalled by this single sorting feature being so restrictive!

@karlg Have you had thought about using updatecdt() or an array of label-value pair which Appian shows in its recipes?

And may we know the issue you have been facing with sorting?

I have a column with an ID. The ID might be 1-2-3 but it gives no value or meaning to the end user so we use expression rule to translate in english it's label value such as "ABC" and in french it would be "DEF".

When I sort that column I wish to sort on the translated ID (what is actually shown) and NOT the ID itself (like mentionned in the field property of the gridTextColumn). Because it makes the sorting illogical then.

Now I'm not going to update my CDT to have a column for each language we support for this ID and for each "ID".

But in the end it seems I have no choice; I will have to create a second CDT that will not have the IDs but the "translated" IDs and use that variable to populate the grid. Exactly like you mentionned.