Blog Sections Open
Handling Very Large TV Option Lists in Evolution CMS
Once a TV needs to carry hundreds or thousands of options, the problem is no longer just field configuration. It is data modeling.
In some projects a TV effectively needs to work with around 1,500 values. That is the moment when the usual dropdown or checkbox pattern stops being pleasant for editors and starts raising structural questions.
The real options
The post compared a few directions:
- store everything directly in a TV value list
- maintain a separate resource-based or pagetitle-based source
- move the dataset into a dedicated structure and resolve values programmatically
What this tells us
A TV is a useful field mechanism, but it is not automatically the right storage model for a large external directory, geographic dataset, or classification list. At that scale, maintainability matters more than whether the field can technically be made to work.
Recommendation
If the source list is large and likely to change, separate the dataset from the editing field. Let the field reference a structured source instead of trying to hard-code the whole world into one manager control.
Fixing Pagination with getResourcesTag and tagLister
How to troubleshoot pagination when combining tagLister, getResourcesTag, and pageNav so that page 2 and later pages keep working correctly.
Loading Evolution CMS Content with AJAX Without Breaking Chunks and TVs
A safer way to think about AJAX content loading in Evolution CMS when direct document content output skips chunks, TVs, and parser behavior.