Building AJAX Catalog Filters with tagManager and getPage

A practical implementation of this pattern showed a full product-listing setup built around tagManager, custom TV data, and AJAX pagination. Even today the pattern is useful: keep the catalog markup predictable, isolate filter rendering, and let the listing reload inside a dedicated container instead of rebuilding the whole page.

Product item template

<li class="item">
    <a href="[[+tv.ssilka-offer]]" class="product-image">
        <img src="[[+tv.kartinka]]" alt="" width="145" height="145">
    </a>
    <div class="brend"><a href="[[+tv.ssilka-offer]]">[[+tv.brend]]</a></div>
    <div class="product-name"><a href="[[+tv.ssilka-offer]]">[[+tv.nazvanie]]</a></div>
    <div class="price-box">
        <span class="price">[[+tv.cena-skidka]]</span>
        <span class="price-skidka">[[+tv.cena-old]]</span>
    </div>
</li>

AJAX listing container

<a name="products" id="pageAnchor"></a>
<div id="products">
[[!tmGetProducts]]
</div>

<ul class="pages" id="pages">
[[!+page.nav]]
</ul>

Filter block bootstrap

<script src="/assets/components/tag_manager/js/web/view_switch.js"></script>
<script src="/assets/components/tag_manager/js/web/jquery.history.js"></script>
<script src="/assets/components/tag_manager/js/web/filters.js"></script>

<div id="filters">
[[!tmCatalogFilters?
  &jsMap=`1`
  &innerTpl=`filters_innerTpl`
  &outerTpl=`filters_outerTpl`
  &priceName=`cena-skidka`
]]
</div>

Why this structure works

• filters are rendered separately from product cards
• pagination has a stable target container
• price ranges and checkbox filters can share one filter UI
• the page can preserve state without a full reload

On modern Evolution CMS projects the exact JavaScript stack may differ, but the architecture still holds up well: isolate listing state, isolate filter markup, and keep the server-side output deterministic enough that pagination and filtering can safely reuse the same rendering rules.