А создание плагина на основе какого-то файла описания — не такая уж и глупая мысль.
Я знаю. У меня на в комнате на стенке висит доска для маркеров, на ней нарисована архитектура «саморасширяемой» livestreet (вплоть до UML-кодогенерации).
Если бы это было глупо, я бы про это не говорил. Но это настолько далекое будущее…
Иначе будете терять почту далеко не только идущую в нашу сторону.
Трындят. Я еще не встречался с отправкой в СПАМ только из-за того, что их, видите ли, формат не устроил.
Это все равно, что браузеры сейчас перестанут показывать не 100% валидные сайты, мол, пусть формируют HTML по стандартам. 98% интернет отвалиться автоматически.
P.S. По поводу выявления несовместимостей ДО активации плагина, я предчувствовал негодование. Поэтому в readme.txt содержится вот эта строка:
Хотя ее использование и не прописано в коде системы плагинов. Честно говоря, не знаю нужно ли это. Можно, конечно, довести систему до того уровня, когда LS будет на основе переданного XML \ UML сама писать плагины… Только зачем?
"… не всегда остается рабочий после минимизации..." -моя фраза заканчивалась словами "… на максимальной степени сжатия". В той конфигурации, которая использована сейчас все Ок. А вообще, вопрос сжимаемости CSS скорее не к LS, а к верстальщикам шаблонов (css меняется в шаблонах гораздо больше, чем js).
По поводу блоков: там был уже предусмотрен механизм создания блока из плагина — для этого нужно добавить параметр блока 'plugin'. Посмотри как это реализовано в самом Smarty-плагине:
Я там в @733 только немного пофиксил под новую функцию.
По поводу SetTemplate(), если я тебя правильно понял, то ты говоришь про это:
Или нет?
По меню посмотри @732 ревизию. Вставил минимум того, что планирую реализовать по menu-контейнерам (но это уже, наверное в 0.5 пойдет) =) Ту проблему, которую ты описал, косячно немного, но решает.
Основная идея в том, что система будет воспринимать параметр menu в первую очередь как название контейнера, а уж если такого нет — искать туда файл. Если контейнер определен, то Smarty подтянет на место меню заранее подготовленное меню (рендериться при Shutdown`е модуля Viewer).
Для добавления плагин меню, нужно в шаблоне из плагина указать название контейнера, например menu='my_plugin_blog', а в функции Init() плагина передать название шаблона в этот контейнер. Например,
Про ресурсы почитаю. Никогда не сталкивался. Но на вскидку скажу, что это не совсем то — здесь идет речь о возможности извлечения шаблонов не из файловой системы, а из других источников (как описано в примере — из базы данных).
Ситуация с меню вообще отдельная (достаточно сложная с архитектурной точки зрения). Обсуждалось неоднократно.
Я лично вижу выход только в создании некой абстракции (на подобие Zend`овских ViewsHelper) — вопрос не только в том, как добавить новое меню, а как например добавить новый пункт в старое, не заменяя его полностью? (ведь плагинов, которые пожелают это сделать может быть несколько)…
У тебя есть какие-нибудь предложения по этому поводу?
Просто getTemplatePathPlugin возвращает путь к директории со скином. Если у нас скин тот же самый new, но есть несколько различных вариантов его оформления — можно складывать эти шаблоны по директория /skin/new/my_format/index.tpl и вызывать как
Не вижу логики.
У нас в плагине предусмотрены шаблоны плагинов default, new, develper. На сайте используется скин new, а я указываю в плагине выводить шаблоны не new, а developer… Я правильно понял идею? Зачем такое может понадобиться?
при этом в папке default должны размещаться шаблоны, которые будут использованы плагином в том случае, если текущий skin сайта в плагине не предусмотрен
Для обслуживания этого процесса в ActionPlugin есть функция getTemplatePathPlugin(), есть еще Plugin::GetTemplatePath($sPluginName) — обе эти функции возвращают адрес директории с шаблонами плагина с учетом наличия (либо не наличия) нужного скина.
Проблема конфликтности плагинов классическая для всех плагин-систем. Вопрос а) к пользователю — что ему больше нужно, б) к разработчиком — писать наиболее гибко (чем более гибко и не назойливо мой плагин, тем более востребованным он будет).
Грубо говоря, я делаю плагин, который добавляет номер телефона в инфо о пользователи. А еще нужен скайп, вконтакте и т.д. Будет ли мой плагин востребован — ровно до тех пор, пока не будет заменителя. И когда-то найдется разработчик, который напишет легко кастомизируемое пользователем расширение, с произвольным расширением данных…
Тут нужно понимать, что задача разработчиков предоставить механизм, а не вкручивать мозги разработчикам =)
Mapper нельзя делегировать, мепперы подключаются в каждом модуле отдельно, поэтому для делегирования меппера нужно переопределить тот код в модуле, который отвечает за подключение меппера.
Без знания ООП тебе будет сложновато разобраться. Дождись лучше конкретного примера, сделаешь по аналогии. Или расскажи, что ты меняешь — я этот случай проанализирую в статье.
Что ты имеешь ввиду? Режим «Предпросмотр» и так уже реализован…
ли будет дополнениям безболезненно внедряться в файлы уже изменённых шаблонов
Странная постановка на самом деле.
а) «внедряться» в файлы можно только путем Viewer_Assign() с последующим выводом этой переменной в шаблоне. Описанный в статье механизм делегирования означает полную замену, а не «внедрение»;
б) «уже измененных шаблонов» — звучит равно как «Может ли хирург вырезать аппендицит, учитывая что структура тела была изменена внеземной формой радиации?»
Идея классная, реализация тоже. Хотя
тут больше подойдет live streaming (типа Твиттера).
Я знаю. У меня на в комнате на стенке висит доска для маркеров, на ней нарисована архитектура «саморасширяемой» livestreet (вплоть до UML-кодогенерации).
Если бы это было глупо, я бы про это не говорил. Но это настолько далекое будущее…
Трындят. Я еще не встречался с отправкой в СПАМ только из-за того, что их, видите ли, формат не устроил.
Это все равно, что браузеры сейчас перестанут показывать не 100% валидные сайты, мол, пусть формируют HTML по стандартам. 98% интернет отвалиться автоматически.
2. Отсутствие текстовой версии — не повод для того, чтобы делать письмо СПАМом, какой логикой они пользуются не совсем ясно.
3. Письма иногда попадают в СПАМ и на других сервисах. С этим ничего не сделаешь — это недоразвитость систем СПАМ-фильтров.
Хотя ее использование и не прописано в коде системы плагинов. Честно говоря, не знаю нужно ли это. Можно, конечно, довести систему до того уровня, когда LS будет на основе переданного XML \ UML сама писать плагины… Только зачем?
В readme.txt система читает только первые строки.
Остальное содержание можно писать как угодно.
Я там в @733 только немного пофиксил под новую функцию.
По поводу SetTemplate(), если я тебя правильно понял, то ты говоришь про это:
Или нет?
По меню посмотри @732 ревизию. Вставил минимум того, что планирую реализовать по menu-контейнерам (но это уже, наверное в 0.5 пойдет) =) Ту проблему, которую ты описал, косячно немного, но решает.
Основная идея в том, что система будет воспринимать параметр menu в первую очередь как название контейнера, а уж если такого нет — искать туда файл. Если контейнер определен, то Smarty подтянет на место меню заранее подготовленное меню (рендериться при Shutdown`е модуля Viewer).
Для добавления плагин меню, нужно в шаблоне из плагина указать название контейнера, например menu='my_plugin_blog', а в функции Init() плагина передать название шаблона в этот контейнер. Например,
Аналогичным вызовом, можно заменить существующее меню своим.
Я лично вижу выход только в создании некой абстракции (на подобие Zend`овских ViewsHelper) — вопрос не только в том, как добавить новое меню, а как например добавить новый пункт в старое, не заменяя его полностью? (ведь плагинов, которые пожелают это сделать может быть несколько)…
У тебя есть какие-нибудь предложения по этому поводу?
У нас в плагине предусмотрены шаблоны плагинов default, new, develper. На сайте используется скин new, а я указываю в плагине выводить шаблоны не new, а developer… Я правильно понял идею? Зачем такое может понадобиться?
Для обслуживания этого процесса в ActionPlugin есть функция getTemplatePathPlugin(), есть еще Plugin::GetTemplatePath($sPluginName) — обе эти функции возвращают адрес директории с шаблонами плагина с учетом наличия (либо не наличия) нужного скина.
Грубо говоря, я делаю плагин, который добавляет номер телефона в инфо о пользователи. А еще нужен скайп, вконтакте и т.д. Будет ли мой плагин востребован — ровно до тех пор, пока не будет заменителя. И когда-то найдется разработчик, который напишет легко кастомизируемое пользователем расширение, с произвольным расширением данных…
Тут нужно понимать, что задача разработчиков предоставить механизм, а не вкручивать мозги разработчикам =)
Mapper нельзя делегировать, мепперы подключаются в каждом модуле отдельно, поэтому для делегирования меппера нужно переопределить тот код в модуле, который отвечает за подключение меппера.
Без знания ООП тебе будет сложновато разобраться. Дождись лучше конкретного примера, сделаешь по аналогии. Или расскажи, что ты меняешь — я этот случай проанализирую в статье.
Что ты имеешь ввиду? Режим «Предпросмотр» и так уже реализован…
Странная постановка на самом деле.
а) «внедряться» в файлы можно только путем Viewer_Assign() с последующим выводом этой переменной в шаблоне. Описанный в статье механизм делегирования означает полную замену, а не «внедрение»;
б) «уже измененных шаблонов» — звучит равно как «Может ли хирург вырезать аппендицит, учитывая что структура тела была изменена внеземной формой радиации?»