Современная, быстрая и удобная система управления сайтом

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

Архив записейКомментарии: 20Просмотров: 36530

Пока речь идет о некой абстракции, призванной прояснить некоторые моменты, которые предположительно могут появиться в 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.

Комментариев: 20 RSS

1jogurt08-11-2013 17:43

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

Т.е., например, по этой закладке у нас было бы два выпадающих списка стилей: body-back.css и page-back.css

В первом можно было бы выбрать цвет фона для body, а во втором - цвет фона для div.page

Владелец сайта мог бы свободно комбинировать, играть цветами.

И такие опции можно было бы предусмотреть для множества элементов - сайдбар боковой, сайдбары нижние, шапка, подвал, div.all, div.comments, div.MainMenu и т.д. По каждому - набор цветов. Плюс, допустим, набор css, отвечающих за ширину сайта, свойство shadow для элементов разных и т.д. и т.п.

В итоге это был бы фактически уже встроенный в систему модификатор дизайна.

2jogurt08-11-2013 17:46

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

3АндрейСайт08-11-2013 18:44

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

Почему бы его не кинуть в сам шаблон? Хочется, переделай под себя.

Сейчас я просто выдергиваю стили по умолчанию и переделываю под текущие задачи. Без каркаса не сделать то, что хочется.

В общем, убирать его плохая идея. Тут скорее приоритетность стилей надо сделать.

И еще, все идеи можно опробовать в отдельно взятом шаблоне и тогда будет ясно, что надо и что не пойдет..)

4Максим08-11-2013 19:12

Так сейчас и приходится переделывать. А нужен какой-то отработанный и четкий алгоритм, позволяющий прикрутить стили MaxSite CMS к любому фреймворку.

5Кирилл09-11-2013 03:21

Максим, привет. У меня сейчас реально остро встает вопрос по этим стилям - точно ничего не поломается?? Я делаю шаблоны на D2, следуя твоей рекомендации. Прост, как потом поддерживать их, если просто что-то выкинуть. Но с другой стороны - style-all-mini.css - честно говоря задрал! Т.к. хочется сделать шаблон нормальный, изменить все по максимуму, но в то же время хочется, чтобы и при след.обновлениях он оставался актуальным. Порой просто этот файл реально мешает и не позволяет внести изменения. Я думаю надо реально вынести в сторону какой-то каркас, но главное чтобы уже действующие шаблоны не поломались, ато это будет полный пипец! И нужно этот вопрос решать скорее, т.к. вот это постоянное изобретение велосипеда начинает отталкивать, приходиться снова изучать структуру и учиться по-новой можно сказать - на это тратиться много времени. У меня прост планы большие на твою CMS, раскрывать пока что не буду, как сделаю, увидишь :) И кстати, надо делать пропаганду какую-то платных шаблонов и скриптов для CMS. На WP я смотрю все больше и больше платностей появляется - подумай над этим Максим пожалуйста.

6Антон09-11-2013 03:45

Лучше механизм, чтобы прокрутить готовые стили к типовым стилям максайта, отключая алл-мини и ресет, т.к. именно они конфликтуют обычно с готовым стилями.

7Александр09-11-2013 10:57

Моё скромное мнение... Начинаю знакомиться с Вашей системой, а пришёл сюда из Joomla.

Мне не очень понравилось, что "компоненты" и "плагины" включены в состав шаблона. Если их вынести за пределы шаблона (а соответственно и их стили), то и обсуждаемой проблемы не было бы.

Разделяй и влавствуй - это кажется девиз системы.

Можно сделать такой релиз Системы (с долгосрочной поддержкой) паралельно с существующей. Тогда будет как и везде (Joomla, Ubuntu-linux) - некоторые компоненты не совместимы, но ничего страшного. Так было всегда.

Вот такие "мысли вслух". С уважением, Александр.

8Олег09-11-2013 15:45

Александр, по моему Вы глупости пишите.

9Максим09-11-2013 16:29

В общем пока получается такая схема. Файл style.less — здесь выполняем подключение less-файлов. Вначале подключается фреймворк (который на LESS), после некоторые файлы MaxSite CMS, плагины, а после уже стили шаблона.


// вначале фреймворк
@import url('bootstrap/_bootstrap.less');

// миксы-хелперы MaxSite CMS
@import url('maxsite/mixins/helpers.less');

@import url('maxsite/mso-menu-vertical.less'); // меню
@import url('maxsite/mso-forms.less'); // .fform
@import url('maxsite/mso-helpers.less'); // cs-хелперы

@MSO_IMPORT_ALL(maxsite/plugins); // плагины

// дальше пошли стили шаблона
@import url('variables.less'); // свои переменные
@import url('layouts/layout.less'); // модульная сетка
// и т.д.

10Максим09-11-2013 16:31

Да, добавлю. Таким способом у меня получилось подключить uikit, kickstart, bootstrap, inuit и kube.

11Кирилл09-11-2013 22:34

Это окончательный вариант? или просто наброски?? Кстати, где именно все это шаманство идет? в шаблоне D3 или в shared?

12Максим10-11-2013 08:06

Наброски в пределах D3. Если бы каждый попробовал по этой схеме подключить стили, мы бы вышли на понимание того, какие следует оставить общими, какие в виде каркаса, а какие обязательными.

13Кирилл10-11-2013 16:34

В ближайшее время попробую реализовать, посмотреть что и как ;-) Имеется ли этот шаблон в 0.855 версии? или как это чудо можно скачать?

14Максим11-11-2013 13:59

Выложил набросок D3: http://max-3000.com/uploads/d3.zip

Описание см. в /css-less/

Просьба, кто делает шаблоны на css-фреймворках, попробовать этот вариант со своим шаблоном.

15АндрейСайт11-11-2013 15:27

А нужен какой-то отработанный и четкий алгоритм, позволяющий прикрутить стили MaxSite CMS к любому фреймворку.

Мммм... А не наоборот? По мне так актуально, например, взять стили от wordpress и получить красивый шаблон для MaxSite CMS

16Илья ЗемсковСайт14-11-2013 06:18

Максим, а будете выкладывать какой-нибудь полноценный шаблон на основе того же бутстрапа? Просто в порядке примера использования предложенного подхода. Считаю, что было бы полезно.

17Максим14-11-2013 07:34

Я не использую сторонние css-фреймворки. И уж тем более бутстрап с его отвратительной типографикой. Моё дело предложить только методику.

18Максим19-11-2013 19:12

Обновил D3 в MaxSite CMS 0.857. Разбил стили по уровням, чтобы было понятно в какой последовательности верстать и куда кидать свои стили. Если не сложно, посмотрите. Скоро выложу релиз 0.86, нужно до этого момента отработать D3.

19Максим03-12-2013 14:46

Скоро выложу MaxSite CMS 0.86, поэтому все, кому тема ещё интересна, могут высказать свои замечания. Напомню: заготовка в shared/blanks/d3.

20Сергей03-07-2014 19:13

А если честно, не поннимаю, в чем сыр бор. Почему просто нельзя взять, и подключить свой css-файл и настроить все под себя на основе "каркасных"? По крайней мере я так делаю. Новые стили замещают старые в порядке приоритетности и все становится замечательно...

Или может я чего-то не понимаю?...

Оставьте свой комментарий!

Комментарий будет опубликован после проверки

Вы можете войти под своим логином или зарегистрироваться на сайте.

(обязательно)