SmartCJ Support Forum

предлагаем добавить упрощенный и переносимый между шабонами (без php-костылей и лишнего кода) способ вывода preview-контента (Video Preview\Rolling Thumbs) при наведении мыши.

Для этого:

1. условно считаем, что всего может быть только два типа preview-объектов: "thumbs" (без уточнения user или ротации) & "video" (то, что было импортировано под паттерном `video_preview_url`)

2. в цикл <thumb> добавляется два парамерта:

2.1. `preview_types_attr` принимающий в качестве значения имя будущего html-атрибута, который будет выведен вместо нового тэга <!--PREVIEW_TYPES_INFO-->, с одним или более интересуемыми нас типами preview-объектов из пункта #1, в качестве значения этого атрибута

если `preview_types_attr` не задан явно, то для данного цикла весь механизм preview отключается (экономим ресурсы)

2.2 `preview_types_priority`, который задаёт порядок и приоритетность имеющихся типов preview и может иметь значения: "thumbs", "video", "all"

на основе порядка его значений, новый тэг <!--PREVIEW_TYPES_INFO--> будет возвращать preview-тип сразу по определению его наличия, или пустую строку если требуемый preview-тип у галеры отсутствует

3. добавляется новый тэг <!--PREVIEW_TYPES_INFO-->, возвращающий имя html-атрибута (из параметра `preview_types_attr`) c имеющимся preview-типом для этой галеры, или пустую строку, если требуемый preview-type для галеры не задан

`short-circuit` для <!--PREVIEW_TYPES_INFO-->: поиск preview объектов запрошенных типов прекращается как только был найден первый preview-type, соответствующий находящемуся в начале списка переданных значений, например:

- preview_types_priority="video,thumbs" и для галеры есть видео превью (галера импортировалась с паттерном `video_preview_url` ): в этом случае <!--PREVIEW_TYPES_INFO--> сразу вернёт `data-preview-type="video"`

- preview_types_priority="thumbs, video" и для галеры есть тумбы и видео: в этом случае <!--PREVIEW_TYPES_INFO--> сразу вернёт `data-preview-type="thumbs"`

- preview_types_priority="thumbs, video" и для галеры есть видео превью, но нет тумб: в этом случае <!--PREVIEW_TYPES_INFO--> вернёт `data-preview-type="video"` не смотря на то, что юзера интересует thumbs в первую очередь

- preview_types_priority="all" - <!--PREVIEW_TYPES_INFO--> вернёт через пробел вообще все preview-типы, которые есть для этой галеры: `data-preview-type="video thumbs"` (через пробел - для селекта их в CSS-е)

значение по умолчанию preview_types_priority - 'video,thumbs' (видео preview эффективнее чем Rolling тумбами)

4. новый тэг <!--PREVIEW_ITEMS-->, использующийся в отдельном шаблоне, который на основе полученного в query string парамерта `preview_type` вернёт json-список реально имеющихся preview-объектов для этой галеры

<!--PREVIEW_ITEMS--> анализирует все те же самые параметры которые можно передать смарту (gallery_id, gallery_slug, sponsor_id, trader_id, etc), плюс новый `preview_type`, который указывает какой именно тип preview ("thumbs" | "video") нам требуется

т.е. просто отдаёт json_encode массива всех preview-объектов переданного в `preview_type` типа

так же, если preview_type==thumbs, то <!--PREVIEW_ITEMS--> возвращает те тумбы (<!--USER_THUMBS_FOLDER-->/*.* или <!--ALL_THUMBS-->) которых больше (как правило, это user thumbs, но смарт должен проверить, что в <!--USER_THUMBS_FOLDER-->/*.* они реально существует, и что собственно их больше чем <!--ALL_THUMBS-->)

5. (опционально) форсирование отключения определения preview types через GET-параметр disable_preview_types=true, но без изменения самих шаблонов, например:
т.е. мы специально отключаем механизм определения preview-типов и экономим ресурсы для страниц > 10, т.к. это скорее-всего бот, а не серфер

ПОЛНЫЙ ПРИМЕР ИСПОЛЬЗОВАНИЯ:

1. мувисная галера импортировалась с паттерном `video_preview_url`, имеет только одну тумбу ротации, нет пиксового контента (скриншотов, юзер-тумб и прочего):
это рендерится в:
псевдо-код на frontend:
код шаблона `my_preview_items_template.tpl`: возвращает `json_encode` этого массива (возможно, сразу экранируя все опасные для json символы), т.е:
если бы `preview_type` был 'thumbs', то <!--PREVIEW_ITEMS--> определив каких тумб больше (ротации или user thumbs) вернул бы что-то вроде:

Сорри, но выведение \ генерация html кода во внутрь скрипта - это сразу мимо концепции разделения кода и html

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

Все это делается без скрипта, прямо в темплейте и так же темпелйт копируется на новый сайт если надо, в чем тут проблема?

admin wrote: Сорри, но выведение \ генерация html кода во внутрь скрипта - это сразу мимо концепции разделения кода и html

ну не вопрос, эта фича - просто предложение, не более

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

по поводу разделения кода - параметр `preview_types_attr`, в этой концепции, ни чем не отличается от уже имеющегося `separator`, который так же может содержать что угодно (включая разделительный html), но и с другой стороны - мы здесь рассматриваем именно шаблон, то есть - чисто html, и вот именно по этой причине, мы и предложили способ, который поможет ещё больше избавиться от чего-либо в шаблоне, кроме декларативных тэгов (html или смарта). в любом случае, от `preview_types_attr` можно отказаться, оставив только `preview_types_priority`, а `<!--PREVIEW_TYPES_INFO-->` будет тогда просто возвращать названия самих preview-типов (т.е. просто "thumbs video", "thumbs", "video" и всё)

admin wrote: Все это делается без скрипта, прямо в темплейте и так же темпелйт копируется на новый сайт если надо, в чем тут проблема?

проблема - в лишнем обязательном коде, который должен копироаться из шаблона в шаблон, а так же в необходимосте знаний верстальщика о внутренней специфике получения тумб разного типа для роллинга, усложнении у увеличении постоянно копируемого кода от шаблона в шаблон, когда в предлагаемом механизме, можно было бы обойтись только двумя (одним) новым параметром для <thumb>, одним новым тэгом `<!--PREVIEW_TYPES_INFO-->` в нужном месте шаблона где мы хотим получить данные о имеющихся preview-типах для текущей галеры, и одним тэгом <!--PREVIEW_ITEMS-->, который бы и выводил все имеющиеся preview нужного типа, не заставляя верстальщика вникать в процесс их получения, обработки краевых условий и прочее. т.е. проще говоря: как сейчас - это неудобно с точки зрения верстальщика

тогда хотели бы попросить вас просто показать правильный, универсальный и переносимый между разными шаблонами способ получения:

1. инфы о реальном наличии тумб\превью для галеры выводимой в цикле <thumb> (при условии, что это работает для галер от любого источника)

2. получения конкретного типа имеющегося превью (мувисы, тумбы - не важно какие user thumbs или ротации, главное, что б выбирался тип с максимальным кол-вом таких тумб) для данной галеры

3. получение упорядоченного списка URL-ов на элементы превью требуемого типа (тумбы, видео)

т.е.:

тогда ваш пример мы и будем считать основным, и дальше везде использовать.

пойдем по очереди


1. инфы о реальном наличии тумб\превью для галеры выводимой в цикле <thumb> (при условии, что это работает для галер от любого источника

например

<? if ('<!--VIDEO_PREVIEW_URL-->') { ?>

один вариант

<? } else { ?>

другой вариант

<? } ?>




PS вы верстальщик?

2. получения конкретного типа имеющегося превью (мувисы, тумбы - не важно какие user thumbs или ротации, главное, что б выбирался тип с максимальным кол-вом таких тумб) для данной галеры

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


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

В первом случае надо напрягать сервак тысячи раз каждый день, во втором - напрячь мозг 1 раз при написании темплейта и экономить потом все время существования сайта

admin wrote: В первом случае надо напрягать сервак тысячи раз каждый день, во втором - напрячь мозг 1 раз при написании темплейта и экономить потом все время существования сайта

кажется мы немного отходим от сути проблемы, меняя её изначальный контекст... смотрите, конкретно по обсуждаемому пункту, мы сейчас обсуждаем тот факт, что <!--USER_THUMBS_FOLDER--> просто возвращает статический путь, просто добавляя ID галереи, но ни как не проверяя реальный факт её существования, что делает этот тэг в принципе малоинформативным, т.к. мы могли бы вычислить этот путь используя другие тэги (<!--GALLERY_ID--> например)

как вы считаете, в контексте конкретно задачи выяснения факта реального существования директории с юзер тумбами, не следует ли если не поменять ф-ность <!--USER_THUMBS_FOLDER--> (если такой директории реально не существует, то этот тэг должен будет вернуть просто пустую строку) то добавить другой - который это реально делает (типа <!--REAL_USER_THUMBS_FOLDER-->) и в случае отсутствия такой директории, он просто вернёт пустую строку, что мы и будем использовать в качестве условия определения какой тип тумб для галеры реально используется ?

но в любом случае, при необходимости определения реального факта существования юзер тумб (стандартными средствами Смарта или каким-то php-костылём), нам всё равно придётся напрягать сервак этим тестом... если конечно мы просто не примем, что имеющимися средствами скрипта это нормально не реализуется, и проще будет от идеи определения имеющихся типов preview просто отказаться... что б не грузить сервак?

Если вы создаете сайт без user_thumbs и вы это конечно знаете в процессе создания - зачем добавлять условный REAL_USER_THUMBS_FOLDER ?

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

да, такое можно сделать, но ценой доп нагрузки

выбор:
- или постоянная допнагрузка везде с мегатемплейтом
- или 1 раз при создании сайта добавить темпелйт с нужным вариантом превью

я верно угадал ?

admin wrote: я верно угадал ?

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

это стандартный паттерн юзер-интерфейса просто, множество других ЦМС предоставляют подобные возможности из коробки (просто в силу другого принципа хранения мета-данных об имеющихся объектах), и поэтому мы не считали, что могут возникнуть какие-то серьёзные проблемы в данном случае

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

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

но в целом, думаю, если бы <!--USER_THUMBS_FOLDER--> возвращал бы что-либо (кстати, почему "folder"? этот макрос возвращает именно URL) если вообще создавались юзер тумбы, и пустую строку если юзер тумбы не создавались в принципе - некоторая часть задачи была бы решена

чисто субъективное мнение - при импорте галеры (реграбе, обработки скриншотов и т.д.) можно было бы просто сохранять куда-то в таблицу, в качестве логического доп. атрибута этой галеры, сам факт что для данной галеры генерились юзер тумбы, и после проверять это в обработке <!--USER_THUMBS_FOLDER-->, и если не генерились - то сразу возвращать пустую строку, если генерились - то возвращать как сейчас (т.е. не проверяя физического наличия тумб)

в общем, ситуация с положением дел в этом, в принципе ясна, запрос фичи закрываем.

благодарим за ваши комментарии и разъяснения.