DockLister?
просто цену лучше не хранить в МультиТВ, ту по которой сортировать планируется и фильтровать если это какие-то там опции неважные - ладно ещё, да и то я не юзаю для этого МультиТВ (мало ли взбредет кому-то потом по ним сортировать)
МультиТв, это просто способ хранения множественных данных, привязанных к ресурсу, вида ключ-значение, и в базу оно залетает в виде json, поэтому по этому полю и не очень удобно что-то фильтровать. Чтобы "раскрыть" его в отдельные строчки/столбцы, как раз приходится через прослойку такое делать, если это требуется. Требуется оно не всегда :)
Просто цена зависит от опций, тут лили куча однотипных товаров создавать, или параметры типа MiltiTV
Гы. Как раз в одном проекте сейчас именно на мультиТв переделываю. Так как изначально там вообще на dd_multiplefields или как там его было сделано, ну где не по ключам значение, а просто через раздеители вида || и :: размечается и там эти смещения вечно считать надо. А товаров несколько штук, и комплектации/цены/свойства именно таким образом вбиты. Вот как раз пересохраняю их сейчас в мультиТв, чтоб редактироваь было удобно, и сразу с выводом в такую промежуточную табличку, чтоб там это вильтровать можно было удобно.
я бы лучше однотипные создавал, с параметром "объем упаковки", в общем случае
Кстати с какой-то версии мускуль умеет форма хранения json и как-то там нативно ищет. И записывать можно передавая не json, а данные (как-то). Но это все волшебство я не пробовал ещё.
У меня не задалось с этим волшебством, там начинались какие-то ограничения, то а в такой-то таблице не можем, а в таких-то операторах не можем, а в такой-то версии не можем и т.д. Плюнул и разложил во временные таблицы. Да там же еще и не совсем одноуровневый джонсон, а некое фиелдвалюе, что тоже чуть добавляет возни. Поэтому решил мультитв чисто как удобный визуальный элемент использовать, а данные в таблицу гнать и оттуда всё дергать.
Обсуждают сегодня