Что лучше использовать в качестве основы для верстки шаблона (темы), плагинов, модулей по умолчанию ?

88.3% 197
11.7% 26

223 Дата 12.05.2016 14:37

Форумы / National / Russian / Скины и дизайн / Опрос: Опрос: шаблон (тема) - прототип или индивидуальность ?

12>>>

Как вы считаете, в официальном шаблоне сборки Cotonti лучше использовать сторонние решения (bootstrap) для вёрстки, или создать своё ?

Roffun
#1 12.05.2016 14:37

 

Здравствуйте, уважаемые пользователи и разработчики,

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

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

Иначе получается та же ситуация что и со CKEditor, когда в сборку он входит, но по всем вопросам отправляют на офсайт редактора, и если в случае со CKEditor это нормально, то в случае с шаблонами совсем наоборот.

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

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

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

 

ЗОЛОТАЯ СЕРЕДИНА:

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

 

При таком варианте для всех будут одинаковые условия, единый код. Его также можно развивать сообществом как и всё остальное, через гитхаб. Но сам код конечно изначально должен быть от разработчиков Cotonti, а не сторонних.

Хочет кто-то использовать бутстрап - пожалуйста, натягивайте, вот например:

#41680 CrazyFreeMan:

Добрый день

Я лично против любого "своего" шаблона.

1. Это CMF/CMS не для нуба однозначно (а не нуб должен уметь работать с таким примитивным фреймов как бутстрап тот же)

2. Я как бекенд разработчик хочу выучить 20 конструкций бутстрапа и прототипировать и даже адаптировать за 2 часа другие крутые шаблоны на буте а не изучить все прелести CSS / адаптивности и кросбраузерности.

3. В чем проблема с шаблонами если у нас модеь MVC? Кто захочет может легко заменить на другой шаблон, хотите верстайте другие 20-30 шт, дефолтный бут не накладывает ограничений.

Если проблем нет, человек хочет выучить Бутстрап и работать с ним, а я наоборот, не хочу. А если его не будет по умолчанию, то каждый из нас или сделает по умолчанию так как задано в официальной теме разработчиками (а не сторонними прототипами общего назначения), или будет делать своё кино, но это уже будет не вынужденная мера, а личная инициатива. 

Профессиональный подход в данном случае будет таким:  модуль или плагин участвующий в отображении, нуждающийся в структуре (типа pages) по умолчанию делается под официальный код который задокументирован, а если нужно его адаптировать например под Бутстрап, Yui и тд, то для темы идёт папка с необходимыми tpl файлами, как сейчас приходится делать всем кто не с Бутстрап-сообществом. 

ЕСЛИ ВСЁ ОСТАНЕТСЯ КАК ЕСТЬ:

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

Улетел на другую планету, а там почты нету.. https://www.cotonti.com/forums/45298?m=posts
Отредактировано: Roffun (25.05.2016 17:30, 7 лет назад)
CrazyFreeMan
#2 13.05.2016 07:22

Добрый день

Я лично против любого "своего" шаблона.

1. Это CMF/CMS не для нуба однозначно (а не нуб должен уметь работать с таким примитивным фреймов как бутстрап тот же)

2. Я как бекенд разработчик хочу выучить 20 конструкций бутстрапа и прототипировать и даже адаптировать за 2 часа другие крутые шаблоны на буте а не изучить все прелести CSS / адаптивности и кросбраузерности.

3. В чем проблема с шаблонами если у нас модеь MVC? Кто захочет может легко заменить на другой шаблон, хотите верстайте другие 20-30 шт, дефолтный бут не накладывает ограничений.

На счет ДЛЕ у которого 3 шаблона и другие тысячи на их основе - так мне так же просто на основе скелетонти натягивать на кота другие бутшаблоны (тысячи бессплатных) и не плачу за это деньги верстальщикам.

Не нужно путать теги и шаблон я думаю они никак не пересекаются.

И к тому же прийдется эту тему поддерживать в актуальном состоянии и вносить изменения в код, а бутом занимаются люди - просто копипастить код в сборку проще нежели ждать когда кто-то пофиксит шаблон кота.

 

Да и если я правильно понимаю то бут не будет жестко интегрирован в кота.

Будет хорошо увидеть какие-то тезисы от активных разработчиков и планов но голосование подверждает 

Roffun
#3 14.05.2016 13:53

Первый ответ в теме, с почином smiley

#41680 CrazyFreeMan:

Добрый день

Я лично против любого "своего" шаблона.

1. Это CMF/CMS не для нуба однозначно (а не нуб должен уметь работать с таким примитивным фреймов как бутстрап тот же)

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

#41680 CrazyFreeMan:

(а не нуб должен уметь работать с таким примитивным фреймов как бутстрап тот же)

Но захочет ли ?

Например я его вообще не использую, и против навязывания его мне. А навязывание находится внутри шаблонов сборки, модулей, плагинов. В последних изменения даже в классах появились константы, посмотрев которые видно, что Бутстрапу уделено такое же внимание, как например jQuery:

	/**
	 * @var array predefined aliases
	 */
	protected static $alias = array(
		'@jQuery' => 'js/jquery.min.js',

		'@ckeditor' => 'plugins/ckeditor/lib/ckeditor.js',
		'@ckeditorPreset.js' => 'plugins/ckeditor/presets/ckeditor.default.set.js',

		'@bootstrap.js' => 'lib/bootstrap/js/bootstrap.min.js',
		'@bootstrap.css' => 'lib/bootstrap/css/bootstrap.min.css',
		'@bootstrapTheme.css' => null  // Undefined value. You can set to: lib/bootstrap/css/bootstrap-theme.min.css
	);

	// ==== predefined alias constants ====
	const jQuery = '@jQuery';
	const bootstrap = '@bootstrap.js';
	const ckeditor = '@ckeditor';
	// ==== /predefined alias constants ====

Я понимаю что можно не использовать, можно натянуть что угодно куда угодно, сделать с нуля, и т .д.

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

Значит желательно иметь совместимость расширений, не только на уровне логики, но и визуально. Для этого нужен единый стандарт на который нужно равняться. Обычно его задают разработчики. А все остальные решают, следовать им, или делать по-своему.

А в случае с Cotonti, такого стандарта нет, фреймворк ориентируется на другой, сторонний фреймворк. 

  

Улетел на другую планету, а там почты нету.. https://www.cotonti.com/forums/45298?m=posts
Отредактировано: Roffun (25.05.2016 17:24, 7 лет назад)
CrazyFreeMan
#4 14.05.2016 16:56

Тогда вопрос кто займется разработкой независимого шаблона в базовую комплектацию и что б он отвечал нынешным запросам веб-сообщества ?

Будет свой шаблон или бут - те кто делает серьезный проект побоку, все равно заказывает разработку и натягивает

Но мне точно проще с бутом работать, куча готовых решений и придумывать ничего не нужно (типа карусели, дропдауны, шаблоны форм) а так прийдется лепить кучу js библотек под каждую задачу что б показать возможности кота/шаблона/прототипа на коте

 

Жду других постов от пользователей, хочется почитать что думаю

 

Roffun
#5 14.05.2016 20:14
#41682 CrazyFreeMan:

Тогда вопрос кто займется разработкой независимого шаблона в базовую комплектацию и что б он отвечал нынешным запросам веб-сообщества ?

Будет свой шаблон или бут - те кто делает серьезный проект побоку, все равно заказывает разработку и натягивает

 

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

Я бы смотрел в сторону чего-то среднего между фреймворком-прототипом и обычным шаблоном, но с приставкой мини, заточенным под Cotonti. Например лёгкий базовый код, в котором есть маленькое ядро которое практически не нужно будет менять, ( reset , сетка ). Главный скелет, в котором легко задать адаптивное поведение главных контейнеров, из которых состоит каркас, это семантические теги header footer nav aside article main, из которых должен состоять современный сайт. Отдельно уже идут вложенные блоки, которые формируют функционал, от поиска до копирайтов. При таком подходе получается код, который легко можно кастомизировать, изменить моментом количество сайдбаров, максимальную ширину всех блоков изменив пару строк в css. 

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

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

Улетел на другую планету, а там почты нету.. https://www.cotonti.com/forums/45298?m=posts
Отредактировано: Roffun (25.05.2016 17:22, 7 лет назад)
Yusupov
#6 15.05.2016 06:25

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

Кроме-того, если нет желания пользоваться bootstrap, то кто мешает убрать все его файлы и написать свои стили для прописанных в шаблонах селекторов? При этом не нужно будет существенно править сами шаблоны. 

Беда котонти не в выборе bootstrap или своего велосипеда, все гораздо глубже. 

Roffun
#7 15.05.2016 09:28
#41685 Yusupov:

Сплошное противоречие. 

Почему противоречие ?  я нигде не говорил что какой-либо фреймворк нужен по умолчанию в сборке вообще.

#41685 Yusupov:

Говорите, что нужен хорошо документированный конструктор и одновременно противитесь готовых и всем известных css-фреймворков.  

 Это никакой взаимосвязи не имеет, я против любых фреймворков общего назначения в Cotonti вообще, исключение в данном случае - конкретная наработка заточенная под Cotonti, но таковой пока что нигде нет. Вы считаете что нереально создать свой конструктор конкретно под задачи Cotonti ?

#41685 Yusupov:

Кроме-того, если нет желания пользоваться bootstrap, то кто мешает убрать все его файлы и написать свои стили для прописанных в шаблонах селекторов? При этом не нужно будет существенно править сами шаблоны. 

Для меня это не проблема,  например я всю вашу биржу со всеми плагинами могу перевести на любую вёрстку, свою, новый фреймворк, что угодно, возможностей и опыта для этого достаточно.

 

Улетел на другую планету, а там почты нету.. https://www.cotonti.com/forums/45298?m=posts
Отредактировано: Roffun (25.05.2016 17:21, 7 лет назад)
Yusupov
#8 15.05.2016 10:17

Не вижу никаких проблем. Пусть каждый сам под себя и адаптирует любую готовую фичу. Всем не угодишь! Тем более у каждого разработчика уже итак свои наработки. 

 

Macik
#9 18.05.2016 01:31

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

Вижу перечень заявленных проблем / вопросов таким:
1. Недостаток тем
2. Недостаток документации / инструкций по созданию / верстке под Котонти
3. Под какую тему делать шаблоны при разработке расширений
4. Выбор между фрейворком или «специализированной разработкой»

Я, естественно, не смогу предложить всеобъемлющее решение, но изложу свое видение по пунктам.

Пункты 1 и 2 можно свести воедино. Причины а) отсутствие самоподдерживающегося сообщества вокруг Котонти, как такового; б). отсутствие возможности (должной мотивации) у разработчиков. Иными словами некому делать и решение тут одно — помочь делом: на уровне пользователя (написать недостающую документацию, сделать пошаговые инструкции), на уровне помощника сообщества (поделиться своими темами и расширениями, помочь проекту финансово), на уровне разработчика (исправление текущих ошибок, разработка в контексте оперативного плана).

п3. Идеология Котонти подразумевает, что темы должны переопределять базовые шаблоны расширений, но не наоборот. Т.е. иными словами, расширение должно предоставлять максимально универсальный шаблон, который позволяет использовать расширение как минимум с базовой (стандартной) темой.
Если разработчик создает комплекстное расширение (подразумевающее вывод сложных структур данных или элементов UI), то использование сторонних фрейворков или требование работы только с определенной темой остается на совести разработчика и, в конечном счете, зависит от желания сделать расширение универсальным или ограничить потенциальную аудиторию пользователей.

п4. Каждый разработчик для себя выбирает сам, что ему удобнее. 
Для движка разработчиками выбор сделан в пользу Бутстрапа (см.ниже). Почему подробно описывать не буду (уже обсуждалось многократно), лишь отмечу  доходчивую документацию, хорошую поддержку и досаточно широкий спектр решаемых задач.
В специализированной разработке (в текущих условиях) вижу одни минусы и контраргументов в приведенных постах для себя не нашел. 
Это ни в коем разе не умоляет заслуг по разработке «альтернатив». Во многом из таких проектов и складывается сообщество. И яркий тому пример это «Биржа», которая выросла в полноценный проект и дает толчок самому движку.
Поэтому могу пожелать только удачи в нелегком деле собственных разработок, а так же поддержки и документирования. Как говорится не только спрос рождает предложение...  Если разработка нужная, то она будет востребована. 


Если перейти к конкретике и поговорить о перспективах, то ситуация такая:
- движение в сторону БС начато разработчиками уже очень давно и не безосновательно.
- последнее (внутрикомандное) обсуждение было осенью, что подтвердило планы сделать базовую тему на БС.
- кроме этого Дмитрий предложил доработать свою «Nemesis» в сторону «универсального скелета для разработки» (т.е. максимально унифицировать, сократить привязку к классам и т.д.).

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

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F
Roffun
#10 18.05.2016 09:22
#41702 Macik:

 

Пункты 1 и 2 можно свести воедино. Причины а) отсутствие самоподдерживающегося сообщества вокруг Котонти, как такового; б). отсутствие возможности (должной мотивации) у разработчиков. Иными словами некому делать и решение тут одно — помочь делом: на уровне пользователя (написать недостающую документацию, сделать пошаговые инструкции), на уровне помощника сообщества (поделиться своими темами и расширениями, помочь проекту финансово), на уровне разработчика (исправление текущих ошибок, разработка в контексте оперативного плана).

 

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

Те кто пробовал когда-нибудь перенатянуть полностью готовое решение имеющее структуру, знает, что это дело кропотливое. Я знаю о чем говорю, так как переводил полностью и весь дистрибутив Cotonti, и биржу, а там один модуль projects чего стоит, переводить нужно всю структуру. Но это если мне нужен модуль проектов, а если дело наоборот, у меня есть какой-нибудь модуль, а я его сделаю под свою сборку, которая на коде без бутстрап, то тем кто захочет модуль использовать вне моего кода, придется адаптировать самостоятельно.

 

Улетел на другую планету, а там почты нету.. https://www.cotonti.com/forums/45298?m=posts
Отредактировано: Roffun (25.05.2016 17:19, 7 лет назад)
Leshkens
#11 18.05.2016 17:09

Бутстрап не люблю, люблю фондейшен. Если что-то и использовать в сборке, то собственную разработку, если нет, то кода бутстрапа или другого фреймворка быть не должно, по моему мнению.

Отредактировано: Leshkens (18.05.2016 17:19, 7 лет назад)
Macik
#12 18.05.2016 17:22
#41704 Roffun:

... но почему-то их воспринимают на уровне шаблона. а она глубже, на уровне любых расширений где задействован код html css.

Это не проблема системы. Это проблема конкретного разработчика, который выбирает как оформить код, привязывать ли его к определенному фрейворку или своему коду. Система сама по себе достаточна гибка. Те же строковые ресурсы позволяют абстрагироваться от сырого HTML кода и , позволяют писать достаточно универсальный код. Другое дело, что разработчик, как правило, не хочет себя утруждать и делает как быстрее и удобнее, под себя.

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

Да. И это проблема разработчика. Чем проще и универсальнее сделает, тем шире будет его потенциальная аудитория. 

но всё это будет основываться на своём коде,

Увы, это давний тренд. Система в силу исторических причин сильно фрагментирована. И улучшений в этом направлении пока нет.

В том числе и поэтому мы, как команда разработчиков, стараемся сделать ядро максимально универсальным и стандартизировать то, что возможно. 

пишу только то что сам знаю и использую, а использую я свою наработку, которую тестировал не один год.

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

Но в любом случае, это даст приток новых людей, согласен с тем, что Булата сборки поспособствовали притоку пользователей. Мои задумки ориентированы на другую аудиторию, поэтому надеюсь со временем это тоже сделает свой вклад в популяризацию Cotonti.

Будем надеятся это будет органично дополнять стандартные варианты, в смысле займет свою нишу.

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F
Roffun
#13 18.05.2016 18:06
#41706 Macik:
 

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

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

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

#41705 Leshkens:

Если что-то и использовать в сборке, то собственную разработку, если нет, то кода бутстрапа или другого фреймворка быть не должно, по моему мнению.

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

Улетел на другую планету, а там почты нету.. https://www.cotonti.com/forums/45298?m=posts
Отредактировано: Roffun (19.05.2016 11:02, 7 лет назад)
Dr2005alex
#14 19.05.2016 19:14

Добавлю пару капель... спор уже давно..... результаты у всех разные...

Мое мнение изначально.. было за бустрап.......

Потом потихонечку начал отходить от него.... писать свое...

Сейчас опять я за бутстрап.... объясню...

1) Бутсрап очень сокращает время верстки. Писать свое поверьте дольше.. мало того что дольше, так и нет гарантий что вы все в состояние уследить (аля кроссбраузерность и мобилы)

2) Раньше изменял стили бутстрапа путем переопределения стилей в другом файле... это мало того что не правильно.. это еще и не удобно..Разобрался с less и бутсрап стал лучшим другом.. Пару движений и ваш шаблон превращается в совершенно неузноваемый сайт на буте.... Советую разобраться все уто против бутстрапа.

3) По поводу ниписания своих стилей и классов -- это трудоемкая работа... требующая анализа и аудита для нормального поддержания  этого всего в нормальном состоянии... в текущей задаче для коробочного котонти. Это все требует времени и сил команды... которая сейчас и так не в лучшем виде...

4) Если в коробке иметь классы и методы бутстрапа, то совсем нет проблем (как писали выше) удалить файлы бутстрапа и прописать свои стили... Зато остается некий стандартизированный скилет в шаблоне. Хочешь свой, хочешь бутстрап ИМХО

Я за BOOTSTRAP нынче... после освоения его првки через less. Оказывается очень удобно...

WebKaa.ru - Cotonti Relax
Roffun
#15 19.05.2016 20:00

Дело в том, что я для себя собрал воедино то что нужно, например каркас сайта я использую семантический, бутстрап тут не поможет, использую свой генератор верстки каркаса. Некоторые элементы и сетку сделал как у фреймворка W3.CSS только классы короче.

Верхнее меню сделал свою наработку, 3 уровневое, адаптировал его к плагину, пункты появляются автоматически, респонсив, сворачивается на маленьких экранах без скриптов, также адаптировал боковое меню-аккордион. 

Дроп-кнопки тоже сделал свои, только в отличие от бутстрапа, у меня с отключенным js они по наведению работают, а с включенным по клику. Модальные окна есть в движке по умолчанию jqModal , смотрел сегодня документацию, запускать не проблема, также есть мой плагин fancyboxes на основе скрипта fancybox, через него вообще легко запустить вызов модального окна, как файла, ифрейма, видео, флеш, так и содержимого id блока.

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

Также будет встроена возможность сделать контент в несколько колонок добавив 1 класс в нужное место, легко добавить / убрать сайдбары, и другие плюшки. На данный момент код css всех файлов в шаблоне в несжатом виде весит около 40 кб, и это с комментариями к каждому куску, например:

/* CABINET */

/*SEARCHFORM *

/* SPEEDBAR */

Что мне может в этом случае дать бутстрап, если у меня уже есть наработка готовая, и мой сайт работает на ней, вернее уже на более устаревшей версии чем сейчас готовится. Я знаю что на этой наработке смогу обеспечить своих пользователей и уроками, и документацией, и плюшками.

А если учесть что я с самого начала не использовал бутстрап, как только освоил Cotonti, написал сразу свой код под всю сборку, а теперь ещё и запустил новый сайт по вебмастерингу, то поддержка кода мне нужна как для своего сайта, так и для уроков, поэтому мне всё равно его придётся поддерживать и развивать, даже если бы не собирался делать сборку, а со сборкой тем более.

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

Поэтому для меня здесь вариант очевиден. Выводы опроса можно уже подбивать: большинство будет использовать бутстрап, а я продолжу свой путь smiley.

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

Улетел на другую планету, а там почты нету.. https://www.cotonti.com/forums/45298?m=posts
Отредактировано: Roffun (08.07.2016 19:51, 7 лет назад)

12>>>