соответствие имен GET-параметрам именам фильтров

harizmadark
Posts: 37
Joined: Wed Jan 13, 2021 4:06 pm

соответствие имен GET-параметрам именам фильтров

Post by harizmadark »

приветствую

1. начал разбираться со скриптом, возник один вопрос: по каким правилам осуществляется маппинг имен GET-параметров на имена html-comment макросов и фильтров(параметров) тагов?

например, в wiki указывается, что в случае передачи группы в запросе, как GET-параметра, мы используем её как значение для переменной с именем group_name, однако, в шаблоне для тэга <thumb> мы указываем название группы как значение фильтра group:

Code: Select all

<thumb group=Mygroup num=1-10></thumb>
когда же для вывода её названия в шаблоне, снова используется <!--GROUP_NAME--> (или <!--CATEGORY_NAME--> - более новый вариант)

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

т.е. имея например название тага в виде html-коммента из шаблона, как мне получить по нему название для использования в GET-запросе?

мне кажется что в принципе никаких соглашений по построению имен здесь нет, и как было удобно назвать их автору на момент кодирования, так они и назывались, несмотря на то, что где-то ранее уже такая сущность имеется под своим именем... например force_template из GET-параметра стал просто template в тэге <thumb>, но duration_min & duration_max сохранили своё имя одинаковое для всех мест где они используются.

есть ли где-то нормально офрмленный полный список всех html-тагов (в виде комментариев и собсна в виде нормальных тагов) со всеми принимаемыми ими параметрами, а так же все стандартные возможные GET-переменные и их соответствие друг другу в виде справочника простым списком? вот здесь https://smartcj.com/wiki/doku.php?id=ru ... _templates много чего не уточнено, кроме того там не все таги как понимаю (в инфе по апдейдам встречаются отсутствующие там параметры)

2. где можно взять примеры всех шаблонов с реврайтами для demo.smartcj.com ?
harizmadark
Posts: 37
Joined: Wed Jan 13, 2021 4:06 pm

Re: соответствие имен GET-параметрам именам фильтров

Post by harizmadark »

3. касательно экранирующих префиксов:
думаю, нужно составить некие "рекомендации & best practices" как работать с этими префиксами. сейчас вижу это так (исправьте, если ошибаюсь):
  • 3.1 везде в шаблонах, при выводе любой единицы информации макросами возвращающими текст, типа <!--CATEGORY_NAME--> нужно использовать HTMLENTITY_, т.е. <!--HTMLENTITY_CATEGORY_NAME-->, <!--HTMLENTITY_MODEL_NAME-->, <!--HTMLENTITY_TAG_NAME--> и т.д. (просто этот момент вообще очень скудно уточняется, а везде в примерах используется небезопасный вариант)
  • 3.2 URLSAFE_ для "красоты" ссылок... непонятно вообще в каких случах его нужно использовать. на мой взгляд, те урлы, которыми управляет смарт (урлы на тумбы например) могут меняться только на этапе добавления в базу (замена пробелов на тире и т.д.), но URLSAFE_THUMB_URL уже после - это 404, ровно как и URLSAFE_ на любой другой внешний (споновский) контент.
  • 3.3 как поступать с GALLERY_SLUG ? если я сделаю URLSAFE_GALLERY_SLUG будет ли это то же самое для скрипта, что и просто GALLERY_SLUG по которому он определяет какая именно запрошена галера? если для какой-либо гали GALLERY_SLUG окажется с "опасными" символами, которые я должен экранировать, сможет ли смарт определить настоящий SLUG по безопасной версии или как нужно поступать в этом случае ?
  • 3.4 имхо, все операции типа URLSAFE_ для локального контента, должны осуществляться при импорте, когда смарт раскидует скачанные тумбы/контент, иначе URLSAFE_ на урл где есть пробелы это 404.
Last edited by harizmadark on Wed Jan 13, 2021 8:57 pm, edited 1 time in total.
harizmadark
Posts: 37
Joined: Wed Jan 13, 2021 4:06 pm

Re: соответствие имен GET-параметрам именам фильтров

Post by harizmadark »

4.1 из wiki

в Related Galleries
<thumb sponsor=CURRENT_ITEM_MODEL group="" num=1-5>
some template
</thumb>
наверное имелось ввиду <thumb model=CURRENT_ITEM_MODEL ?

4.2 нужен аналог <!--LINK_STYLE--> и active_link_style, но для классов, т.е.

Code: Select all

<navigation skip_href_deletion=true link_class="pager__link" active_link_class="pager__link--active">
  <li><a href="/?page=<!--PAGE_NUM-->" class="<!--LINK_CLASS-->"><!--PAGE_NUM--></a></li>
</navigation>
создаст (или добавит в конец через пробел, если он уже имеется):

Code: Select all

<li><a href="/?page=1" class="pager__link">1</a></li>
<li><a href="/?page=2" class="pager__link pager__link--active">2</a></li>
<li><a href="/?page=3" class="pager__link">3</a></li>
но в идеале, это конечно делать для parent-ноды, например:

Code: Select all

<navigation skip_href_deletion=false page_class="pager__page" active_page_class="pager__page--active" active_page_replace_tag="span">
  <li class="<!--PAGE_CLASS-->"><a href="/?page=<!--PAGE_NUM-->"><!--PAGE_NUM--></a></li>
</navigation>
сгенерит:

Code: Select all

<li class="pager__page"><a href="/?page=1">1</a></li>
<li class="pager__page pager__page--active"><span>2</span></li>
<li class="pager__page"><a href="/?page=3">3</a></li>
(добавился <!--PAGE_CLASS--> + active_page_replace_tag=имя html-тага, на который заменить <a href=""> если это текущая страница и skip_href_deletion==false)

это более правильнее с точки зрения структурированной верстки как таковой.
Last edited by harizmadark on Wed Jan 13, 2021 11:14 pm, edited 1 time in total.
admin
Site Admin
Posts: 37202
Joined: Wed Sep 10, 2008 11:43 am

Re: соответствие имен GET-параметрам именам фильтров

Post by admin »

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

Да, было бы неплохо если бы все верзе называлось одинаково, но поскольку много чего тянется из старых версий то для обратной совместимости надо сохранять старые варианты, более того например есть category_name= но мастера пишут просто category= и потом спрашивают "почему у меня не работает", чем проверять каждого проще ввести несколько называний переменных

давайте проведем ревизию того что не нравится

относительно group \ category - есть конкретное разделение category - это для ртации, group - для трейдеров

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

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

3.1 почему везде это надо?

3.2 тоже не совсем понял зачем в базе что то менять

3.3 gallery_slug не может быть с опасными символами если вы конечно руками их туда не добавите

3.4 почему?

4.1 поправил

4.2 скрипт не доабвляет что-то там в предыдущую ноду, никак не меняет html , он только заменяет таг скрипта на актуальную инфу

зачем эти навороты если вы можете сделать

link_class="pager__link" active_link_class="pager__link pager__link--active">


и получите тоже самое
Don't forget to run script update
harizmadark
Posts: 37
Joined: Wed Jan 13, 2021 4:06 pm

Re: соответствие имен GET-параметрам именам фильтров

Post by harizmadark »

давайте проведем ревизию того что не нравится
да не, тут дело не в том, что что-то не нравится, а просто непонятно как юзать в тех или иных случаях, которые не описаны в wiki. а в случае со смартом скорее-всего просто нужно принять что нет какой-либо четкой системы и просто запоминать как что называется в каждом конкретном случае. но это, как уже сказал - не проблема, просто было непонятна сама система "naming convention", и вполне удовлетворяющий в данном случае ответ - что она просто отсутствует. ок, проехали с этим.
3.1 почему везде это надо?
ну как почему? мы никогда не должны верить "сырому" контенту из базы, пусть даже и от спона и просто вставлять его в качестве текстового контента на страницу... ясен, я не говорю что спон в своём экспортируемом контенте будет спецом отдавать нам какую-то XSS, но там всякое может быть, что при неэкранированной вставке as is, просто порвёт вёрстку (как много может быть такого контента и сколько таких спонов - вопрос другой, здесь главное что как-бы вообще всегда нужно всё экранировать, что выводится из БД в вёрстку - например я часто в дампах видел тайтлы где присутсвуют не просто html-тэги, но "битые" html-тэги, которые просто порвут верстку, если сделать <!--CATEGORY_NAME--> вместо <!--HTMLENTITY_CATEGORY_NAME-->).
в общем весь 3-й пункт - чисто "филосовский" поэтому тоже проехали. а для себя лично, считаю что HTMLENTITY_ юзать обязательно (кстати, наверное все известные на данный момент шаблонизаторы по дефолту форсируют этот безопасный режим, т.е. вообще всё, что выводится макросами в их шаблонах, неявно проходит ф-нал аналогичный HTMLENTITY).
зачем эти навороты если вы можете сделать
link_class="pager__link" active_link_class="pager__link pager__link--active">
да, но здесь просто вопрос семантики: "link" - это конкретно ссылка (семантически), а вот кнопка пэйджера, "page" - какой-угодно контейнер, и в данном случае, нам удобнее повесить класс именно на контейнер (page) и дальше от него каскадировать через immediate children селектор, т.е.

Code: Select all

.pager__page--active > span {...styles}
.pager__page > a {...styles}
поэтому, параметр в таге navigation, для навешивания класса на "page", логичнее называть как page_class & active_page_class, но опять же, это вопрос чисто семантики, и если добавите просто active_link_class то тоже норм (единственное что - добавлять именно класс, а не просто стиль, всё-таки нужно для нормальной правильной верстки)

в общем, сейчас уже успел составить для себя более общую картину по скрипту... здесь нужно именно вначале "тыкать", а не читать документацию, поэтому, на данном этапе у меня наверное всё, когда появятся новые вопросы буду задавать.
admin
Site Admin
Posts: 37202
Joined: Wed Sep 10, 2008 11:43 am

Re: соответствие имен GET-параметрам именам фильтров

Post by admin »

Ок, как я понимаю из актуальный вопросов только "параметр в таге navigation, для навешивания класса на "page", логичнее называть как page_class & active_page_class", убирать существующий параметр конечно нельзя, можно эти довесить к тому что уже есть. Делаем?
Don't forget to run script update
harizmadark
Posts: 37
Joined: Wed Jan 13, 2021 4:06 pm

Re: соответствие имен GET-параметрам именам фильтров

Post by harizmadark »

Делаем?
угу, реальный пример где это действительно нужно: я делаю сетку master-slave на одном html-шаблоне но в 10-и цветовых вариациях, где структурно только одна верстка на все 10 сайтов (1 мастер, 9 слэйвов), а шаблоны отличаются только ссылкой на каждый отдельный css с цветовой схемой под этот сайт (типа в хэдере <link href="/css/dark.css"> - мастер, /css/metal.css - слэйв 1, /css/kitkat.css - слэйв 2 etc), но если у меня ссылки (или вообще что угодно) стилизируются через inline-стили, то мне так же приходится:

- менять все шаблоны во всех местах где есть inline-стили
- ну и вообще, юзать аттрибут style для таких вещей - вообще не камильфо

в принципе решая главную первую проблему по кастомизации цветовых гамм старыми параметрами, что бы не править все шаблоны, можно "выкрутиться" хаком заюзав css custom vars, типа как:

Code: Select all

<navigation skip_href_deletion=true link_style="--link-color: blue;" active_link_style="--link-color: red;">
  <li><a href="/?page=<!--PAGE_NUM-->" class="<!--LINK_CLASS-->"><!--PAGE_NUM--></a></li>
</navigation>
а сами стили писать как:

Code: Select all

.pager__link {color: var(--link-color);}
но имхо это изврат, т.к. можно просто навесить нужный класс на контейнер в зависимости от его состояния.

так что, имхо, необходимость добавления page_class & active_page_class обоснована

зы: не, ну можно ещё !important во всех цветовых вариациях (/css/metal.css, /css/kitkat.css) к стилю ссылок в пэйджере добавлять что б все шаблоны не переколупывать, а только эти css-файлы с цветовыми гаммами , но ведь реально изврат, имхо ) так что проще и правильнее это клаcсами для контейнеров пагинации (<li>, <div>) делать
admin
Site Admin
Posts: 37202
Joined: Wed Sep 10, 2008 11:43 am

Re: соответствие имен GET-параметрам именам фильтров

Post by admin »

"шаблоны отличаются только ссылкой на каждый отдельный css с цветовой схемой под этот сайт (типа в хэдере <link href="/css/dark.css"> - мастер, /css/metal.css - слэйв 1, /css/kitkat.css - слэйв 2 etc), но если у меня ссылки (или вообще что угодно) стилизируются через inline-стили, то мне так же приходится:

- менять все шаблоны во всех местах где есть inline-стили
- ну и вообще, юзать аттрибут style для таких вещей - вообще не камильфо"


опять же - зачем эти навороты если можно прописать нужный стиль в файле css и в пагинации юзать его? те зачем в пагинации - инлайн стили? это ж уже разные шаблоны и массово их не заюзаешь.
Don't forget to run script update
harizmadark
Posts: 37
Joined: Wed Jan 13, 2021 4:06 pm

Re: соответствие имен GET-параметрам именам фильтров

Post by harizmadark »

опять же - зачем эти навороты если можно прописать нужный стиль в файле css
ну да, я о том же: добавление page_class & active_page_class обосновано, и привожу развернутые аргументы этого утверждения
admin
Site Admin
Posts: 37202
Joined: Wed Sep 10, 2008 11:43 am

Re: соответствие имен GET-параметрам именам фильтров

Post by admin »

я видимо не понял

сейчас в шаблоне пишем

link_style="стиль1" active_link_style="стиль2"

после этого шаблон менять не надо, только файл стилей

что тут не так?
Don't forget to run script update
Post Reply