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

Veter:

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

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

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

Sergeich:

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

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

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

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

Trustmaster:

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

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

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

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

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

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

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

• идея мной была высказана с целью найти отзыв и для обсуждения заинтересованными людьми.
• я не призываю это «ставить на первый план». Считаю, что в штатной поставке Котонти «такому» делать нечего (по крайней мере пока) и данная функциональность должна быть реализована в виде отдельного модуля/плагина.
• и не дай Бог напрягать «этим» основных разработчиков. У них и без этого работы хватает (есть и план развития CMS и текущие доработки). Если наберется заинтересованный коллектив - можно обсуждать детали и пробовать свои силы.
• то, что тема так или иначе находит отклик меня радует. Еще больше радует, что у каждого свое видение темы «шаблонов» и ее применения. (для этого тема и создана).

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

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

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

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

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

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

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

Trustmaster,

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

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

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

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

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

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

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

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

Привет!

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

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

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

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

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

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

Глянул в 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>
...

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

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

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

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

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

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

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

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

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

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

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

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

#34532 Fox: 

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

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

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

•  удобный способ редактировать шаблон (не надо обращаться к файловой системе, используя FTP/SSH клиенты)
• возможность дать доступ на редактирование стороннему пользователю, не имеющему доступа к файловой системе (администратору заказчика)
• иметь возможность визуального контроля отображения шаблона (если используется HTML парсинг на странице) - см.пример