Народ ,кто-нибудь знаком с модификаторами modx?
Значения тв выводятся в виде:
фантазии хватило только на
как положить каждое значение в тег span?
Не хочу загонять в доп. сниппет и пилить строку, подскажите модификатор, пожалуйста!
текст1||текст2||текст3||текст4
и.т.дфантазии хватило только на
[[+version:replace=`||==, `]]
|| заменяет на запятые,как положить каждое значение в тег span?
Не хочу загонять в доп. сниппет и пилить строку, подскажите модификатор, пожалуйста!
Комментарии: 44
В настройках TV можно указать формат вывода, и там есть html-тег.
да, знаю, но почему-то на главной каталога выводится треш текст1||текст2||текст3||текст4, а на деталке норм, параметр вывода указан html-тег — span
причину устал искать, наверно очередной баг modx, вот и написал сюда
причину устал искать, наверно очередной баг modx, вот и написал сюда
Не думаю, что MODX видит разницу между каталогом или деталкой, для него и то, и то — ресурс. Скорее всего вы что-то не так выводите.
да обычно вывожу — в каталоге mFilter2 работает, в нем указан шаблон вывода, а в нем это поле — [[+some_tv]], а на деталке [[*some_tv]]
Чтобы в чанках учитывались типы вывода TV-шек, нужно в вызов mFilter2 добавить:
&processTVs=`имена_tv-шек_через_запятую`
разумеется! — добавлено
К вашему сведению, у самого MODX нет сниппета/скрипта для вывода списка ресурсов, вы скорее всего используете getResources или что-то из набора pdoTools, причем тут MODX немного непонятно.
Не знаю где вы там искали, но точно не там где нужно, т.е. в документации к выше перечисленным компонентам. Прочтите про параметры processTVs и prepareTVs
Не знаю где вы там искали, но точно не там где нужно, т.е. в документации к выше перечисленным компонентам. Прочтите про параметры processTVs и prepareTVs
Феном учите, какие ещё модификаторы… эта дрянь нормально никогда не работала, а поддерживать сайт с этим колдунством в коде просто отвратительное занятие.
Всегда работает, а вот к fenom бывают вопросы :) Хотя это дело привычки. И, кстати, встроенные модификаторы MODX fenom также использует, в доках же есть.
а вот к fenom бывают вопросыКакие?
Лично меня раздражает то, что синтаксис сильно вариативный, типа:
Но смущают такие фразы, типа:
{$id}, {$_modx->resource.tv_param}, {$_modx->lexicon('lexicon')}
, еще нужно учитывать точку, тире и фигурные скобки (куда без них). Смотрится разношерстно и все это помнить нужно. Но, повторюсь, это дело привычки. Так-то в fenom плюшек больше.Но смущают такие фразы, типа:
… просто отвратительное занятие.реально настолько отвратительно? :) И то, и то шаблонизаторы, принципиальной разницы нету.
И то, и то шаблонизаторы, принципиальной разницы нету.Нельзя назвать парсер MODX полноценным шаблонизатором
Ну, судя по статьям в сети, и то, и то подходит под «шаблонизатор».
Ford Model T — тоже автомобиль, и когда был самым популярным)
реально настолько отвратительно?Да, после Fenom это наимерзкая штука, даже притрагиваться противно. На каждый чих нужно писать сниппет, синтаксис сам по себе ужасный. Попробуй написать какую-нибудь более-менее сложную конструкцию с парочкой if-ов. Глаза сломаешь читать это потом.
Что уже говорить про разношерстность этих модификаторов. Одних только != модификаторов (notequalto, notequals, isnt, isnot, neq, ne) уже шесть штук, зачем? Один разработчик использует одно, второй — другое, третий — третье.
Так что еще очень хороший вопрос о том, что разношерстнее — модификаторы или несколько вариаций обращения к массиву в Fenom.
И то, и то шаблонизаторы, принципиальной разницы нету.Если «шаблонизатор» не позволяет пройтись по массиву в цикле, то это никакой не шаблонизатор, это фильтры ввода-вывода — именно так они правильно и называются.
что разношерстнее — модификаторы или несколько вариаций обращения к массиву в FenomДля конкретного разработчика однозначно вариации обращений в fenom больше, т.к. если я и буду использовать модификатор, то один вариант, который привычен (например, :ne=``), а в fenom мне в любом случае нужно использовать все варианты обращений. Но я не понял причем тут модификаторы, я имел ввиду именно вызов тегов MODX. Было бы сильно удобнее, если бы fenom в MODX отрабатывал бы по схожей логике, например:
{$_modx->lexicon('lexicon')} - {$_modx->%('lexicon')}
{$_modx->resource.tv_param} - {$_modx->*('tv_param')}
{$id} - {$_modx->+('id')}
Или еще как-то лаконичнее.Если «шаблонизатор» не позволяет пройтись по массиву в цикле, то это никакой не шаблонизаторЕсть какой-то стандарт требований к шаблонизатору? Я не нашел. Так можно и шире рассуждать, мол зачем вообще писать сниппеты, пусть «тру-шаблонизатор» отрабатывает все.
Для конкретного разработчика однозначно вариации обращений в fenom большеЭто каких вариаций обращения больше? Если ты про различные методы, которые предоставляет объект $_modx, так это нельзя назвать вариациями, это же тот же самый глобальный $modx, только с некоторыми ограничениями.
Под вариациями можно понимать обращение к массиву либо через точку, либо через квадратные скобки, но это легко решается — к массиву можно обращаться всегда через скобки, прямо как в php.
если я и буду использовать модификатор, то один вариант, который привычен (например, :ne=``)Так это для тебя привычен этот вариант, а если тебе достанется сайт от другого разработчика, которому будет привычен вариант notequals?
я имел ввиду именно вызов тегов MODXТак стандартные модификаторы напрямую связаны со стандартными тегами modx.
Не будешь же ты проверять через Fenom-овский {if} наличие [[*id]]
Было бы сильно удобнее, если бы fenom в MODX отрабатывал бы по схожей логикеТак это и так уже есть — альтернативный синтаксис через прямую черту. Например,
{1 | resource : 'pagetitle'}
{'some_entry' | lexicon}
{'some_text' | upper}
Чем не единый стиль?Есть какой-то стандарт требований к шаблонизатору? Я не нашел.Шаблонизатор — это ведь про удобную обработку входящих данных в твоем шаблоне.
Представь, что тебе в чанк прилетел массив, который тебе нужно обработать.
Для первых 3 элементов тебе нужно добавить один css-класс, для остальных — другой.
Шаблонизатор должен решать эти задачи, в этом его и назначение.
Fenom с этим отлично справляется, как и какой-нибудь Smarty/Twig/Blade/etc.
Фильтры ввода-вывода не могут даже по массиву пройтись, тебе нужно будет писать сниппеты или парсить малюсенькие чанки столько раз, сколько элементов в твоем массиве.
Чувствуешь разницу?
мол зачем вообще писать сниппеты, пусть «тру-шаблонизатор» отрабатывает все.Сниппеты нужны для инкапсуляции небольшой логики, которую нерационально оставлять в шаблоне, но никак не для одного if, как в случае со стандартными фильтрами.
Так это и так уже есть — альтернативный синтаксис через прямую черту. Например,Вот с сокращенной записью можно работать, почти оно, но к сожалению, не все можно вывести. Как, к примеру, вывести TV или id текущего ресурса через |?
{1 | resource: 'pagetitle'}
{'some_entry' | lexicon}
{'some_text' | upper}
Чем не единый стиль?
А вызов вида
{'id' | placeholder}
в шаблоне сниппета по-моему не работает вообще. Или тут какие-то подводные камни снова?p.s. Если что, я не говорю, что стандартный шаблонизатор лучше, он просто выглядит логичнее и проще.
Как, к примеру, вывести TV или id текущего ресурса через |?Все это доступно в $_modx->resource. При желании к нему можно обращаться только через квадратные скобки — это обычный массив с данными. Не думаю, что это сложнее, чем различать [[*id]] и [[+id]].
Или тут какие-то подводные камни снова?'id' | placeholder — то же самое, что и $modx->placeholders['id'], какие тут могут быть подводные камни? Если $modx->placeholders['id'] доступен, значит и альтернативная конструкция что-то вернет.
Если что, я не говорю, что стандартный шаблонизатор лучше, он просто выглядит логичнее и проще.Так стандартный «шаблонизатор» практически ничего не умеет. Он призван лишь фильтровать вывод. Это, например, когда нужно вывести текст-заглушку, если плейсхолдер пуст. Тут — никаких проблем. Но что-то сложнее — увы.
Поэтому по большому счету их даже некорректно сравнивать, у них разное предназначение, и там, где Fenom справляется без проблем, стандартный «шаблонизатор» ни в зуб ногой, как говорится.
Все это доступно в $_modx->resource.Вы подменяете понятия, вопрос про стиль написания. Выше вы писали, что есть стиль единый, а выходит он не единый.
@Артем @Баха Волков Я работаю с fenom, я даже не утверждаю что он хуже, наоборот, выше писал, что там плюшек больше и это дело привычки. Но мне, персонально, не нравится как это выглядит (в сравнении с [[+]], [[*]], [[$]] и т.п.). А вы мне пытаетесь обосновать то, что мне это должно нравиться :)
Наше обсуждение можно привести к аналогии:
— Мне не нравится капуста.
— Но тебе должна нравится капуста, она полезна.
— Ну чет не мое, не люблю капусту.
— Да любишь, смотри, голубцы можно сделать же, и прочее, красота!
— …
:)
В итоге, с помощью @Баха Волков и исходников, выяснилось, что унификация написания есть, с помощью модификаторов через | (что не может не радовать):
В итоге вопрос снят, спасибо за обсуждение!
[[*content]] -> {'content' | resource}
[[+pagetitle]] -> {$pagetitle} (не путать с {'result' | placeholder})
[[$chunkName]] -> {'chunkName' | chunk}
[[!snippetName]] -> {'!snippetName' | snippet}
[[++settingKey]] -> {'settingKey' | option}
[[%lexiconName]] -> {'lexiconName' | lexicon}
[[~5]] -> {5 | url}
[[...:ellipsis=`100`]] -> {... | ellipsis : 100}
В итоге вопрос снят, спасибо за обсуждение!
Давным-давно в далёкой галактике пытался комбинировать феном синтаксис с модыксовским
{[$chunkName]}
{[!snippetName] : ['param' => 'value']}
Уже не помню, на чём забуксовал — не пошло или лень стало. Но получилось бы прикольно. ) Поэтому по большому счету их даже некорректно сравнивать, у них разное предназначение,Если тебе гитара нравится больше, чем скрипка, это ещё не значит, что скрипка не музыкальный инструмент. Ребята из MODX в своё время придумали альтернативную парадигму шаблонизации, в которой всю логику засунули в сниппеты. Она реально лаконичнее. Согласен с @Руслан Алеев — теги короткие и понятные даже для непрограммистов. Страница выглядит легче и привычнее. Что, кстати, поддерживается стандартами разработки — меньше логики во вьюхах. Но другое дело, что его перестали совершенствовать. Впрочем, как и MODX в целом и xPDO. Думаю, можно было допилить шаблонизатор до какого-нибудь гибрида с обычными шаблонизаторами. Я в своё время экспериментировал, но потом решил, что староват я для велосипедостроительства.
Я недавно писал про парсер MODX, про специфику и недостатки. В текущее время, с развитием стандартов и большого количества готовых и универсальных шаблонизаторов, парадигма шаблонизации в MODX выглядит как минимум странно.
Если тебе гитара нравится больше, чем скрипка, это ещё не значит, что скрипка не музыкальный инструмент.Так это не мне больше нравится, это вполне объективные вещи, с которыми трудно поспорить.
На данный момент родной «шаблонизатор» в modx просто нельзя назвать шаблонизатором — он не справляется с большинством типовых задач шаблонизации, это же очевидно.
Она реально лаконичнее.Лаконичнее в нем только вызов тегов — тут согласен. Но в реальных сценариях никто не вызывает просто теги, практически всегда требуется дополнительная обработка. А когда ты пишешь сниппет «If», то это уже не кажется таким лаконичным.
Я в своё время экспериментировалДа, вот если бы в нем был такой функционал, то это был бы полноценный шаблонизатор, со своими фичами и идеей, и это было бы круто.
Проясню, что все негодование связано с тем, что текущий вариант шаблонизации в modx без использования Fenom приносит исключительно боль и страдания.
На данный момент родной «шаблонизатор» в modx просто нельзя назвать шаблонизатором — он не справляется с большинством типовых задач шаблонизации, это же очевидно.Слова человека, воспитанного на фреймворковских шаблонизаторах. Ещё раз повторю, ты просто не вник в механизм «скрипки». Он без проблем справится с любыми задачами. Просто ты пытаешься решить её также как в других шаблонизаторах, а в MODX логика другая. И чем дальше, тем она всё менее понятная для современных разработчиков. А в былые времена пилили серьёзные проекты. Тот же Tickets — очень мощная система для блога. Или сниппеты pdoTools. Даже в них ещё старый подход — логика с кучей чанков без фенома. И всё замечательно работает.
Но в современном мире разработки — это уже анахронизм. Ибо фреймворки захватывают мир разработки. Они двигают свои стандарты.
Да, вот если бы в нем был такой функционал, то это был бы полноценный шаблонизатор, со своими фичами и идеей, и это было бы круто.Был бы ещё один шаблонизатор похожий на другие, но в отличие от них (универсальных), он использовался бы только в MODX. А значит судьба его была бы предрешена. И зачем тогда на него тратить время?
Но и с другими шаблонизаторами в MODX ситуация не лучше. Попробуй написать таблицу умножения римскими цифрами. Тот же Fenom заставляют работать в парадигме шаблонизации MODX, а у него другая логика. Я об этом тоже уже много раз говорил.
Ещё раз повторю, ты просто не вник в механизм «скрипки».Если тебе нравится аналогия со скрипкой, то это у нас получается старая неудобная скрипка, на которой нужно играть ногами, иначе не работает.
Так и тут — создавай 25 маленьких чанков, чтобы обработать одну вьюху.
Он без проблем справится с любыми задачами.Правда?
Задача: вывести массив товаров, у каждого товара 3 поля — id, sizes, pictures. Каждые 3 итерации меняется класс товара. Сначала 'a', потом 'b', потом 'c', потом по новой. Если есть размер 50, то товар получает класс 'xl', если же 50 нет, но есть 48, то 'l', в противном случае 'm'. В массиве 'pictures' содержится 2 поля — image & thumb. Если thumb нет, то нужно вывести image.
На вход получаешь один массив со всеми товарами.
{set $classes = ['a', 'b', 'c']}
{foreach $products as $product}
{set $index = $product@index / 3 % 3}
{set $size = (50 | in : $product.size) ? 'xl' : ((48 | in : $product.size) ? 'l' : 'm')}
<li class="product {$classes[$index]} {$size}">
<img src="{$product.thumb ?: $product.image}">
Product #{$product.id}
</li>
{/foreach}
Покажи, пожалуйста, альтернативное решение без проблем. Разумеется, без Fenom.Был бы ещё один шаблонизатор похожий на другие, но в отличие от них (универсальных), он использовался бы только в MODX.Почему? Smarty используется вне modx? Да. Fenom используется вне modx? Да.
Можно было бы написать некий аналог Fenom, но с некоторыми крутыми фичами, которые работали бы только в modx.
Тот же Fenom заставляют работать в парадигме шаблонизации MODX, а у него другая логика.Тут согласен, да. Чего только стоят issue в репе Fenom о том, что ignore не работает в modx.
@Руслан Алеев В главном шаблоне которую будут расширять в начале пишешь:
и вуаля
В твоем примере:
Это легко читается программистом
{set $resource = $_modx->resource}
{set $resource.headline = $resource.longtitle ?: $resource.pagetitle}
{set $config = $_modx->config}
и вуаля
{$resource.id}
{$resource.pagetitle}
{$resource.headline}
{$resource.content ?: $resource.introtext ?: $resource.description}
{$config.site_name}
{$config.site_url}
Лично меня раздражает то, что синтаксис сильно вариативный, типаНе понимаю, в чем вариативность и в чем сложность вообще?
В твоем примере:
{$id} // Это переменная
{$_modx->resource.tv_param} // Доступ к элементу массива, которая является свойством объекта $_modx
{$_modx->lexicon('lexicon')} // Вызов метода объекта $_modx, которой нужно передать ключ лексикона в качестве параметра
Это легко читается программистом
Как, к примеру, вывести TV или id текущего ресурса через |?Нужно просто указать имя поля вместо id ресурса, тогда будет использоваться текущий
{'tvname' | resource}
Да, спасибо, разобрались с этим — modx.pro/help/20713#comment-122474
Попробовал использовать такой вызов, но выводится массив.
Т.е. в итоге,
Т.е. в итоге,
{$_modx->resource.tvname} != {'tvname' | resource}
Хотя, к примеру, {'content' | resource} выведет именно содержание, тут нет ошибки в модификаторе | resource?
Дело в том, что ТВ в MODX и хранится как массив у ресурса, со своим названием, параметрами и прочим.
Если нужно получить сразу значение, то просто добавляй префикс tv.:
Если нужно получить сразу значение, то просто добавляй префикс tv.:
{'tv.tvname' | resource}
Понял, спасибо
Мне всегда было не понятно, зачем нужны были такие конструкции?
{$_modx->resource}
{$_modx->user}
и почему нельзя было эти массивы выделить в отдельные переменные{$resource}
{$user}
Это сформированные массивы из глобальных объектов, которые есть в каждом запросе. Зачем их засовывать в объект $_modx? По привычке наверно.
Потому что в чанк могут передать свои собственные переменные $resource и $user.
Также как и в обычном шаблонизаторе. MODX парсер перед обработкой чанка выгружает все плейсхолдеры, а после обработки загружает обратно.
П.С. Доберусь до компа, попробую. Главное — не забыть! )
П.С. Доберусь до компа, попробую. Главное — не забыть! )
На мой взгляд куда правильнее глобальное хранить в глобальном классе microMODX. Как уже сказал Василий выше:
А если уж очень хочется «попроще» писать, то Баха дал рабочий вариант выше.
в чанк могут передать свои собственные переменные $resource и $userи такое довольно часто происходит. Потому, я считаю, это очень весомый аргумент. Как ты в чанке потом до глобальных свойств доберёшься?
А если уж очень хочется «попроще» писать, то Баха дал рабочий вариант выше.
Как ты в чанке потом до глобальных свойств доберёшься?Аргумент принят.
Но для меня ещё один вопрос не понятен (в своё время Коля Ланец тоже об этом говорил) — нафига вообще нужен этот microMODX класс? Только не говори за безопасность? Ты где-нибудь видел в Ларе или Симфони создавали такие вещи? А сниппеты pdoTools вообще убирают вопрос безопасности в дальний угол.
А если уж очень хочется «попроще» писать, то Баха дал рабочий вариант выше.Для любителей костылей сойдёт. Всякие бест практисы так делать не советуют. Согласись, стрелки и точки в одном выражении как-то не кашерно.
Только не говори за безопасность?Именно для неё.
Потому что чанки писать и править может простой менеджер, без доступа к сниппетам, файлам и знаниям PHP.
Понимаешь, тут сложно спорить. У всех свои понятия безопасности. Откуда такие требования безопасности к простому менеджеру? Были случаи когда такой человек (сотрудник с доступом в админку) грохал сайт или просто гипотетически? В Лаварел и Симфони я не встречал таких требований. Ну допустим. Но когда я тебе говорю, что тот же менеджер может вызвать любой файл сайта (php или html), ты говоришь, ну и пусть. А если также, чисто гипотетически, допустить, что есть чанк, шаблон или сниппет (речь о файловых элементах) с системной информацией, предназначенной только для глаз админа, и этот менежер получает к ним доступ?
Есть ещё одна дыра (Женя Борисов говорил, ты про неё знаешь). Дай мне доступ в админку только с правами контент-менеджера и установленным pdoTools и я стану админом.
Но эти вопросы ты почему-то счситаешь неопасными. Вот я и говорю, всё в мире относительно.
Есть ещё одна дыра (Женя Борисов говорил, ты про неё знаешь). Дай мне доступ в админку только с правами контент-менеджера и установленным pdoTools и я стану админом.
Но эти вопросы ты почему-то счситаешь неопасными. Вот я и говорю, всё в мире относительно.
Я и не спорю, а говорю, зачем это было сделано.
pdoTools пользуются очень много где, и по умолчанию доступ ко всякому опасному через Fenom отключен.
Вопросы безопасности самого MODX меня не касаются.
pdoTools пользуются очень много где, и по умолчанию доступ ко всякому опасному через Fenom отключен.
Вопросы безопасности самого MODX меня не касаются.
Вопросы безопасности самого MODX меня не касаются.Тут ошибка. Ты, наверно, хотел написать pdoTools, а написал MODX. ;)
Понимаю Женю Борисова, который кричал о дырах безопасности, а разрабы MODX его не слышали. Но есть отличие — меня вопросы безопасности pdoTools не касаются! Я сайты не делаю. А те, кто использует pdoTools, держите в уме то, что я написал выше.
Нет, я написал именно то, что хотел.
Я не занимаюсь разработкой MODX уже давно, а pdoTools поддерживаю в актуальном состоянии. Про критические баги pdoTools, дающие возможность взломать сайт, лично я ничего не знаю, иначе бы исправил.
Если у тебя есть такая информация — будь добр, напиши мне про это в телеграмме.
Я не занимаюсь разработкой MODX уже давно, а pdoTools поддерживаю в актуальном состоянии. Про критические баги pdoTools, дающие возможность взломать сайт, лично я ничего не знаю, иначе бы исправил.
Если у тебя есть такая информация — будь добр, напиши мне про это в телеграмме.
Судя по всему, тебе не интересно содержание моих комментариев, а нравится стрелочки тыкать. Be my guest! Enjoy!
Это ты у меня в гостях, если что.
Не хочешь как взрослый общаться — до свидания.
Не хочешь как взрослый общаться — до свидания.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.