Filtering DocLister Results by a TV-Based Section Map

One recurring DocLister pattern is a catalog where each item stores its section relationship in a TV, for example a parent-id TV. The temptation is to solve this with one DocLister call nested inside another, but that quickly becomes hard to read and harder to maintain.

The original pattern

The source discussion used a nested DocLister call inside &filters to generate a list of IDs dynamically:

[[DocLister?
&id=`TableList`
&controller=`site_content`
&parents=`13`
&tvList=`img,material,parent-id`
&filters=`AND(tv:parent-id:in:[[DocLister?&parents=`[*id*]`&showParent=`1`&tpl=`@TPL:[+id+],`&tplLast=`@TPL:[+id+]`]])`
]]

Why this gets fragile

• nested snippet calls are harder to debug
• editorial changes can break assumptions silently
• performance becomes less predictable as the tree grows

A cleaner strategy

Generate the section ID list once in a helper snippet or controller method, then pass the prepared value into DocLister as a normal parameter. That keeps the listing logic readable and lets you reuse the same helper in multiple templates.

[[SectionMapIds? &root=`[*id*]` &toPlaceholder=`sectionIds`]]
[[DocLister?
&parents=`13`
&tvList=`img,material,parent-id`
&filters=`AND(tv:parent-id:in:[+sectionIds+])`
&tpl=`TableListTpl`
]]

Why this is better

• the tree traversal and the final listing are separated
• the placeholder is easy to inspect while debugging
• future refactors no longer require unreadable nested calls

DocLister can handle complex data relationships, but the most stable solutions usually come from preparing the relationship map first and listing second.