Концепция шаблона D3

Пока речь идет о некой абстракции, призванной прояснить некоторые моменты, которые предположительно могут появиться в MaxSite CMS. Причём я даже не уверен, что D3 будет именно шаблоном, поскольку речь идет скорее о методике, которая без проблем может использовать в любом текущем shared-шаблоне. Я рассматриваю D3 просто как эволюционное развитие, как когда-то D2 послужил основой для текущего Default.

Точно также скажу, что никаких проблем совместимости не возникнет и ничего переделывать не придется. Задача D3 — отработать механизм, добавляющий ещё одну степень свободы — создание и использование произвольного CSS.

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

А вот что касается css-стилей, то тут возникает масса вопросов и сложностей.

Традиционный вариант — использование style-all-mini.css из shared-каталога показал свою достаточную эффективность и практичность, но вместе с тем накладывает определённые ограничения.

Достаточно простой пример: в style-all-mini.css используется сброс стилей reset. Вместе с тем, всё больше вебмастеров переходят к normalize.css, поскольку он демонстрирует лучшую типографику и «дефолтные» стили.

Очевидно, что мы не можем взять и просто заменить reset на normalize в style-all-mini.css — это «поломает» все существующие шаблоны.

Другой пример — использование стороннего css-фреймворка, например Bootstrap. Подключить его стили не проблема, но из-за различий в именовании css-классов, мы не можем полноценно его использовать. Или то что Bootsrtap использует normalize, уже достаточно, чтобы сильно усложнить вёрстку.

Единственным вариантом решения подобных проблем — отказаться от использования style-all-mini.css.

Но этот файл состоит из различных предопределенных стилей (см. shared/css-less/default/), которые в любом случае должны войти в результирующий css-файл. Например стили форм (класс .fform) используются в type-файлах. Стили плагинов также придётся копировать, поскольку без них они будут выглядеть явно не идеально. Классы css-хелперов используются не только при верстке шаблона/плагинов/компонентов, но и при редактировании текста. Отказаться от них — значит развалить всю типографику.

Таким образом становится очевидным, что css-стили должны разделяться на

• обязательные — те которые используются в type-файлах
• стили плагинов — у них своя html-структура
• вспомогательные — вроде css-хелперы, которые должны быть «типовыми»
• шаблонные — работающие только на уровне шаблона (по сути произвольные)

Формально мы можем сделать подобное разделение уже сейчас. Для этого нужно исключить подключение style-all-mini.css, а вместо него использовать style.css. Поскольку все исходники написаны на LESS, сделать это совершенно не трудно.

Копируется Default шаблон как D3 (или любой другой, не важно). В каталоге css удаляются все файлы и создается один style.php:

<?php if (!defined('BASEPATH')) exit('No direct script access allowed'); 
/**
 * MaxSite CMS
 * (c) http://max-3000.com/
 * 
 * Компиляция less в css
 *
*/
 
// укажем less-файл - полный путь
$less_file = getinfo('template_dir') . 'css-less/style.less';
 
// выходной файл - путь относительно каталога шаблона
$css_file = 'css/style.css';
 
// если нет style.less, то отдаем style.css
if (!file_exists($less_file))
{
	mso_add_file($css_file);
}
else
{
	echo mso_lessc(
			$less_file, 
			getinfo('template_dir') . $css_file, 
			getinfo('template_url') . $css_file, 
			true, 	// разрешить использование кэша LESS
			true, 	// использовать сжатие css-кода?
			false 	// если включено сжатие, то удалять переносы строк?
			);
}
 
# end file

Этот код подключает less-компилятор, но при этом отключаются все остальные css-файлы, вроде var_style.css.

Результирующий файл — style.css будет создан автоматически на основе css-less/style.less. Схема в общем-то стандартная, только немного другие файлы.

Дальше всё шаманство может происходить в style.less. Это может быть подключение стороннего css-фреймворка или полностью свой код. При этом мы «потеряли» все стили плагинов, хелперов и т.д., что приведёт к полному «разваливанию» шаблона.

Чтобы этого избежать, следует подключить файлы (хотя бы выборочно) из shared/css-less/default/.

Но тут другая дилемма: подключать непосредственно из shared-каталога или файлы предварительно скопировать в свой шаблон?

Вопрос достаточно сложный, поскольку каждый вариант имеет как плюсы, так и минусы. Например скопировав mso-plugins.less мы можем сразу выставить нужные стили плагинов. Подключив из shared, скорее всего придется их переопределять.

Другой пример: появился новый плагин или в каком-то существующем поменялась верстка. Подключение из shared в худшем случае просто потребует перекомпиляции css-файла шаблона (она работает автоматом).

Решений проблемы может быть несколько (в комментариях предлагайте свои). Например в shared разместить стили плагинов в отдельном каталоге, где каждый плагин будет содержать свой less-файл. Вебмастер может копировать этот каталог в свой шаблон и уже там меняет стили как нужно.

Другой вариант — задание только каркаса для css-классов без стилей. Например для div.pagination заданы отступы и размер шрифта. Вместо этого формируется только пустой каркас классов, с тем чтобы показать html-структуру плагина. Вебмастер копирует и задает стили уже в своем шаблоне по этому каркасу.

В обоих случаях less-файлы переносятся в свой шаблон, а shared-каталог используется только как заготовки будущих стилей.

Вопрос по css-хелперам (mso-helpers.less) решается достаточно просто — готовый файл кидается в каталог шаблона. Даже если он и обновится, достаточно будет просто его заменить.

А вот вопрос по «обязательным» стилям гораздо сложней. В эту категорию попадают mso-forms.less, mso-style.less (type-файлы) и mso-menu-vertical.less. Файл меню и type-файлов в принципе может быть просто скопирован или заменен своим, поскольку html-разметка меню выдается на уровне MaxSite CMS и уже не меняется. Поэтому стили можно сразу определять на уровне шаблона.

А вот как быть с стилями форм? Это уже отработанный API, который позволяет достаточно просто и быстро сверстать произвольую форму и поэтому активно используется в самых разных частях системы. Тут мне пока видится только один вариант решения: выделить из mso-forms.less основные стили .fform и всегда подключать его к шаблону. При этом создать еще один файл-каркас, в котором уже можно переопределить стили форм под свою задачу.

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

И о совместимости. Ничего ломаться не будет и текущие варианты стилей shared, остаются и поддерживаются в полном объёме. По сути мы говорим даже не о «завтра», а о «послезавтра». Это будет что-то вроде отдельного каталога или шаблона, который вебмастер может использовать по своему усмотрению.

UPD. После обсуждения, сделал набросок шаблона в shared/blanks/d3/ в MaxSite CMS 0.856.