Again, regarding editing a row.
We assume here that the developer has intimate knowledge of the application. We aren't doing an deep introspection of the system here. That could be another level of abstraction.
You could write the code to do the edit based on the visible columns outside the listbuilder.
I tried to make these dynamic features add-ons to listbuilder but the way it works, I could not easily do it.
I still think it might be best if I refactored listbuilder and allowed adding columns/filters after the call to template::list::create.
This would keep the internals of listbuilder a little simpler (a good thing! have you looked inside there?) and make it more clear in the code exactly what was happening.
The reason I tried to integrate was that the filter_where_clauses etc... are generated from "prepare_elements" and "prepare_filters" clauses.
But it should be straightforward to append to those properties after template::list::create is called.
So I could create a template::list::prepare_filters_again (name for illustration purposes only ...) that takes a list of filter names and prepares just those filters. Ditto for prepare_elements.
In fact I added the filter_form feature and I think it makes sesne to add that explicitly too outside the call to template::list::create.
I'll post more, but I think this way will make the code much cleaner for anyone who does not need this features.
It also makes it possible to add them incrementally without modifying the core code until we have a good understanding of it.
