cotonti.com : Редактируемые шаблоны https://www.cotonti.com Laatste forum onderwerpen Cotonti en Mon, 06 Oct 2025 05:47:52 -0000 Macik На всякий случай освежу тему... Вдруг кто не в курсе - с версии шаблонизатора 2.7.9 (вошла в выпуск Siena 0.9.11) добавлена функция компиляции (загрузки) шаблона из строковой переменной.

 

]]>
Vr, 19 Okt 2012 23:11:06 -0000
Sergey Я, например, нашел важным дать возможность вставлять страницы вместо слотов, получается так: http://www.cotonti.com/datas/users/slot_205.png

 

]]>
Vr, 08 Jun 2012 17:49:58 -0000
Sergeich Опять же, если сайт сопровождает маломальски подготовленный вебмастер, то нет никакого сомнения, что у него есть инструменты для фтп-доступа к файлам сайта и наверняка он пользуется каким-то своим набором инструментов разработчика. Так зачем ему мучаться в вебинтерфейсе, когда проще и удобнее всё делать своими инструментами?  

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

]]>
Vr, 08 Jun 2012 06:18:34 -0000
Macik Ух, тема находит отклик.  :)

 

Veter:

Я лично двумя ногами и руками «за!» Грамотно продуманная и реализованная система «„Виртуальных“ шаблонов» поднимет потенциал Котонти по сравнению с другими ЦМС, даже думать нечего. И задачу эту, господа, нужно ставить на первый план.

Один важный момент для ВШ: в админке обязательно должна быть страничка со списком всех созданных ВШ сайта.

Задачу эту надо сначала полностью формализовать. Для этого и создал тему - услышать о вариантах применения идеи и вариантах ее развития. Что касается «в админке» - я бы не засовывал это в «стандартную поставку», а делал бы плагином/модулем, тогда не проблема в админке плагина сделать необходимый функционал. Для страниц шаблонов, например, можно выделять отдельную фиксированную категорию страниц. 

 

Sergeich:

Был плагин для Седитио, который позволял редактировать шаблоны через админку, особой популярностью не пользовался. Вообще, нужно понимать, что CMS не для дизайнеров и програмёров делается, а для управления сайтом обученными "секретаршами".
... 
Отсюда вывод - полезность фичи стремится к нулю.  

Тут зависит от того,

1. кому и для чего делается сайт. Часть этой мысли раскрыл Veter. Делаешь сайты для секретарш - не включай этот модуль вообще. Делаешь для фирмы с «веб-админом» дай им возможность (испортит - сам разгребет или тебе консультацию оплатит). Делаешь под себя - строй хоть замок, особенно если инструмент удобный.

2. не надо эту идею рассматривать узко, как редактор шаблонов (это может быть одной из функций). На текущей стадии (обсуждение) вообще непонятно будет ли что-то реализовано и если будет, то что. :) Я смотрю на этот «прообраз» шире. Это может быть просто «Ш-парсер» дополнительной разметки в текстах страниц с простой подстановкой. Это может быть свой шаблонизатор с разметкой и подгрузкой шаблонов (wiki-style). Может быть что-то еще.

Trustmaster:

Вопрос первый: какова частота обращения БД ...

Ответы, опять же, зависят от того, что планируется реализовать - хранение некоторых (coTemplate) шаблонов в БД или некий абстрактный парсер тегов на страницах с возможностью сделать вставку текста из другой страницы (микрошаблоны). Поэтому отчечая на вопросы буду придерживаться начальной идеи - подгрузки отдельных coTemplate шаблонов из текстовой переменной (не важно из БД или нет). 

1. В перспективе надо стремиться к минимуму. в идеале загрузили единожды после изменения, закешировали в файлах кеша, потом пользуем от туда. В общем как и сейчас реализовано. Что касается реальной нагрузки - тут как всегда будет зависеть от способа применения. Если разработчик использует 100 шабонов для компоновки одной страницы - он сам себе враг.

2. Ответ очевиден. Если БД ложится - сайт не работает. :) Если речь о том, что можно потерять из БД шаблоны - то бекап никто не отменял.

3. Ни о каком WYSIWYG и речи быть не может (разве кто-то сейчас шаблоны в WYSIWYG делает?). Только plain-text, только хардкор. :) Речь была о том, что при просмотре готового (сохраненного) шаблона его можно было бы увидеть почти в «готовом» виде.
Если мы не привязываемся к coTemplate, а развиваем идею «Ш-парсер», то редактор может быть каким угодно, лишь бы был удобен для набора той разметки которую будет понимать наш парсер.

4. Да, узкое место. Но во-первых мы же не ведем речь о переносе всех шаблонов в БД (а узко специализированные могут и не требовать callbacks), во-вторых это можно завязать на систему прав. Делаешь шаблон сам или  доверяешь стороннему вебмастеру - «поставь галочку» расширенных прав.

 

Подытоживая свое ви́дение:

  • идея мной была высказана с целью найти отзыв и для обсуждения заинтересованными людьми.
  • я не призываю это «ставить на первый план». Считаю, что в штатной поставке Котонти «такому» делать нечего (по крайней мере пока) и данная функциональность должна быть реализована в виде отдельного модуля/плагина.
  • и не дай Бог напрягать «этим» основных разработчиков. У них и без этого работы хватает (есть и план развития CMS и текущие доработки). Если наберется заинтересованный коллектив - можно обсуждать детали и пробовать свои силы.
  • то, что тема так или иначе находит отклик меня радует. Еще больше радует, что у каждого свое видение темы «шаблонов» и ее применения. (для этого тема и создана).
]]>
Vr, 08 Jun 2012 00:36:03 -0000
Nik Samokhvalov

Отсюда вывод - полезность фичи стремится к нулю.  

У меня другой вывод: у вас мало опыта. Не обижайтесь, но это так. Заказчики бывают разные, так же как и сайты. Просто, видимо вам не довелось поработать над проектом уровня «сайт-портал», на котором работает не просто секретарша, а более-менее серьёзный веб-мастер, а иногда и команда сотрудников. Такие порталы не будут занимать лидирующие места с шаблонным представлением контента — для них нужны нестандартные решения.

Верно, навряд ли ВШ станут популярными и найдут широкое признание среди комьюнити. ВШ — это функция для редких, но глобальных проектов. Как верно заметил однажны Влад, Котэ — фреймворк медиа-класса, правда его можно «сточить» и под эконом-класс. ВШ, на равне с другими полезными фичами, помогут укрепить статус медиа-класса Котонти.

Кстати, от секретарш можно будет выключать ВШ. Это же так просто :)

P. S. «CMS не для дизайнеров и програмёров делается, а для управления сайтом обученными "секретаршами"» — ой не согласен, не согласен. Не губите потенциал Котонти, в мире есть много сайтов на ЦМС-ках, к которым секретарш вовсе не подпускают. Или не пропускают дальше уровня «Добавить страницу».

P. P. S. Прежде чем делать выводы, старайтесь просматривать ситуации не только со «своей головы». И вы сразу же увидите кучи проблем и перспектив. Спасибо :)

Добавлено 6 минут спустя:

Trustmaster,

1) Не совсем понял суть.

2) Редирект на страницу с ошибкой. Без БД, помоему, сейчас никуда.

3) Это да, ВИЗИВИГ лучше не юзать.

4) Можно пример?..

]]>
Thu, 07 Jun 2012 19:35:03 -0000
Trustmaster Вопрос первый: какова частота обращения БД при загрузке шаблонов из оной? Для справки: при генерации среднестатистической страницы с плагинами вызывается 3-7 шаблонов.

Вопрос второй: что происходит с сайтом, если БД ложится (у многих хостеров такое случается).

Вопрос третий: как вы себе технически представляете редактирование в режиме WYSIWYG страницы, состоящей из 7 разных шаблонов и сотни тегов (да ещё и с подстановкой данных на лету). Я это даже с использованием технологий HTML5 ContentEditable и MVC-фреймворков на JavaScript типа Meteor или Backbone представляю не очень.

Вопрос четвёртый: согласны ли вы с тем, что при передаче третьим лицам прав на редактирование таких шаблонов придётся отказаться от callback-функций шаблонизатора.

]]>
Thu, 07 Jun 2012 19:27:10 -0000
Sergeich Был плагин для Седитио, который позволял редактировать шаблоны через админку, особой популярностью не пользовался. Вообще, нужно понимать, что CMS не для дизайнеров и програмёров делается, а для управления сайтом обученными "секретаршами". Шаблоны на действующем ресурсе вы меняете от силы пару раз в год. Среднестатистического заказчика лучше вообще к шаблонам не подпускать близко, ибо шаловливые ручонки могут на раз-два запороть сайт. Отсюда вывод - полезность фичи стремится к нулю.  

]]>
Thu, 07 Jun 2012 16:17:37 -0000
Nik Samokhvalov

Дык. Напишите, пожалуйста, подробнее: ваш пример использования, в котором бы подошел «редактируемый шаблон», как сейчас решаете эту задачу (в виду отсутствия такой функциональности). 

Привет!

Сейчас решается задача примерно так: плагины. Либо статично прописывать условия, либо проверять перед выводом, например, страницы, есть ли в экстраполе БД имя шаблона. Шаблон, разумеется, физический.

Я лично двумя ногами и руками «за!» Грамотно продуманная и реализованная система «„Виртуальных“ шаблонов» поднимет потенциал Котонти по сравнению с другими ЦМС, даже думать нечего. И задачу эту, господа, нужно ставить на первый план.

Один важный момент для ВШ: в админке обязательно должна быть страничка со списком всех созданных ВШ сайта.

]]>
Thu, 07 Jun 2012 11:33:37 -0000
McDuck Вы верно уловили суть моей фантазии :)

]]>
Di, 05 Jun 2012 05:24:02 -0000
Macik  

Если говорить о той, концепции, о кторой я в начале, то мной предложен «простой» вариант, только возможность подгрузить тело страницы как шаблон (теги на страинце-шаблоне при его просмотре не парсятся (не происходит замены их содержимым)).

А выпредлагаете, как я понял, расширеный вариант, когда при просмотре этой страницы-шаблона теги будут «обработаны» перед выводом. 
Т.е. о том, чтобы была возможность на [любой] странице запользовать произвольный тег, вызвав подстановку его содержимого.
Я правильно мысль уловил?

Тут трудности в том, что сейчас нет прямой зависимости тега и содержимого (которым он будет наполнен), т.к. все плагины вызываются не через теги, а через хуки, да к тому же «пишут» свой вывод в глобальный «поток» шаблона $t. Вот если придумать привязку {Тег} → содержимое...

 
]]>
Di, 05 Jun 2012 00:16:37 -0000
McDuck #34541 Macik: Мне казалось, что если изменился сам шаблон, то кеш автоматически обновиться. 

Глянул в coTemplate: вроде есть проверка на дату файла, и если дата шаблона «свежее» кеша - кеш должен обновиться.

p.s. А можно поподробнее про вариант использования «фичи» разработчиками тем? Хочется понять примерный алгоритм, по шагам.

Простейший пример:

<!-- BEGIN QUICK_TEMPLATE -->
{TAG_1}
...
{TAG_N}
<!-- END QUICK_TEMPLATE -->
...
<p><input  type="text" name="quicktemplate" ></p> <!-- Source of  QUICK_TEMPLATE -->
<input type="submit" name="Submit" value="Refresh" /></p>
...
Видим вывод шаблона нужного участка, под ним его исходный код ]]>
Ma, 04 Jun 2012 09:00:46 -0000
Macik #34566 Wilder:
#34521 esclkm:

переодически хочется использование шаблонизатора из текстовой переменной

Да, да! Буквально вчера в очередной раз столкнулся с подобным желанием :-)

Дык. Напишите, пожалуйста, подробнее: ваш пример использования, в котором бы подошел «редактируемый шаблон», как сейчас решаете эту задачу (в виду отсутствия такой функциональности). 

Хочется собрать больше информации о возможных применениях данной идеи. Понять возможные «узкие» места.

 

]]>
Ma, 04 Jun 2012 08:50:34 -0000
Wilder #34521 esclkm:

переодически хочется использование шаблонизатора из текстовой переменной

Да, да! Буквально вчера в очередной раз столкнулся с подобным желанием :-)

]]>
Ma, 04 Jun 2012 07:34:35 -0000
Macik #34537 McDuck:

ИМХО как «костыль» сохранение на диск содержимое шаблона в неком временном файле не сработает, т.к. при подгрузке включаемого файла стандартными средствами шаблон не изменится до обновления кэша.

Мне казалось, что если изменился сам шаблон, то кеш автоматически обновиться. 

Глянул в coTemplate: вроде есть проверка на дату файла, и если дата шаблона «свежее» кеша - кеш должен обновиться.

p.s. А можно поподробнее про вариант использования «фичи» разработчиками тем? Хочется понять примерный алгоритм, по шагам.

]]>
Za, 02 Jun 2012 23:04:17 -0000
McDuck Фича интересная была бы для разработчика тем, причем не столько для визуальной оценки дизайна страницы (HTML каркас мало информативен), столько для оптимизации отдельных его деталей.

ИМХО как «костыль» сохранение на диск содержимое шаблона в неком временном файле не сработает, т.к. при подгрузке включаемого файла стандартными средствами шаблон не изменится до обновления кэша.

]]>
Za, 02 Jun 2012 21:03:02 -0000
Macik Если на пальцах - сейчас все шаблоны  находятся в физических файлах на диске, что бы отредактировать надо загрузить файл, изменить и записать обратно. Мысль поста в том, чтобы обсудить возможность создавать шаблон как страницу. Т.е. создаем обычную страницу и размещаем на ней содержимое шаблона. Т.о. мы имеем возможность создать/радактировать шаблон через обычный web-интерфейс польностью по аналогии со страницой (не нужен доступ к файлам).  

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

 

#34532 Fox: 

Пример посмотрел там только ТПЛ теги одним словом ниче не понял

Там не только TPL теги, на них как раз смотреть не надо, там главное оформление этих тегов (шрифт, цвета, блоки, и т.п., т.е. то, за что отвечает HTML в шаблоне).

Надеюсь, чуть понятнее объяснил...

 

 

]]>
Za, 02 Jun 2012 20:11:00 -0000
Fox Пример посмотрел там только ТПЛ теги одним словом ниче не понял

]]>
Za, 02 Jun 2012 19:33:36 -0000
Moool13 Эмм.. Два раза прочитал и не понял..

]]>
Za, 02 Jun 2012 14:41:26 -0000
esclkm переодически хочется использование шаблонизатора из текстовой переменной

]]>
Za, 02 Jun 2012 14:14:52 -0000
Macik  

Идея, если коротко, иметь возможность загружать необходимые шаблоны из содержимого страницы (речь не о переносе всех шаблонов в БД, а о более гибком варианте использования некоторых шаблонов для страниц или плагинов).
 
Для чего? Для возможности гибкой (динамической) настройки отображения страниц (или их частей) в зависимости от категории/параметров/возможно содержимого конкретной страницы. Может быть актуально для сайтов-каталогов товаров, например. 
 
В чем удобство:
  •  удобный способ редактировать шаблон (не надо обращаться к файловой системе, используя FTP/SSH клиенты)
  • возможность дать доступ на редактирование стороннему пользователю, не имеющему доступа к файловой системе (администратору заказчика)
  • иметь возможность визуального контроля отображения шаблона (если используется HTML парсинг на странице) - см.пример
Заглянул в coTemplate и судя по беглому анализу просто подсунуть ему текст шаблона не получится, т.к. есть привязка к именам файлов на основе которых
создаются файлы кэша.
Как «костыль» можно сохранять на диск содержимое шаблона в неком временном файле, и оттуда уже его подгружать стандартными средствами. 
 
Пока реализация мне интересна с теоретической точки зрения.
Поэтому и захотелось услышать ваши мнения на это счет. 

 

]]>
Vr, 01 Jun 2012 21:43:18 -0000