"Developer Kit" v.1.5.0
Продолжаю работать над шаблоном и сегодня представляю вам новую его версию — 1.5.0.
Основное изменение — добавлена новая тема, которую сейчас можно наблюдать в моем бложике. Надеюсь, вам понравиться.
PS: В блоге прошу не мусорить.
Основное изменение — добавлена новая тема, которую сейчас можно наблюдать в моем бложике. Надеюсь, вам понравиться.
PS: В блоге прошу не мусорить.
33 комментария
Да, к сожалению, от этого никуда не дется. По большому счету, к любому шаблону плагины необходимо адаптировать в той или иной мере.
В других моих шаблонах есть ссылки на файлы адаптаций для плагинов. Большинство из них подойдет и сюда. Для тех же плагинов, которые работают с меню необходимы небольшие правки. Посмотрите, может найдете нужный.
Можете рассказать за счет чего это достигается, если не секрет?
Нет, потому как это получиться костыль, который будет только мешать впоследствии. Да плагины будут отображаться в большинстве своем, но их ведь все равно необходимо подстраивать под основной дизайн… И в таком случае теряется вся гибкость Бустрапа.
Давайте на примере:
Берет человек шаблон для разработки на его основе своего шаблона, ну или простого допиливания под себя. На той же странице кастомизации Бутстрапа меняет его по своему усмотрению, дописывает свои стили… А затем начинает ковырять плагины подгоняя их под общую стилистику. А тут у него два варианта: изменять html или css плагинов. Хорошо, если пойдет по первому пути.
Поэтому считаю, что лучше сразу брать необходимый плагин и менять его html согласно документации Бутстрапа. Тем более, что изменения там не такие страшные, как кажуться.
Конечно, такой подход повышает уровень необходимых знаний для работы с шаблоном и оттолкнет новичка, но тут уж…
А вообще, я одного не пойму: в последнее время адаптацию плагинов под шаблон чуть ли не в обязанность разработчикам шаблонов ввели. На сколько я помню, когда-то это был всего лишь акт доброй воли.
И почему разработчик шаблона должен адаптировать плагины, а не разработчик плагина? :) Я ведь могу сказать, что это не шаблон не дружит с плагинами, а плагины не дружат с шаблоном. Как бы палка о двух концах, а стрелки все активно переводят на верстальщиков и это становиться само собой разумеющимся…
Я раньше с Друпалом немного работал, так там таких вопросов даже не возникало. Возможно, потому что уровень вхождения выше, или еще по какой причине — хз, но небыло. Да и работа в вебе как бы подразумевает наличие каких-то знаний, или желания их получить…
А у вас будет меньше проблем с поддержкой.
То может напишите краткую базовую инструкцию по замене классов, например:
у меня где-то был обширный комментарий по этому поводу, но сейчас не найду. если коротко — авторы плагинов используют стандартную структуру и набор классов шаблона по-умолчанию, а авторы шаблонов часто меняют их там, где можно было и сохранить даже для своего дизайна.
очень просто: на шаблоне по-умолчанию движка плагины отображаются корректно.
так и не часто такие вопросы возникают, т.к. часть покупателей решает их сама.
Это я видел, но не пойму как работает. Плагины будут наследовать файлы (структуру?) установленного на сайте шаблона или как?
А у меня их особо нет. Если что по мелочи подсказать — объясняю на словах, если на заказ — отправляю на Р.ЛС. Конечно, часть возможных покупателей теряется, но мне это не принципиально, мне нравиться сам процесс. :) Делать же для каждого шаблона отдельный стилевой файл и лепить в него еще кучу стилей… нет, это не вариант.
Я считал, что этого достаточно, да и вопросов за год таких не возникало. Но коль уж подняли тему — ок, напишу.
Ага, только вот тут есть немного лукавства. Авторы плагинов затачивают свои плагины под стандартный шаблон (сейчас это synio), причем не всегда и придерживаются стилистики шаблона, хотя, по идее должны бы завязывать все на developer, ведь именно на нем, по идее, должны разрабатываться шаблоны.
Иногда это необходимо. Я когда этот шаблон делал, мог часть стандартных классов просто выбросить за ненадобностью, чтобы не городить огороды и избыточность. В конце-концов, я могу написать полностью свою структуру со своими классами, меня никто не принуждает к каким-то стандартам и уж тем более это не обязывает меня адаптировать в последующем плагины под то, что у меня получилось.
Адаптация — личное желание разработчика направленное на популяризацию своего расширения, не более того. Она одинаково может делаться как верстальщиками, так и программистами. Если есть на то желание. Имхо.
Ни разу не аргумент. На движке из коробки шаблоны отображаются корректно.
Я это все пишу не ради желания поспорить. Проблема есть и ей уже ни один год. Более того, я считаю, что так просто ее и не решить. В любом случае, нужно вооружаться напильником, толикой знаний и терпения, если есть желание сделать что-то свое, а не поставить типовой набор. Я веду к тому, что не стоит прививать пользователям мнение о том, что за адаптацию плагинов должен отвечать разработчик шаблона.
Ок, тогда более конкретно — буду говорить про себя: мои плагины совместимы со стандартным шаблоном по-умолчанию (синьйо), но под вашим (одним) шаблоном не очень корректно отображалось. А вот почему девелопер и синьйо различаются — это уже не знаю.
А что делать покупателю, когда не совместимы купленные им продукты?
Решать эту проблему нужно, просто никто почему-то не собирается этого делать.
Как и всегда — допиливать, или заказывать допиливание.
Я не против пользователей и рад пойти им на встречу, более того, я сам был на их месте, но другого варианта, на сегодняшний день, я не вижу. Адаптировать кучу плагинов — это мартышкин труд, тем более, когда нужны они одному-двум пользователям. Я для «Юпитера» спрашивал какие кому нужны, просил плюсики ставить. Много их там было? Допиливать серьезный плагин для одного человека? А что делать потом, когда собереться куча адаптаций? Следить за обновлениями плагинов? Какая итоговая стоимось шаблона в итоге получиться, если закладывать в нее человекочасы потраченные на адаптацию?
На сегодняшний день я нашел для себя единственный приемлимый вариант:
Таким образом «и волки сыты, и овцы целы». Другого решения я пока не вижу.
У Вас есть идеи как решить? Что для этого надо делать?
Написать стандарт по проектированию шаблонов, также как я начал писать стандарты написания кода. Какие классы для того или иного элемента, общие правила, организация файловой структуры и т.п. Просто пока это не интересно никому, т.к. потребует дополнительных затрат и может распугать часть разработчиков.
Это хорошо, но как быть в случаях схожих с моим? Если кому-то захочется привязать другой фреймворк с другой разметкой?
.button {}писать
.default-css .button {}таким образом в плагинах в родительском элементе добавить только класс default-css и тогда он начнет отображаться более-менее корректно.
но и это решено в новой версии: кроме уже названного наследования в шаблонах будет набор элементов форм и они будут подключатся в нужных местах т.е. где раньше вы писали инпут тайп=«текст»… теперб нужен будет инклуд файла инпута с указанными параметрами (классом, ид и др.)
таким образом каждый разработчик не будет делать дизайн инпутов, а только подключать те, которые есть в шаблоне.
какие это дает перспективы — можно только догадываться)
Я о том, что сейчас в темах по, большому счету, можно только стили шаблона менять, т.е. сделать для шаблона несколько цветовых решений, к примеру.
А в новой версии, слышал, можно будет в добавок к стилям еще и структуру шаблона менять на уровне тем. Или я неправильно услышал?
можно и шаблоны — внутри писать условия
Все верно. Тоже условиями. Есть одна идея правда, но это позже.
Так с условиями понятно, только иногда в них запутаться можно. :) Я когда «Maxone» делал у меня голова пухла от их количества и уровней.
Я думал, в новой версии будет по принципу: закинул в тему свой topic_list.tpl, к примеру, и он автоматом подхватывается при активации данной темы.
Нет. В начале пробовал пару раз, но потом отказался. В модальных окнах уперся в вызов окна добавления изображения к топику. Кнопку разворота информации о блоге хотел перевести, но тогда она на Бутсрапе не совсем хорошо работала (сейчас, правда все норм). Тултипы тоже на тот момент у Бутстрапа проблемные были.
Поэтому в этой части оставил все как есть, но отлючать js Бутстрапа не стал, так что при необходимости его можно использовать.