Hi there,
I've got a business needs where I have 2 records types (let's call them RT1 and RT2). RT1 has a one-to-many relationship with RT2 and I need to display a grid where my row would be RT1, in which the first 5 columns would be property of RT1 while the following columns would be dynamically added based on possible values of RT2, this mean the number of columns would be equal to the number of properties of RT1 + the number of possible values for RT2.
This could give something like :
What would be the best architecture to build that?
Discussion posts and replies are publicly visible
All UI components in Appian can be made dynamic. So, well, if that UI has to look like this, then a normal grid should do it.
Hi Stefan,great, my main concern is more about how should I load the child in each row? Usually we feed a query result, but in this case I'm not sure which data structure I should use? Custom Data Fied, RecordType, dictionnary, etc.I've got about 800 items, which can have up to 80 features (some item can have 1-2 features, while other have 50-60). Right now we are building a dictionary dynamically but the load time is long (like 30s with RecordType, while it take's SQL less than 1 to generate the same data).
To put you in better context, we are aware that the grid will overflow the screen and this is not a concern for us. Also, I understand some Item will only have values in column 1, 2,3,4,5,52,67, while other may have value in each columns.
Do you plan for paging? A grid with 800 rows will also slow down the client.
What does business want to achieve with this highly problematic UX?
Hi Stefan,thanks for your input, actually the grid will have paging + lot of filtering possibilities.
The grid is a tool that is used by our staff to see our multiples locations and which services are available in each location. They must have a quick picture or everything available everywhere.
IMHO this seems not like a great user experience. I hear this "Everything, everywhere all at once" from most of my clients. But this is only because they are used to work with Excel, but not because this would be the best way of doing it.
But, yeah ... your "requirement" can easily be implemented, just keep an eye on the performance. And queyr only the data required for a single page.
Unknown said:I hear this "Everything, everywhere all at once" from most of my clients.
But what if they were just making movie recommendations?