wouldn’t it be better to have just one checkbox-TV, which fetches the accounts with
@CHUNK binding instead of creating one TV for each account?
I’m not sure if I get you correct with the @SELECT or @CHUNK binding - never used those before. I’m gonna check this out…
I would store the ids, not the name of the account into the TV, btw
I guess I described this bad, these TVs are only named like [[+Account_00100]], [[+Account_00450]], etc.
But maybe I have to think the whole thing over and maybe chose another approach.
In general I want to have different tables on the front-end. The “names” of the rows and columns shall be freely editable for the customer, but I guess they won’t get renamed that often than the default-table I am going to create. So far not a big problem.
But then each table-cell shall output a result of different calculations, based on the different accounts that are available in the custom-db-table(those are related to a customer-ID and by year, all those data get fetched via a mysql-query). But only some of these accounts shall be used for calculations, not all of them each time.
So my first thought was using the new Fred-extra:
creating different tables as Fred-elements by hand the customer can choose from, and also creating the different accounts off the custom-db-table as Fred-elements by a snippet. So far my snippet worked, I could create a Fred-Element for each account and I created a table by “hand”.
Then I thought the customer might be able to choose the table he wants to use, name all the columns and rows like he wants them to be named (just in case they need to be renamed from the default-values), and just drag’n’drop in each table-cell all the Fred-element accounts he needs to use there. Additionally maybe make an option which kind of math he wants to use (summarize, substract, divide, multiply).
In “Fred-edit-mode” i was able to use a table i created as a Fred-element in the Fred-dropzone, and also drag’n’drop some accounts off the Fred-elements into a table cell. But then I didn’t know how to calculate them. Sure, I could use [[+Account_00100:add=
But I don’t want the customer to have to type this by hand, and I guess this might be the worst way to do this. There might be up to 10 or 15 accounts, that should be getting calculated. So there must be a better way to do this.
Then my second approach was to go with the TVs. Create a resource for each table-cell, which has all the available accounts off the custom-db-table as TVs to make them chooseable. Then get all the TVs that have been chosen by the customer with a resource by a snippet and calculate them. Then doing the output by a [[getResource…]]-call, or by creating a placeholder like [[+result_table-cell_XY]].
Another “problem” I haven’t thougt much about yet is bthe ability to use a result of one of the calculations for another calculation in a different table-cell. By thinking of this now I think the placeholders [[+result_table-cell_XY]] I created beforehand by the snippet are usable when the snippet has been run once, but not in the same table/on the same page.
Pretty complex stuff I guess, maybe this is off my limits…