Поставил DLLastView. Если у сниппета ставлю чекбокс Анализировать DocBlock и нажимаю сохранить, то страница перегружается и чекбокс снова не активен становится

ну так и должно быть

оно первый раз тянет инфу из докблока а дале ты уже меняй описание или события если плагин сам

иначе б оно затирало

А что означает этот DocBlocks?

А если нужно чтобы DLLastViews и учитывал страницу и выводил на ней последние просмотренные. Получается два вызова DLLastViews?

А что означает этот DocBlocks?

DocBlock это инфа об елементе которая вот в начале http://joxi.ru/LmG1JexCw1GNxA тоесть можна поставив галку анализировать Doc Block автоматом проставить события

А если нужно чтобы DLLastViews и учитывал страницу и выводил на ней последние просмотренные. Получается два вызова DLLastViews?

Поидее да один раз из mode = register второй раз mode = show

можно обработку register и show сделать в одном вызове, а не через switch. Тогда один раз можно вызывать

вообщем спасибо, что в столь поздний час помогаете советом )

можно обработку register и show сделать в одном вызове, а не через switch. Тогда один раз можно вызывать

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

ну вообще можна еще сделать mode all и дописать к каждому кейсу

$template = '@CODE:' . file_get_contents(dirname(__FILE__) . '/templates/home.tpl'); $outTpl = $tpl->parseChunk($template, $data);

Никогда не понимал этих загадочных конструкций

Как и то, зачем папку и сам компонент называть разными именами:)

это к чему

Да там, из нового модуля редиректов

$template = '@CODE:' . file_get_contents(dirname(__FILE__) . '/templates/home.tpl'); $outTpl = $tpl->parseChunk($template, $data);

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

Зачем сочинять @code и file_get_contents постоянно, когда можно просто @FILE:home :)

Ну уже наверно лет сто можно:)

Безобразие

Эта конструкция кочует из модуля в модуль аналогично event/Event и e= & $modx->Event :)

модули копипастом обычно и пишутся

Кто нибудь разбирается в html video? Я на странице использую его, если открывать или обновлять страницу работает, а при переходе с других страниц сайта на ту что с видео, не открывается. Возможно дело в ajax подгрузке страницы, незнаю куда компать.

Эта конструкция кочует из модуля в модуль аналогично event/Event и e= & $modx->Event :)

А разве где-то есть документация по правильному написанию модулей и плагинов?

А разве где-то есть документация по правильному написанию модулей и плагинов?

Речь не про модули/плагины, а про использование класса DLTemplate)

Так про него тоже не особо та написано

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

Ну а с DLTemplate удобно, да.

не доросла ево до того, чтобы лепили как положено

А есть пример того как положено?

нету, я же и говорю - не доросла

К слову, что-то я не нашёл в ядре, может плохо искал: есть какая-то API-функция чтобы в своём плагине внутри админки добавить скрипты и стили в head?

🤠

конечно нет

По-моему очень частая задача в своих плагинах и кастомных tv

эта задача частично решена в 2.0, но до полноценного решения далеко

Эта задача очень давно как-то решена в ManagerManager https://github.com/evolution-cms/evolution/blob/1.4.x/assets/plugins/managermanager/utilities.inc.php#L241

это костыль, а не решение

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

потому что в ядре это невозможно сделать прямо вот сейчас

То есть только через js, а это костыль?

нормально в смысле сделать, а не вкостылить событий для добавления скриптов

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

Тут событий недостаточно. Иногда надо не в плагине делать, а в кастомном tv. там событий то нет

ну все тогда, никак

Тут событий недостаточно. Иногда надо не в плагине делать, а в кастомном tv. там событий то нет

в рево с кастом тв обычно еще и плагин идет в комплекте как раз для этого

Ну так себе затея.

если руками ставить, то да

а с инсталлятором разницы нет

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

Это, конечно, хоть какое-то решение, но больше нравится идея с системным api-методом.

мне тоже, но увы (:

господа, а evo 2.0 уже можно в проектах использовать ?

да

зачем

тсс

богов найдут - сообщат

🤔

нет, использовать-то можно, но это же альфа

Вот. Можно? Можно.

для верстальщиков там ничего нового нет

богов найдут - сообщат

Зачем их искать? Он же один

Можно, кто же вам запретит )

Так про него тоже не особо та написано

Ну про @code в нем "написано" там же, где и про @file, так что если нужен именно файл, то намного логичнее и использовать @file :) я только про это :)

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

Это когда система спроектирована с определенным заделом на масштабы применения, а modx совсем не про это был.

Поэтому делать можно так как удобно и стараться не пересекаться с текущими обновлениями основных версий

Нет понятия костыль в системе, где основа на костылях.

Ну про @code в нем "написано" там же, где и про @file, так что если нужен именно файл, то намного логичнее и использовать @file :) я только про это :)

но ты забыл что когда это было написано, то файлы должны были лежать в assets/templates и иметь расширение html

не доросла ево до того, чтобы лепили как положено

Моя заготовка не устраивает? Можешь написать, что не так, чтобы был фен-шуй? https://github.com/0test/simpleModule

К слову, что-то я не нашёл в ядре, может плохо искал: есть какая-то API-функция чтобы в своём плагине внутри админки добавить скрипты и стили в head?

Хорошо что нет, а то бы добавляли в head скрипты

вам не угодить

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

Возможно, что-либо удобное для работы с ajax, кардинально меняющее скорость написания раза в 2-4

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

ну он чуток одобней $modx->parseText и $modx->parseChunk можна юзать @CODE в parseChink такое не факт что пройдет

ну он чуток одобней $modx->parseText и $modx->parseChunk можна юзать @CODE в parseChink такое не факт что пройдет

А зачем использовать parseChunk и подобное если мы не в режиме фронтенда где это обосновано. То есть зачем использовать в модулях чанки или файлы типа tpl и дополнительно парсить их.

Если конечно модуль не связан жестко с фронтендом сайта

и какие-либо чанки могут повлиять на работу модуля

Затем что это заготовка. И хер знает что я буду делать на ее основе завтра/через неделю.

Вас никто не осуждает или заставляет делат по другому, тут вопрос стоит простой, какие преимущества дает дополнительная "прокладка" в виде парсера файлов. На вид это 1 функция str_replace('[+placeholder+]','value',file_get_contents('file')), на вскидку.

Ну так я преимущества и описал же. Универсальность.