Comments 3
>>Кроме неудобства, что данное решение не входит в базовую поставку CMS
А ваше разве входит?
>>оно еще и обладает, на мой взгляд, слишком длинным именем
Можно переименовать как угодно.
>>не говоря уже о том, что приходится держать открытым RTFM
По-моему очень просто зпомнить все параметры. Их совсем не много.
А если не нравится длинная строка, можно было бы написать сниппет, который вызывался бы примерно так:
[[fastField?opt=`10.pagetitle`]]
Городить такай плагин как у вас по-моему лишнее. Но как пример гибкости MODX сойдёт.
А ваше разве входит?
>>оно еще и обладает, на мой взгляд, слишком длинным именем
Можно переименовать как угодно.
>>не говоря уже о том, что приходится держать открытым RTFM
По-моему очень просто зпомнить все параметры. Их совсем не много.
А если не нравится длинная строка, можно было бы написать сниппет, который вызывался бы примерно так:
[[fastField?opt=`10.pagetitle`]]
Городить такай плагин как у вас по-моему лишнее. Но как пример гибкости MODX сойдёт.
Помню эту заметку. И вот появился повод к ней вернуться.
Городить такай плагин как у вас по-моему лишнее.Это не просто плагин, а ажно переопределение родного парсера. Сейчас вот обкатываю модуль мониторинга (чуть позже заметку опубликую), и неотъемлемая часть его — это переопределение MODX-парсера (чтобы перехватить моменты получения элементов дабы замерить тайминги). Тут вот как раз подвернулся сайт подопытный, на производительность проверить. Ставлю туда модуль, а он не работает. Потому как я предусмотрительно прописал проверку текущего используемого парсера (мой вешается плагином, а не жестко в систему прописывается). И вот всего из-за одного дополнительного поля система ломается. Как-то так.
Sign up to leave a comment.
Добавляем новый тег в MODX Revolution