The problem with the recommended approach is that if you really do have many conditions, you are creating a separate model, and thus a separate database query, for each condition. That isn’t very efficient and slows down the page. I’d love to know of a solution where I could have five different tables all driven from the same model/query, each filtered on a different value. That way the models load in (theoretically) 1/5 the time.
Use case (we have many similar to this right now): A highly normalized SF object that requires data-entry. It has a picklist with five options, and will have a dozen records for each option, each record containing data in the same six fields. Users will get overwhelmed with a single table of dozens of records, so I want to create one for each option and visually separate them. Users also want to see subtotals for each option (in some cases).
Seems like I could potentially create a single master model, then an empty dummy model for each option, then populate the dummy models with records from the master via javascript, but that probably would take a similar amount (or more) of processing time, right?
Alternatively, I suppose, if there was a good way to group or break up a single table and provide a label for each option (on the side or above, say) while displaying subtotals for each option, that would work, too.
