В соседней теме родилась идея - использовать содержимое страницы как шаблон. Хочется обсудить перспективность и возможные реализации.
Nik Samokhvalov |
|
---|---|
У меня другой вывод: у вас мало опыта. Не обижайтесь, но это так. Заказчики бывают разные, так же как и сайты. Просто, видимо вам не довелось поработать над проектом уровня «сайт-портал», на котором работает не просто секретарша, а более-менее серьёзный веб-мастер, а иногда и команда сотрудников. Такие порталы не будут занимать лидирующие места с шаблонным представлением контента — для них нужны нестандартные решения. Верно, навряд ли ВШ станут популярными и найдут широкое признание среди комьюнити. ВШ — это функция для редких, но глобальных проектов. Как верно заметил однажны Влад, Котэ — фреймворк медиа-класса, правда его можно «сточить» и под эконом-класс. ВШ, на равне с другими полезными фичами, помогут укрепить статус медиа-класса Котонти. Кстати, от секретарш можно будет выключать ВШ. Это же так просто :) P. S. «CMS не для дизайнеров и програмёров делается, а для управления сайтом обученными "секретаршами"» — ой не согласен, не согласен. Не губите потенциал Котонти, в мире есть много сайтов на ЦМС-ках, к которым секретарш вовсе не подпускают. Или не пропускают дальше уровня «Добавить страницу». P. P. S. Прежде чем делать выводы, старайтесь просматривать ситуации не только со «своей головы». И вы сразу же увидите кучи проблем и перспектив. Спасибо :) Добавлено 6 минут спустя: Trustmaster, 1) Не совсем понял суть. 2) Редирект на страницу с ошибкой. Без БД, помоему, сейчас никуда. 3) Это да, ВИЗИВИГ лучше не юзать. 4) Можно пример?.. Sorry for my English.
|
|
Отредактировано: Veter (07.06.2012 19:42, 12 лет назад) |
Macik |
|
---|---|
Ух, тема находит отклик. :)
Veter: Задачу эту надо сначала полностью формализовать. Для этого и создал тему - услышать о вариантах применения идеи и вариантах ее развития. Что касается «в админке» - я бы не засовывал это в «стандартную поставку», а делал бы плагином/модулем, тогда не проблема в админке плагина сделать необходимый функционал. Для страниц шаблонов, например, можно выделять отдельную фиксированную категорию страниц.
Sergeich: Тут зависит от того, 1. кому и для чего делается сайт. Часть этой мысли раскрыл Veter. Делаешь сайты для секретарш - не включай этот модуль вообще. Делаешь для фирмы с «веб-админом» дай им возможность (испортит - сам разгребет или тебе консультацию оплатит). Делаешь под себя - строй хоть замок, особенно если инструмент удобный. 2. не надо эту идею рассматривать узко, как редактор шаблонов (это может быть одной из функций). На текущей стадии (обсуждение) вообще непонятно будет ли что-то реализовано и если будет, то что. :) Я смотрю на этот «прообраз» шире. Это может быть просто «Ш-парсер» дополнительной разметки в текстах страниц с простой подстановкой. Это может быть свой шаблонизатор с разметкой и подгрузкой шаблонов (wiki-style). Может быть что-то еще. Trustmaster: Ответы, опять же, зависят от того, что планируется реализовать - хранение некоторых (coTemplate) шаблонов в БД или некий абстрактный парсер тегов на страницах с возможностью сделать вставку текста из другой страницы (микрошаблоны). Поэтому отчечая на вопросы буду придерживаться начальной идеи - подгрузки отдельных coTemplate шаблонов из текстовой переменной (не важно из БД или нет). 1. В перспективе надо стремиться к минимуму. в идеале загрузили единожды после изменения, закешировали в файлах кеша, потом пользуем от туда. В общем как и сейчас реализовано. Что касается реальной нагрузки - тут как всегда будет зависеть от способа применения. Если разработчик использует 100 шабонов для компоновки одной страницы - он сам себе враг. 2. Ответ очевиден. Если БД ложится - сайт не работает. :) Если речь о том, что можно потерять из БД шаблоны - то бекап никто не отменял.
3. Ни о каком WYSIWYG и речи быть не может (разве кто-то сейчас шаблоны в WYSIWYG делает?). Только plain-text, только хардкор. :) Речь была о том, что при просмотре готового (сохраненного) шаблона его можно было бы увидеть почти в «готовом» виде. 4. Да, узкое место. Но во-первых мы же не ведем речь о переносе всех шаблонов в БД (а узко специализированные могут и не требовать callbacks), во-вторых это можно завязать на систему прав. Делаешь шаблон сам или доверяешь стороннему вебмастеру - «поставь галочку» расширенных прав.
Подытоживая свое ви́дение:
https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F |
Sergeich |
|
---|---|
Опять же, если сайт сопровождает маломальски подготовленный вебмастер, то нет никакого сомнения, что у него есть инструменты для фтп-доступа к файлам сайта и наверняка он пользуется каким-то своим набором инструментов разработчика. Так зачем ему мучаться в вебинтерфейсе, когда проще и удобнее всё делать своими инструментами? Я не понимаю зачем нужен постоянный доступ к редактированию файлов шаблона, локализаций, ядра... Вот объективно, оцените свои реальные давно работающие сайты (не тестовые площадки) - как часто вы что-то меняете на них в шаблонах, плагинах и т.п.? ну ведь редко, очень редко. В самом крайнем случае - раз в неделю. И ради этого воротить весь этот избыточный функционал, который будет грузить систему постоянно? Это очень недальновидно. |
Sergey |
|
---|---|
Я, например, нашел важным дать возможность вставлять страницы вместо слотов, получается так: http://www.cotonti.com/datas/users/slot_205.png
www.cotonti.mobi
|
Macik |
|
---|---|
На всякий случай освежу тему... Вдруг кто не в курсе - с версии шаблонизатора 2.7.9 (вошла в выпуск Siena 0.9.11) добавлена функция компиляции (загрузки) шаблона из строковой переменной.
https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F |