Как в MODX установить свой цвет к каждому блоку с превью?

Доброе утро. mfilter2 и pdoTools, нужно чтобы в выдаче у каждого блока превьюшки (карточки товара), был свой определённый цвет. Если правильно понял, привязки, id наверно?

Выбор цвета от чего будет зависеть? Случайный?

Нет, необходимо, определённый цвет для каждого анонса, то есть ресурса, не случайный, как то привязать к id ресурса, логика примерно такая же что и у тв, я знаю только один простой вариант, можно просто создать тв, например cvet и указывать там название класса с нужным цветом в каждом ресурсе, далее в tpl компонента выводить так:

<div class="[[+cvet]]"> 
 Блок анонсов
</div>

.black{
 background: #000;  
}
.Blue{
 background: #007aff;  
}

но возможно, есть более правильное решение для этого, какие вообще есть варианты для реализации такой «схемы»? Если ресурсов тысячи слишком много кода, как можно это реализовать без лишней нагрузки?

Если как-то можно было бы зацепиться, то поле не нужно, в том числе и TV. А если нужно, чтобы менеджер это вручную выбирал, то это нужно куда-то сохранять. Это либо TV, либо создавать свою таблицу, ну или использовать существующую, в которое это поле можно добавить.

То-есть единственный вариант, задать свои стили, каждому блоку анонсов это через tv, разница только в том в какую таблицу сохранять значение? Можно пример по поводу зацепится, в моём понимании это уникальный индификатор у ресурса значение тв, id, parents?

Ресурсу же как-то нужно назначить цвет. Каждый ресурс имеет уникальный id. Как в коде определить что, например, ресурсу с id = 5, нужно, например, назначить красный цвет, а ресурсу с id = 7 — синий, а с id = 8 — зелёный? В этом случае нужна таблица, в которой должно быть задано соответствие id цвету. Самое просто решение это использовать TV, более сложное – это создать своё дополнение для этого.
Если же цвет назначается в зависимости от какой-то логики, то в этом случае можно будет попробовать обойтись без TV. Здесь всё зависит от задачи.
Если нужно например, чётные id выводить одним цветом, а нечётные другим — то в этом случае конечно TV не нужно. Также, например, не нужно будет использовать TV, если цвет ресурса зависит от секции, в которой этот ресурс расположен. Если конечно секций не очень много. В этом случае можно прописать для ресурсов, расположенных в одних секциях, выводить превью одним цветом, а для ресурсов в других секциях — другим цветом.

Александр спасибо, скажите а возможно к примеру определять цвет img и в зависимости от этого применять нужный или это сложно и не выгодно в плане производительности и с помощью тв будет проще и менее затратнее?

Если использовать тв, образно говоря имеем 1000 ресурсов, у каждого ресурса свой цвет как отразиться на производительности сайта, примерно?

Если использовать сложное решение, создать своё дополнение, по отношению к первому способу какие преимущества в плане производительности или только тестить и на вскидку не прикинуть?

Насколько понимаю, нужно определить яркость картинки. Если картинка яркая, то один цвет, если нет, то другой. Если что-то такое или подобное, то это можно осуществить при сохранении ресурса в TV или другое поле. А потом уже его использовать при выводе ресурса.
Для производительности лучше конечно не в TV, а использовать extendresource, тем более что он уже есть. Туда добавить ещё одно поле.

Спасибо, всё максимально понятно.

Александр, забыл изначально, очень важный вопрос, более правильный вариант это один компонент extendresource и там все тв или как-то до определенного количества и потом лучше сделать подобный в плане производительности, как лучше?

Немного дополню вопрос. Понимаю что вторая таблица это ищё запрос, но если в таблице очень много полей к примеру более 500 и значений 3000 не целесообразно ли разделить их, создав вторую таблицу и возможно ли использовать две таблицы в одном компоненте?

По поводу количества полей, просто пример:)

3000 значений будет тогда, когда только 3000 ресурсов будет. Т.к. в этой таблице 1 ресурс соответствует 1 записи в таблице. Это правильно.
Если, например использовали бы, TV, и их было бы штук 7, то записей в таблице было бы гораздо больше 7 * 3000 = 21000.
Про количество полей, это наверно шутка. Ну, даже если их будет, 50, всё будет работать хорошо. Для получения всех этих полей, связанных с конкретным ресурсом, потребуется всего один запрос, а не 50, если бы, например, использовали TV.
Но, по-хорошему нужно всё измерять. Если какое-то место не нравится, и есть видение как это улучшить, то всегда стоит пробывать. Потом сравнить с тем что было и принять решение какой код оставить.

Если то, что вы реализовали можно как-то оформить в виде компонента, а потом использовать на другом сайте, то туда лучше ничего лишнего не добавлять.
А для решения другой задачи можно сделать новый компонент и соответственно создать для него уже другое количество нужных таблиц.
Далее, например, при создании нового сайта, вы очень просто уже сможете добавить функционал посредством установки нужных компонентов.
Если это не нужно и если имеющаяся таблица позволяет вам осуществить то, что задумали, то тогда новые таблицы в большинстве случаев создавать не нужно.

Спасибо

Предельно понятно, спасибо.