В MaxSite CMS 0.84 мы обновили дефолтный шаблон. Предыдущий вариант появился в MaxSite CMS 0.54 и за прошедшие полтора года получил достаточно серьезное развитие и оброс массой новых возможностей.
Должен отметить, что в «старом» default-шаблоне впервые появилась концепция компонентов шапки и подвала, были предопределенные файлы, ушки, css-стили и js-скрипты, которые позволяют автоматизировать множество типовых задач вебмастера. Здесь же я предложил css-фреймворк, который содержит базовые стили, «заточенные» под особенности системы (type-файлы, плагины и т.п.).
После того, как я познакомился с LESS, я внедрил его поддержку на уровне ядра MaxSite CMS и разработал механизм «фоновой» компиляции less-файлов в обычный css-файл. Такой вариант позволяет вебмастеру вообще не задумываться о процессе компиляции — всё работает автоматом.
Но, хотя default-шаблон и предлагает очень хорошую функциональность, постепенно я натыкался на некоторые ограничения, которые «тормозили» дальнейшее развитие системы. Именно поэтому был предложен другой вариант построения шаблона, где все существующие ограничения были исключены.
Иногда стоит задача менять наборы компонентов шапки и подвала на разных страницах сайта. Например на какой-то странице выводить только верхнее меню, а на другой вовсе исключить вывод компонентов. Формально для таких вещей делается main-файл (в каталоге main), где в html-секции шапки прописываются нужные компоненты.
Но, main-шаблон больше используется для смены модульной сетки, где меняются расположение элементов (например правый и левый сайдбар), поэтому если и делать наборы компонентов, то придется их делать для каждого main-шаблона. Это довольно утомительно.
Оптимальным вариантом был бы выбор набора компонентов при редактировании записи через дополнительные мета-поля.
На практике это выглядит так: вебмастер подготавливает файлы, где прописывает подключение нужных компонентов, а при редактировании записи файл выбирается из выпадающего списка.
Среди вебмастеров понятие прототипирования имеет несколько значений. Как правило под этим подразумевают эскиз сайта без детализации. Другая точка зрения — прототип это рабочий вариант сайта, также без детализации отдельных элементов. Википедия определяет прототипирование как «быстрая "черновая" реализация базовой функциональности»
.
Прототипирование постепенно набирает популярность среди вебмастеров и не удивительно, что постоянно появляются новые инструменты для решения этой задачи (см. например «Инструменты быстрого прототипирования» на Хабре). Раньше я воспринимал прототипирование только для быстрого создания графического макета сайта, который можно показать клиенту. Для этого использую Pencil, но постепенно мигрировал к Adobe Fireworks, который заслуживает всяческих похвал.
Основной рецепт — научиться систематизировать и находить нужные знания. И это касается не только MaxSite CMS, но и любой другой системы. Существуют некие базовые основы, без которых, действительно, будет тяжело разобраться. Нельзя заниматься программированием, не зная синтаксиса PHP. Нельзя верстать сайты, «плавая» в основах CSS. Точно также будет сложно создавать новый шаблон, не разобравшись в настройках админ-панели. Таких «основ» много, перед тем, как приступить к чему-то сложному, нужно их изучить.
После того, как этап новичка пройден, уже можно заняться изучением возможностей выбранной CMS. В первую очередь следует обратить внимание на PHP-функции системы. Многие ошибочно полагают, что для их изучения требуется искать мануалы и хелпы. На самом же деле с PHP всё гораздо проще: поскольку php-файл — это и исходный и выполняемый код. Поэтому всё, что следует сделать, так это открыть php-файл.
Когда я впервые столкнулся с WordPress (в 2005 году), то не было никакой помощи, а все объяснялки сводились к каким-то примитивным вещам. Тогда я понял, что единственный путь — это изучать исходный код WordPress. Со временем этот подход для меня стал основополагающим и я его применяю до сих пор к любой системе, у которой есть исходные файлы. Как правило исходный код говорит гораздо красноречивей и лучше любого хелпа и описания.
Как выяснилось, многие не совсем понимают принцип работы MaxSite CMS — для них это что-то вроде черного ящика с загадочными хитросплетениями. Предыдущие публикации на эту тему сохранили свою актуальность, хотя с выходом D2 код изменился и стал несколько проще.
Чтобы закрыть эту тему, попробую на пальцах объяснить такие моменты. Для начала рассмотрим процесс «включения» MaxSite CMS.
В комплекте шаблона присутствует файл layout02.less, который содержит немного другой вариант модульной сетки, построенной по «классическому» принципу. И поскольку для этой сетки нет «резины», то её адаптивность должна уже определяться в responsive-файлах. Рассматривать этот вариант не будем, поскольку он практически один в один повторяет предыдущие уроки.
По поводу модульной сетки скажу, что это краеугольный камень в построении шаблона. От её выбора будет зависеть вся остальная вёрстка. Рассмотрим вариант, когда для шаблона нужно разместить шапку на всю ширину браузера. В нашем же варианте контейнер div.all имеет ограничение по ширине. Следовательно этот блок не позволит дочернему div.header выполнить поставленную задачу.
Выход в этом случае только один — позволить всем родительским блокам иметь 100% ширину браузера.




