SmartCJ Support Forum

зачем вводить еще одну переменную?

суть в том, что при импорте по ратио нам не нужно знать точные размеры, а только требуемые нам пропорции - отношение ширины к высоте определяемое дизайном. напрмер, предполагается использовать плеер 16:9, под это ратио я делаю верстку, растягиваю как нужно контейнеры и совершенно не замарачиваюсь выяснением реальных размеров видео/тумбы видео, т.к. у каждого спона для плеера 16:9 будут совершенно разные размеры в пикселях, и вот оно мне совершенно не надо, я просто делаю стили под ратио 16:9 и всё.
так же как и под 4:3 (старые типы мувисов), 3:4 (вертикальные тумбы моделей) и т.д. т.е. по всей базе у меня юзается только 3 (в данном примере) критерия 16:9, 4:3, 3:4, которые я могу: конвертнуть в custom var, создать по ним таги, выводить это всё как доп. иконки на тумбе (типа как для 4K etc). так же вводятся доп. классы под тумбы с этими модификаторами и прочее...

естественно - это просто предложение как задавать размеры "унифицированно" (одинаковым образом для всей базы в виде ратио типа 16:9 вместо указания конкретных размеров в пикселях каждый раз) и что б не скачивать видос только для определения его размеров

т.е. если у нас Parse Video Files - no, и указаны размеры старым способом или через это предлагаемое поле ratio, то смарт при импорте не качает видео, а так же:

- если указаны размеры, то он автоматом приводит эти размеры к виду ратио X:Y
- если рато указано, юзает его
- bind-ит полученное ратио в meta-инфу данной гали, и после делает его доступным из шаблона макросами описанными выше (<!--ITEM_RATIO_X--> ...)
- так же возможно создаёт custom_var_ratio_X_Y
- возможно навешивает таги, типа X:Y (ну т.е. 16:9)

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

само-собой, если юзер выбрал делать rolling thumbs и т.д. для хотлинкованного мувика, то видос качается вне зависимости от всего этого )

кстати, ещё вопрос: в базе индексы для всех созданных юзером custom var полей создаются? просто нормальная таксономия только на них и делается, а без индексов, ясен, их для этого юзать не вариант...

естественно - это просто предложение как задавать размеры "унифицированно" (одинаковым образом для всей базы в виде ратио типа 16:9 вместо указания конкретных размеров в пикселях каждый раз) и что б не скачивать видос только для определения его размеров

если при импорте указан размер - видео не качается, те если вы там укажете 3х4 в поле размера - у вас будут нужные данные и видео качаться не будет, чем плохо?

harizmadark wrote: Fri Jan 15, 2021 10:41 pm кстати, ещё вопрос: в базе индексы для всех созданных юзером custom var полей создаются? просто нормальная таксономия только на них и делается, а без индексов, ясен, их для этого юзать не вариант...

проверил - да, инедкс создается под кастом поля

и видео качаться не будет, чем плохо?

ну не то что бы плохо, а скорее не унифицированно... пожалуйста перечитайте ещё раз мой предыдущий ответ внимательно. уверен, разницу и практическую выгоду в задании именно ратио вы увидите.

в любом случае - это просто предложение, если всё-же считаете более юзабельным задание явных размеров в пикселях контейнера для адаптивной верстки (которые к тому же будут постоянно разные от спона к спону хотя будут обозначать всё те же 16:9 но разными значениями), то проехали. буду выкручиваться теми тэгами, которые имеются.

проверил - да, инедкс создается под кастом поля

очень гуд, принял к сведению

прочел 2 раза

у меня вопрос - чем плохо юзать под ваш вариант то что уже есть?

если вы там укажете 3х4 в поле размера - у вас будут нужные данные и видео качаться не будет, чем плохо?

ну это:
- выдуманные данные (здесь мы эмулируем задание ратио/отношения через пикселы, когда можно юзать именно предназначающееся для этого поле)
- это хак (мы указываем 3x4 для поля логически ожидающего значения в пикселях, но это не пиксели, а уже ратио получается)
- если захотим сгенерить тэги/custom var с размеров для иконок разрешения (как писал выше) хз как мы сможем определить что реальные пиксели, а что фэйк добавленный только для того, что б сэмулировать задание жтого самого ратио (можно ясен, типа всё что не больше 10, то это ратио - но опять же, это хак, имхо), когда всё-же для размеров в пикселях можно юзать как щас, а для ратио - задавать именно ратио

при чём я не только за свой вариант говорю, а вообще в целом предлагаю по улучшению структурированности для всех

в таким походом надо не только поле flv url , особенно учитывая что реально flv уже практически нет, а mp4 url, avi url и еще 100500 отдельных полей

Это закончится тем что люди будут путаться что куда писать, будет 100500 вопросов и результат - "скрипт глючит", хотя в реальности надо искать что человек не в то поле что-то вписал

поле ожидет цифру, будете вы юзать там 3х4 или 300х400 - полю совершенно не имеет значения

но если вам надо именно отдельное поле под это, то можно создать кастом переменную в нужном вам формате и вы сможете у себя ее юзать как вам надо