As the previous idea was closed and there is no way to add comments to closed ideas, I'm creating a new one. Working with the new charts library/widget I've found a new scenario where I would like to have something like XPath snippets or another way to separate the configuration and execution of a retrieve.
To create a few charts I'm retrieving a lot of data from the database, which goes perfectly fine as I'm only counting the results to show pie chart pieces. However the customer also whishes to be able to click on a chart to filter a datagrid on the same page. This makes sense as you'd want to see the data the statistics are based on to be able to act on it.
Now I could associate each pie-chart-piece with it's list of objects, however then I'm sending way more info to the client than required, 90% of the time I'm only interested in the count. Next possibility would be to create a sub-microflow for the data retrieval, use that once during creating of the charts, and once again when the on-click happens. Less data will be send to the client, but still the server will retrieve and evaluate all lists, again causing a perfomance hit.
As the count-optimization only works when retrieve and count are in the same microflow, the only option to make this perform well would be to duplicate every single retrieve action. And as we're talking KPI charts here, that's quite some duplication of (sometimes complex) XPath retrieves, making the application harder to maintain. Here a solution would be the previously suggested XPath snippets. Or if it's easier to realize: the possibility somehow to create a reusable retrieve configuration. So instead of an XPath snippet you make the entire "Retrieve"-action something that can be saved in the project explorer and then re-used in different microflows.
Yes this would be great. It could also really help with consistency. E.g. I've often seen the same (sometimes rather complex) xpath being used in multiple widgets in the UI and in multiple places in a microflow. Using a submicroflows is often not an option as most widgets will lose much of their out of the box functionality this way.
It can also happen that you have a rather complex base xpath that is re-used quite often in subtely differnt ways. E.g. for a different status. It would be great to do something like (where %MyBaseXpathQuery% refers to a XpathSnippet):
[%MyBaseXpathQuery%]
[Status = 'Created’]
Great idea! I would also like for this to happen.
You may want to look into executing an OQL aggregation query using the `Core.retrieveOQLDataTable()` API using a Java action. [1][2]
I'm afraid this functionality is not documented too extensively but you might be able to use this to write your own count query without relying on XPath optimization.