Сниппеты MODX Revolution. Modx наборы параметров


Сниппеты MODX Revolution

Что же такое сниппеты

Согласно определения сниппеты (Snippets) — это «небольшие кусочки много раз применяемого исходного кода» («a short reusable piece of computer source code»). Иными словами сниппеты являются вставками PHP-кода в код основания выдаваемых сервером страничек. При помощи сниппетов формируется динамический контент, к примеру, динамические меню, новостные сводки, выдача итогов поиска и вообщем все, то, что нужно различной выдачи в зависимости от пожеланий и запросов пользователя.

Применение сниппетов

После установки сниппета, вы может попросту внедрить тег вызова сниппета<code>[[MySnippet]]</code>в шаблон, чанк, добавочное поле (TV) либо конкретно в документ в том месте, где желателдьно появление сниппета. В случае если вы желаете, чтобы код сниппета был разным для различных пользователей, у вас есть возможность вызова сниппета таким образом, чтобы он был некешируемым:[[MySnippet]]

Характеристики сниппета

Сниппеты располагают параметрами (Properties), которые могут быть переданы сниппету при вызове, приблизительно так:<code>[[!Wayfinder? &startId=`0` &level=`1`]]</code> Вы можете сформировать пакет параметров, который является коллекцией параметров, ассоциированных с этим сниппетом (и любым иным компонентом MODx). Это дает возможность облегчить вызов параметров для сниппета, записав их все в одном месте. Параметров для каждого элемента MODx (в том числе, и для сниппета) создаются на вкладке «Параметры» соответствующего компонента: В случае если вы сформировали набор параметров, который решили назвать 'Menu', и в котором параметру `startId` задаётся значение 0, а параметру `level` — 1, то у вас есть возможность вызов сниппета записать таким образом:<code>[[!Wayfinder@Menu]]</code> При данном отмеченные значения параметров передадутся сниппету автоматом. При этом в строчке вызова данные значения будут переопределены:<code>[[!Wayfinder@Menu? &level=`2`]]</code> В данном случае значение параметра `level`, которое заданно в наборе в 1, установится 2.

www.modx.cc

Наборы параметров

Вообще раньше только пару раз использовал Наборы параметров. А зря… Их силу оценил только сегодня, когда полез переносить очередной старый сайт на Рево. Как раз недавно писал про обновление сайта. Так вот, там я писал, что так как сайт старый, то просто в базе копировал содержимое отдельных таблиц, и последним пунктом выполнял обновление (читай установку новых/голых) пакетов. Так вот, я там не написал с какой проблемкой столкнулся при таком переносе. И проблема не в самом способе переноса, а в ошибочном подходе к переопределению параметров сторонних элементов.

Простой пример: прописываем вызов сниппета [[Wayfinder?startId=`0`]], но чтобы не переопределять каждый раз все эти innerClass, rowTpl и прочее, просто идем в редактирование сниппета Wayfinder и в удобном редакторе правим нужные нам Параметры по умолчанию. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/58077ac897.jpg

И все. Переопределили все нужные нам параметры, и теперь везде можно тыкать [[Wayfinder]], и не прописывать каждый раз одни и те же параметры. Удобно? А то!

А теперь представьте, что по какой-то причине сниппет Wayfinder (не важно по какой). Само собой удалились и все Параметры по умолчанию, в том числе и те, которые переопределели вы. А там и шаблон был указан с интуитивным названием RowTpl12321SDF, и несколько excludeDocs (2,3,4,5,7,12-34,56-77) и т.д. И как, теперь все это опять где-то искать, переопределять и т.п.?

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

Но как оказалось, есть вполне деликатное решение данной проблемы. И это — Наборы параметров. В чем их суть? Создается набор параметров, связывается с объектами MODX, и можно создавать свои параметры, или (и это главное), переопределять имеющиеся параметры связанных объектов.

Опять пример. В свой шаблон мы воткнули сниппет [[!Login]]. Смотрим результат. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/2878661175.jpg

Хотим изменить шаблон формы. Само собой нам надо изменить параметр loginTpl. Но для этого мы не будем ни редактировать этот параметр по умолчанию, не передавать его в вызов сниппета. Вместо этого мы создадим свой Набор параметров. Назовем его Site, дабы не профилировать его с ходу. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/26c865e2ee.jpg

http://modxclub.ru/uploads/images/00/00/01/2013/06/30/a1345f8b81.jpg

http://modxclub.ru/uploads/images/00/00/01/2013/06/30/54ccb75ec8.jpg

Теперь этот Набор нужно привязать к сниппету Login. Вообще связывать можно с чанками, сниппетами, плагинами и TV, при чем не с одним элементом. Потому и говорю, что не обязательно с ходу профилировать набор. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/b5fc4e7011.jpg

http://modxclub.ru/uploads/images/00/00/01/2013/06/30/9ff2930e06.jpg

http://modxclub.ru/uploads/images/00/00/01/2013/06/30/12b097df7a.jpg

http://modxclub.ru/uploads/images/00/00/01/2013/06/30/66662848b4.jpg

Все, связали со сниппетом Login. А теперь внимание! Кликаем Login, и что там видим? http://modxclub.ru/uploads/images/00/00/01/2013/06/30/5a3afb84ad.jpg

А там мы сразу видим все Параметры по умолчанию сниппета Login. И здесь же можем изменить нужные нам параметры. К примеру я изменю loginTpl. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/4dabb1f6b2.jpg

Но самое приятное не то, что мы здесь же можем параметры править. Самое приятное вот что: 1) Мы не только этот параметр видим в списке всех параметров. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/32931fbfbe.jpg

Главное — мы видим измененный параметр в отдельности, если кликнем на сам Набор параметров. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/b99ab58bd0.jpg

2) Изменив параметр сниппета Login, мы не изменили параметр в самом сниппете. Там он остался прежним. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/a469944391.jpg

А вот это уже действительно удобно. Теперь остается только в элемент передать ссылку на Набор, и все. [[!Login@Site]] Смотрим результат (только не забывайте, что WebLoginSideBar — это мой пользовательский чанк-шаблон для Login, потому кто захочет поэкспериментировать, просто написать имя этого чанка недостаточно): http://modxclub.ru/uploads/images/00/00/01/2013/06/30/f37399a5d7.jpg

А теперь в этот же набор можно добавить и другие объекты, к примеру сниппет Wayfinder. И не только переопределим его параметры, но и свой новый добавим. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/ffbabefb13.jpg

И все измененные параметры мы видим в одном месте. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/53cfb02775.jpg

При этом мы сами решаем, когда использовать эти параметры, а когда нет (то есть передавать параметр @Site объекту или нет).

В общем кому как, но на мой взгляд все это очень удобно. Хотя видимо не очень популярно, так как не смотря на то, что уже версия Revolution 2.2.5, не то, чтобы ошибки какие-то, элементарные недоработки есть. К примеру, тупо нет возможности удалить какой-либо параметр, даже свой, пользовательский. В контекстном меню пункт Редактировать есть, а Удалить — нет. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/3be22e1e46.jpg

Но это не большая проблема. Сейчас мне это не мешает, а потом наверняка доработают.

UPD: А вот с синтаксисом есть особенности. Название Набора параметров не должно следовать за вопросительным знаком. Так же нельзя указать сразу два набора параметров. Так что, если хотите вызвать с набором параметров, и еще и на лету переопределить какие-то параметры, то пишем так: [[!Wayfinder@Site?&limit=`2`&rowClass=`row`(и так далее)]]

UPD 2:Еще одна приятность: возможность восстановить изначальное значение по умолчанию, при этом это действие будет локально только для связанных с этим Набором объектов, а не затронет всю систему в целом. Вот у меня два Набора, связанных со сниппетом Wayfinder. Каждый набор использует для себя дефолтовые параметры из Wayfinder. В каждом наборе свои переопределения параметров. Но если в каком-то наборе я восстанавливаю дефолтовое значение, это восстановление касается только этого набора. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/d607dab646.jpg

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

modxclub.ru

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

В первом «сравнительном» уроке я постарался перечислить все элементы (объекты), присутствующие в MODX Revolution (хотя вряд ли смог все перечислить). В этом уроке мы постараемся классифицировать их, чтобы понять, что для чего нужно.

Сразу определюсь, под каким углом мы будем все это рассматривать: мы постараемся разобраться, для разработки на каком уровне будет достаточно знать только HTML, не имея опыта программирования на PHP, а на каком уровне без PHP уже обойтись будет нельзя. Забегая вперед скажу, что довольно много можно сделать без знания PHP, и даже такие объекты, как сниппеты и плагины, которые в принципе содержат в себе PHP-код, и то можно использовать без знания PHP, если использовать именно сторонние решения, и есть достаточно внятная документация по использованию.

Итак, для начала попробуем просто своими словами определить два уровня разработки:

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

Так что же нам дает MODX Revolution, как среда разработки сайтов? А дает он многое. На нем можно создавать как простые сайты-визитки, так и очень серьезные проекты. И в зависимости от того, какие стоят задачи, для разработки своего проекта можно будет ограничиться даже набором стандартных готовых решений (типа Wayfinder, getResources и т.п.), а где-то уже потребуются серьезные знания и опыт веб-разработок, но зато даже в базовой сборке MODX Revolution способен дать инструментарий для разработки веб-разработчикам любого уровня. Главное только понимать что для чего нужно.

Пойдем по порядку.

Ресурсы (modResource)

По сути основа любой страницы сайта. Содержит все основные параметры страницы (краткий и длинный заголовок, описание, пользовательский контент и т.п.). Здесь вообще все просто, разобраться даже блондинка сможет (с подсказками), которая хотя бы в ворде работала. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/a4855d1a13.jpg

В настройках страницы можно указать (или увидеть, если уже указано) родительский ресурс, даты публикации и отмены публикации, является ли страница контейнером и т.п. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/4cd387d893.jpg

Так же можно указать тип документа. По умолчанию это HTML, но можно указать и другой тип, к примеру XML. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/d0fe5f5306.jpg

Тип документа влияет на то, какие заголовки будут отправлены сервером браузеру, суффикс страницы в адресной строке (если используется ЧПУ) и т.п. Помимо стандартных типов документов, можно создать сколько угодно своих. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/bb0dceec77.jpg

http://modxclub.ru/uploads/images/00/00/01/2013/06/30/2e54e9942c.jpg

http://modxclub.ru/uploads/images/00/00/01/2013/06/30/80c49cee15.jpg

В третьей вкладке управления ресурсом можно указать к каким группам ресурсов данная страница относится. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/78b6b33ec9.jpg

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

Шаблоны (modTemplate)

С шаблонами все просто, и все сложно. Простое расскажу сейчас, для объяснения более сложного посвящу отдельный урок. Шаблоны выполняют две задачи: 1. Собственно, оформление выводимой на сайте страницы. То есть шаблон содержит HTML-код и чаще всего прописанные в нем MODX-элементы (чанки, сниппеты, TV-параметры, плейсхолдеры и т.п.). 2. Страницам могут назначаться пользовательские дополнительные параметры (TV-параметры. Только это не относится к телевизорам, это Template Vars). Так вот создаваемые TV-параметры назначаются нужным шаблонам, и тогда, выбирая в редакторе страницы шаблон, к которому привязаны TV-параметры, появляется вкладка с дополнительными полями. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/1d687d04dc.jpg

http://modxclub.ru/uploads/images/00/00/01/2013/06/30/ad831e1132.jpg

Но странице так же может быть указан пустой шаблон. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/548b6a0586.jpg

В таком случае на странице будет выведен только контент данной страницы, без какого-либо оформления. Это надо при создании таких ресурсов, как CSS, JS, XML и т.п.

Синтаксис MODX, чанки, сниппеты и прочие элементы

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

Итак, посмотрим код шаблона:

<html> <head> <title>[[++site_name]] - [[*pagetitle]]</title> <base href="[[++site_url]]" /> </head> <body> [[*content]] </body> </html>

Здесь мы видим знакомые нам HTML-теги, типа head, title и т.п., а так же видим конструкции, заключенные в двойные квадратные скобки. Как раз это и есть элементы (теги) MODX. Все теги перечислины на этой странице официальной документации. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/1a1ab734e0.jpg

Коротко: все MODX-элементы заключаются в двойные квадратные скобки. Когда MODX-парсер обрабатывает код генерируемый страницы, он ищет свои теги. Найдя тег, он его обрабатывает, и заменяет этот тег результатом выполнения этого объекта. Тип MODX-объекта определяют специальные зарезервированные символы (если они есть. Если нет, то по умолчанию объект — сниппет). Какие символы?

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

++ Системный плейсхолдер. Такие плейсхолдеры хранят значения системных переменных. К примеру в настройках системы указывается название сайта. Эта системная переменная — site_name. Если где-то вставить системный плейсхолдер [[++site_name]], то на выходе в коде мы получим как раз значение этой переменной. Другая системная переменная site_url хранит полный адрес сайта, включая протокол (http, https и т.п.).

* Параметр страницы. Описанный выше объект modResource имеет ряд зарезервированных параметров, содержащих значения этих полей. К примеру Заголовок страницы содержится в параметре pagetitle, длинный заголовок в параметре longtitle. То есть для того, чтобы вывести заголовок страницы в конечный код, мы просто в нужном нам месте прописываем [[*pagetitle]] По всем названиям полей страницы, можно получить подсказки, просто наведя курсор мыши на нужное поле. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/23a6cae473.jpg

Кстати, дополнительные поля имеют такое же обозначение, как параметры страницы, то есть тоже обозначаются звездочкой.

$ Чанки (блоки HTML-кода)

~ Ссылки на MODX-ресурсы (страницы). К примеру, чтобы получить ссылку на страницу с ID 5, достаточно просто прописать [[~5]]. MODX обработает этот тег и сформирует ссылку с учетом настроек системы (учитывая используется ли ЧПУ или нет, является ли документ контейнером и т.д.)

% Значение словаря.

Как я уже сказал выше, сниппеты не имеют спецсимвола, то есть они просто заключены в квадратные скобки. К примеру [[my_snippet]]. Что такое сниппет? Это объект, содержащий блок PHP кода.

Можно использовать вложенные теги. К примеру [[~[[++site_start]] ]] вернет ссылку на главную страницу. Здесь произойдет двойной вызов. MODX найдет тег-ссылку ~, но для формирования конечного значения обработает системный настройку [[++site_start]], которая хранит ID главной страницы, и передаст ее значние. То есть если site_start имеет значение 1, то по сути мы получим [[~1 ]]. Но конструкция [[~[[++site_start]] ]] хороша тем, что в настройках мы можем поменять ID главной страницы, а MODX все равно сгенерирует актуальную ссылку.

! Флаг, указывающий, что данный элемент не кешируемый. Используется для чанков, сниппетов и TV-параметров. Плейсхолдеры не бывают кешируемыми. Подробней о кешировании и примерами читаем здесь.

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

Итак, двинемся дальше.

Параметры TV (modTemplateVar)

Дополнительные поля. Очень полезный элемент. Хотя ресурсы имеют все важные поля (заголовок, дата создания, контент и т.п.), часто этого бывает не достаточно. К примеру мы хотим на сайте сделать новостную ленту, и хотим, чтобы в списке новостей выводилась аннотация новости и картинка-превью. Аннотация есть ( [[*introtext]] ), а вот картинки-превью нет. Но это не беда, такое поле легко создаться.

TV-параметрам так же будет посвящен отдельный урок.

Чанки (modChunk)

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

Сниппеты (modSnippet)

Объекты, содержащие PHP-код. Эти элементы так же можно использовать без знания PHP. К примеру сформировать меню, вызвав сниппет [[Wayfinder]]. Но вот для того, чтобы изменить сниппет, или создать свой, уже понадобится знание PHP.

Наборы параметров (modPropertySet)

Крайне полезная штука. Подробней читаем здесь.

Все, написал уже много буков, хватит на сегодня. Все перечисленное позволит клепать сайты-визитки на потоке, практически не требуя знания PHP и внутренней структуры MODX. Если в Эво хотя бы при установке готовых компонентов приходилось хоть что-то делать (разархивировать, закинуть куда надо, часто что-то прописать), то в Рево практически все делается через интерфейс.

Более детально все разбирать будем в последующих уроках. В дальнейшем буду меньше мучать картинками, больше выкладывая видео.

modxclub.ru

Топики с тегом наборы параметров

Вообще раньше только пару раз использовал Наборы параметров. А зря… Их силу оценил только сегодня, когда полез переносить очередной старый сайт на Рево. Как раз недавно писал про обновление сайта. Так вот, там я писал, что так как сайт старый, то просто в базе копировал содержимое отдельных таблиц, и последним пунктом выполнял обновление (читай установку новых/голых) пакетов. Так вот, я там не написал с какой проблемкой столкнулся при таком переносе. И проблема не в самом способе переноса, а в ошибочном подходе к переопределению параметров сторонних элементов.

Простой пример: прописываем вызов сниппета [[Wayfinder?startId=`0`]], но чтобы не переопределять каждый раз все эти innerClass, rowTpl и прочее, просто идем в редактирование сниппета Wayfinder и в удобном редакторе правим нужные нам Параметры по умолчанию. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/58077ac897.jpg

И все. Переопределили все нужные нам параметры, и теперь везде можно тыкать [[Wayfinder]], и не прописывать каждый раз одни и те же параметры. Удобно? А то!

А теперь представьте, что по какой-то причине сниппет Wayfinder (не важно по какой). Само собой удалились и все Параметры по умолчанию, в том числе и те, которые переопределели вы. А там и шаблон был указан с интуитивным названием RowTpl12321SDF, и несколько excludeDocs (2,3,4,5,7,12-34,56-77) и т.д. И как, теперь все это опять где-то искать, переопределять и т.п.?

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

Но как оказалось, есть вполне деликатное решение данной проблемы. И это — Наборы параметров. В чем их суть? Создается набор параметров, связывается с объектами MODX, и можно создавать свои параметры, или (и это главное), переопределять имеющиеся параметры связанных объектов.

Опять пример. В свой шаблон мы воткнули сниппет [[!Login]]. Смотрим результат. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/2878661175.jpg

Хотим изменить шаблон формы. Само собой нам надо изменить параметр loginTpl. Но для этого мы не будем ни редактировать этот параметр по умолчанию, не передавать его в вызов сниппета. Вместо этого мы создадим свой Набор параметров. Назовем его Site, дабы не профилировать его с ходу. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/26c865e2ee.jpg

http://modxclub.ru/uploads/images/00/00/01/2013/06/30/a1345f8b81.jpg

http://modxclub.ru/uploads/images/00/00/01/2013/06/30/54ccb75ec8.jpg

Теперь этот Набор нужно привязать к сниппету Login. Вообще связывать можно с чанками, сниппетами, плагинами и TV, при чем не с одним элементом. Потому и говорю, что не обязательно с ходу профилировать набор. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/b5fc4e7011.jpg

http://modxclub.ru/uploads/images/00/00/01/2013/06/30/9ff2930e06.jpg

http://modxclub.ru/uploads/images/00/00/01/2013/06/30/12b097df7a.jpg

http://modxclub.ru/uploads/images/00/00/01/2013/06/30/66662848b4.jpg

Все, связали со сниппетом Login. А теперь внимание! Кликаем Login, и что там видим? http://modxclub.ru/uploads/images/00/00/01/2013/06/30/5a3afb84ad.jpg

А там мы сразу видим все Параметры по умолчанию сниппета Login. И здесь же можем изменить нужные нам параметры. К примеру я изменю loginTpl. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/4dabb1f6b2.jpg

Но самое приятное не то, что мы здесь же можем параметры править. Самое приятное вот что: 1) Мы не только этот параметр видим в списке всех параметров. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/32931fbfbe.jpg

Главное — мы видим измененный параметр в отдельности, если кликнем на сам Набор параметров. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/b99ab58bd0.jpg

2) Изменив параметр сниппета Login, мы не изменили параметр в самом сниппете. Там он остался прежним. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/a469944391.jpg

А вот это уже действительно удобно. Теперь остается только в элемент передать ссылку на Набор, и все. [[!Login@Site]] Смотрим результат (только не забывайте, что WebLoginSideBar — это мой пользовательский чанк-шаблон для Login, потому кто захочет поэкспериментировать, просто написать имя этого чанка недостаточно): http://modxclub.ru/uploads/images/00/00/01/2013/06/30/f37399a5d7.jpg

А теперь в этот же набор можно добавить и другие объекты, к примеру сниппет Wayfinder. И не только переопределим его параметры, но и свой новый добавим. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/ffbabefb13.jpg

И все измененные параметры мы видим в одном месте. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/53cfb02775.jpg

При этом мы сами решаем, когда использовать эти параметры, а когда нет (то есть передавать параметр @Site объекту или нет).

В общем кому как, но на мой взгляд все это очень удобно. Хотя видимо не очень популярно, так как не смотря на то, что уже версия Revolution 2.2.5, не то, чтобы ошибки какие-то, элементарные недоработки есть. К примеру, тупо нет возможности удалить какой-либо параметр, даже свой, пользовательский. В контекстном меню пункт Редактировать есть, а Удалить — нет. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/3be22e1e46.jpg

Но это не большая проблема. Сейчас мне это не мешает, а потом наверняка доработают.

UPD: А вот с синтаксисом есть особенности. Название Набора параметров не должно следовать за вопросительным знаком. Так же нельзя указать сразу два набора параметров. Так что, если хотите вызвать с набором параметров, и еще и на лету переопределить какие-то параметры, то пишем так: [[!Wayfinder@Site?&limit=`2`&rowClass=`row`(и так далее)]]

UPD 2:Еще одна приятность: возможность восстановить изначальное значение по умолчанию, при этом это действие будет локально только для связанных с этим Набором объектов, а не затронет всю систему в целом. Вот у меня два Набора, связанных со сниппетом Wayfinder. Каждый набор использует для себя дефолтовые параметры из Wayfinder. В каждом наборе свои переопределения параметров. Но если в каком-то наборе я восстанавливаю дефолтовое значение, это восстановление касается только этого набора. http://modxclub.ru/uploads/images/00/00/01/2013/06/30/d607dab646.jpg

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

modxclub.ru

Общие параметры / pdoTools / Компоненты / docs.modx.pro

Общие параметры для сниппетов, основанных на pdoTools/pdoFetch.

Параметры выборки ресурсов

Эти параметры определяют, какие объекты будут получены.

Название По умолчанию Описание
&class modResource Класс получаемого объекта
&parents Текущий ресурс Список родителей, через запятую, для поиска результатов. Если поставить 0 - выборка не ограничивается. Если id родителя начинается с дефиса, он и его потомки исключаются из выборки.
&depth 10 Глубина поиска дочерних ресурсов от родителя.
&resources Список ресурсов, через запятую, для вывода в результатах. Если id ресурса начинается с дефиса, этот ресурс исключается из выборки.
&templates Список шаблонов, через запятую, для фильтрации результатов. Если id шаблона начинается с дефиса, ресурсы с ним исключается из выборки.
&context Ограничение выборки по контексту ресурсов.
&where Массив дополнительных параметров выборки, закодированный в JSON.
&showHidden 0 Показывать ресурсы, скрытые в меню.
&showUnpublished 0 Показывать неопубликованные ресурсы.
&showDeleted 0 Показывать удалённые ресурсы.
&hideContainers 0 Отключает вывод контейнеров, то есть, ресурсов с «isfolder = 1».
&hideUnsearchable Отключает вывод спрятанных от поиска ресурсов.
&select Список полей для выборки, через запятую. Можно указывать JSON строку с массивом, например {"modResource":"id,pagetitle,content"}.
&leftJoin Аналог SQL оператора left join
&rightJoin Аналог SQL оператора right join
&innerJoin Аналог SQL оператора inner join
&joinSequence innerJoin,leftJoin,rightJoin Порядок подключения таблиц, через зяпятую.
&sortby pagetitle Любое поле ресурса для сортировки, включая ТВ параметр, если он указан в параметре &includeTVs. Можно указывать JSON строку с массивом нескольких полей. Для случайно сортировки укажите «RAND()»
&sortdir ASC Направление сортировки: по убыванию или возрастанию.
&groupby Указывает поле, по которому группируются результаты
&having Используется, чтобы ограничить выборку сгруппированных строк с помощью условия, относящегося ко всей группе, заданной в &groupby
&limit 0 Ограничение количества результатов выборки. Можно использовать «0».
&offset 0 Пропуск результатов от начала.
&first 1 Номер первой итерации вывода результатов.
&last Автоматически, по формуле (total + first - 1) Номер последней итерации вывода результатов.
&loadModels Список компонентов, через запятую, чьи модели нужно загрузить для построения запроса. Например: &loadModels=`ms2gallery,msearch3`.
&tvFilters Список фильтров по ТВ, с разделителями AND и OR. Разделитель, указанный в параметре &tvFiltersOrDelimiter представляет логическое условие OR и по нему условия группируются в первую очередь. Внутри каждой группы вы можете задать список значений, разделив их &tvFiltersAndDelimiter. Поиск значений может проводиться в каком-то конкретном ТВ, если он указан «myTV==value», или в любом «value». Пример вызова: &tvFilters=`filter2==one,filter1==bar%||filter1==foo`. Обратите внимание: фильтрация использует оператор LIKE и знак «%» является метасимволом. И еще: Поиск идёт по значениям, которые физически находятся в БД, то есть, сюда не подставляются значения по умолчанию из настроек ТВ.
&tvFiltersAndDelimiter "," Разделитель для условий AND в параметре &tvFilters.
&tvFiltersOrDelimiter "||" Разделитель для условий OR в параметре &tvFilters.
&sortbyTV Дополнительное поле, по которому нужно сортировать результаты. Может быть указано напрямую в параметре &sortby
&sortdirTV Направление сортировки по дополнительному полю, указанному в &sortbyTV. Может быть указано напрямую в параметре &sortby
&sortbyTVType Тип сортировки по ТВ параметру. Возможные варианты: string, integer, decimal и datetime. Если пусто, то ТВ будет отсортирован в зависимости от его типа: как текст, число или дата.
&checkPermissions Укажите, какие разрешения нужно проверять у пользователя при выводе объектов.
&disableConditions Отключает специфичные для класса modResource параметры выборки.
&fenomModifiers список сниппетов-модификаторов через запятую, для подключения в Fenom. Подробности в соответствующем разделе.

Параметры шаблонов

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

Название Описание
&tpl Имя чанка для оформления ресурса. Если не указан, то содержимое полей ресурса будет распечатано на экран.
&tplFirst Имя чанка для первого ресурса в результатах.
&tplLast Имя чанка для последнего ресурса в результатах.
&tplOdd Имя чанка для каждого второго ресурса.
&tpl_N Имя чанка для N-го ресурса, например, &tpl_4=`tpl4th` установит шаблон для 4-го ресурса.
&tpl_nN Имя чанка для каждого N-го ресурса, например, &tpl_n4=`tplEvery4th` будет применено к каждому 4-му ресурсу.
&tplCondition Поле ресурса, из которого будет получено значение для выбора чанка по условию в &conditionalTpls.
&tplOperator Необязательный оператор для проведения сравнения поля ресурса в &tplCondition с массивом значений и чанков в &conditionalTpls.
&conditionalTpls JSON строка с массивом, у которого в ключах указано то, с чем будет сравниваться &tplCondition, а в значениях - чанки, которые будут использованы для вывода, если сравнение будет успешно. Оператор сравнения указывается в &tplOperator. Для операторов типа isempty можно использовать массив без ключей.
&outputSeparator Необязательная строка для разделения результатов работы.

Параметры результатов

Эти параметры дополнительно определяют, какие данные и каким способом будут выводиться.

Название По умолчанию Описание
&return chunks Определяет способ вывода результатов. См. ниже.
&fastMode 0 Быстрый режим обработки чанков. Все необработанные теги (условия, сниппеты и т.п.) будут вырезаны.
&nestedChunkPrefix pdotools_ Префикс для "быстрых плейсхолдеров", включаемых параметром &fastMode
&idx Вы можете указать стартовый номер итерации вывода результатов.
&totalVar total Имя плейсхолдера для сохранения общего количества результатов.
&includeContent 0 Включаем поле «content» в выборку.
&includeTVs Список ТВ параметров для выборки, через запятую. Например: «action,time» дадут плейсхолдеры [[+action]] и [[+time]].
&includeTVList Псевдоним &includeTVs
&prepareTVs 1 Список ТВ параметров, с файлами из источников медиа, для которых нужно сгенерировать полные пути. Если установить в «1», будут подготовлены все ТВ, указанные в &includeTVs.
&processTVs Список ТВ параметров, которые нужно обработать и вывести согласно их настроек в менеджере системы. Если установить в «1», будут обработаны все ТВ, указанные в &includeTVs. Замедляет работу.
&tvPrefix tv. у pdoResources и пусто у других сниппетов Префикс для ТВ параметров.
&prepareSnippet 1 Указывает сниппет, который принимает данные перед выводом в чанк и может их менять или добавлять
&decodeJSON Разбирает поля типа JSON вместо вывода в виде строки
&scheme -1 Схема формирования url, передаётся в modX::makeUrl(), поэтому возможные варианты нужно смотреть здесь. Особый тип uri подставляет значение uri ресурса, без запуска функции.
&useWeblinkUrl Генерировать ссылку с учетом класса ресурса.
&toSeparatePlaceholders Если вы укажете слово в этом параметре, то ВСЕ результаты будут выставлены в разные плейсхолдеры, начинающиеся с этого слова и заканчивающиеся порядковым номером строки, от нуля. Например, указав в параметре «myPl», вы получите плейсхолдеры [[+myPl0]], [[+myPl1]] и т.д.
&additionalPlaceholders Устанавливает дополнительные плейсхолдеры
&cache_key Значение системной настройки cache_resource_key для ресурсов (по умолчанию resource) или default Ключ кеширования
&cache_handler Значение системной настройки cache_resource_handler или xPDOFileCache Обработчик кеша
&cacheTime Значение системной настройки cache_resource_expires или 0 (вечный) Время жизни кеша

Способы вызова чанков

Все чанки могут иметь один из следующих префиксов:

@INLINE или @CODE. В качестве шаблона будет использован код после этого префикса.

[[!pdoResources? &parents=`0` &tpl=`@INLINE <li>{{+pagetitle}}</li>` ]]

В INLINE чанках нельзя указывать сниппеты, другие чанки или фильтры вывода через обычные теги, потому что так парсер MODX обработает их в первую очередь, и сниппет получит совсем не то, что вы хотели.

Поэтому для INLINE чанков предусмотрена замена [[+]] на {{+}} - такие теги MODX пропускает, а pdoTools при работае конвертирует их как нужно. Конечно, вы всё равно можете использовать теги MODX, если вам нужно, чтобы в чанк попала уже обработанная информация, например:

[[!pdoResources? &parents=`0` &tplFirst=`@INLINE Текущая страница: [[*pagetitle]]` &tpl=`@INLINE <p>{{+id}} - {{+pagetitle}}<p>` ]]

@FILE. Вместо чанка из базы данных используется содержимое файла. Путь до файла указывается в систеной настройке pdotools_elements_path. Имя файла должно быть с расширением .tpl или .html.

[[!pdoResources? &tpl=`@FILE fileBasedRow.tpl` ]]

@TEMPLATE. Указывается идентификатор или имя шаблона. Если пусто - для каждого ресурса будет использован его собственный шаблон.

[[!pdoResources? &tpl=`@TEMPLATE 10` ]]

@CHUNK. Аналогично простому указанию имени чанка, оставлено для совместимости со сторонними сниппетами.

[[!pdoResources? &tpl=`@CHUNK tpl.Resource.row` ]] [[!pdoResources? &tpl=`tpl.Resource.row` ]]

Подробнее про возможности pdoParser можно прочитать в соответствующем разделе.

Возвращаемые значения

pdoTools умеет возвращать данные в разном виде, в зависимости от параметр &return. В основном это используют сами сниппеты для внутренних нужд, но вы можете указывать &return в pdoResources:

[[!pdoResources? &parents=`0` &return=`json` ]]

docs.modx.pro

Как не надо расширять MODX-процессоры / modx.pro

В MODX-2.4.0 появился новый процессор updatefromelement.class.php by Argnist, пришедший на замену обычному процессору updatefromelement.php. Заменять non-classed процессоры конечно дело хорошее, но делать надо это крайне осторожно и обдуманно.

Сразу уточню, что этот процессор используется для обновления параметров элементов (типа шаблонов, сниппетов и т.п.)

Так вот, в чем же неприятность данного процессора? А в том, что расширяет он процессор update.class.php, который обновлять должен объекты с классом modPropertySet, а на практике у нас получается, что новый процессор обновляет чаще элементы типа modTemplate, modSnippet и т.п.

Рассмотрим эту проблему детальней. Суть в том, что когда мы редактируем какой-то элемент (шаблон, к примеру), создаем или редактируем в нем параметры, то эти параметры для сохранения отправляются именно на этот процессор. И что там происходит? Там на самом деле выполняется очень сложная (с точки зрения логики) задача — Есть сам элемент (modTemplate), а есть наборы параметров (modPropertySet). (Есть еще для них связка modElementPropertySet, но она нам сейчас не интересна). Так вот, реально обновлять modPropertySet нужно только в том случае, если мы обновляем именно отдельный объект набора параметров. А вот когда у нас не выбран набор параметров, тогда обновляется именно объект самого элемента modTemplate. А как мы посмотрели выше, процессор этот обновляет объекты с классом modPropertySet. А где он здесь, если мы его не выбрали? Как бы и нигде. Но на самом деле есть — первый же попавшийся набор параметров… Почему так происходит? На самом деле тут наследие от давнего старого минуса xPDO — это отсутствие контроля типов переменных для первичных ключей. К примеру, попробуйте выполнить так: $o = $modx->getObject('modResource', 'любая произвольная строка'). Как вы думаете, получите вы таким образом объект? К сожалению, да. Опять-таки — первый попавшийся. А вот если вот так сделать, то уже не будет: $o = $modx->getObject('modResource', (int)'любая произвольная строка'). То есть строка будет преобразована в 0, а с этим id вряд ли у вас документ есть. Так вот, когда мы запрос шлем на сервер, то там такие данные передаются: Самое интересное там для нас — id: По умолчанию. Это еще одна бага озвученного процессора, так как там проверка идет для Default, которого просто нет, когда язык панели ru.

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

Из всего написанного выше можно извлечь главное правило: обновляться должен только главный объект, и только с ним уже можно обновлять сопутствующие объекты. В данном же процессоре логика была типа «можно обновить дополнительный объект шаблона без сохранения главного объекта наборов параметров, если они не были указаны», что как бы не соответствует реалиям. В виду этого здесь видится только два основных решения: 1. Или плодить дубли кода в двух отдельных процессорах (для обновления параметров один, а для обновления объекта — другой). 2. Или в процессоре вызывать еще один процессор (что тоже достаточно логично).

Но я попробовал все-таки модернизировать текущий процессор, чтобы он и параметры объекта обновлял, и наборы параметров (в зависимости от того, указаны они или нет). Суть его сводится к тому, что если не указан набор параметров, то $this->classKey меняется на класс обновляемого элемента, что переводит процессор из редактора набора параметров в редактор элемента. Вот код gist.github.com/Fi1osof/ff3ea018841b1bb1f99b

Я не стал его слать пуллреквестом, так как код не очень чистый и без локализаций. Виталий, раз ты это все делал, значит боле менее понимаешь как и что там работает. Потестируй и доработай свой процессор, плиз.

UPD: Поступил переводот Andreas Wettainen aka mrhaw. Большое ему спасибо за это! Отправил PR. Райну написал. Надеюсь скоро примут и опубликуют.

modx.pro


Prostoy-Site | Все права защищены © 2018 | Карта сайта