Новое во фронтенде в альфа версии LiveStreet
В новой версии фронтенд был значительно переделан и доработан, все для того чтобы разработка шаблонов стала максимально приятной и удобной. Все что относится к фронтенду было перенесено в отдельную папку frontend, в которой теперь находятся папки с шаблонами, локализацией и компонентами.
Компонент — это отдельная, абстрагированная сущность, с определенным API (который задается в конфиге компонента) которая может содержать любой набор ассетов (css, js, tpl, images и т.д.) и без проблем использоваться в различных проектах.
Благодаря компонентам, теперь, в большинстве случаев, не придется адаптировать плагины под шаблоны. Так же внедрение компонентов позволила избавиться от уймы дублированного кода, который замедлял разработку шаблонов.
Компоненты могут размещаться в папке фронтенда (application/frontend/components), в шаблоне и в плагине, как на уровне приложения, так и на уровне фреймворка. При этом если компонент размещен в папке приложения, он может независимо использоваться как в плагине, так и в шаблоне. Так же поддерживается переопределение компонентов, например компонент в папке с шаблоном переопределяет компонент из папки фронтенда с тем же именем.
Большая часть js кода полностью переписана и оформлена в виде виджетов библиотеки Widget Factory. Многие вендорные библиотеки обернуты в виджет, это позволит без проблем заменить их при желании на какую-нибудь другую библиотеку, сохранив работоспособность шаблона и плагинов.
Небольшой пример использования компонентов:
Подключаем компонент через конфиг (при этом подгрузятся все компоненты необходимые для работы указанного компонента):
Это подключит все скрипты и стили компонента. И теперь с помощью спец функции smarty
В ближайшее время будет написана подробная документация по использованию компонентов.
После всего этого остается несколько базовых бутстрап-компонентов/стилей (типографика, хелперы, лэйблы итд) которые можно использовать в ls-компонентах, но стоит ли ради них подключать весь фреймворк? Предлагаем пользователям высказать свое мнение по этому поводу в комментариях.
Компоненты
Многие слышали о BEM, OOCSS, WebComponents, Components и др. Мы решили взять из этих технологий все лучшее и воплотить это в наших компонетах.Компонент — это отдельная, абстрагированная сущность, с определенным API (который задается в конфиге компонента) которая может содержать любой набор ассетов (css, js, tpl, images и т.д.) и без проблем использоваться в различных проектах.
Благодаря компонентам, теперь, в большинстве случаев, не придется адаптировать плагины под шаблоны. Так же внедрение компонентов позволила избавиться от уймы дублированного кода, который замедлял разработку шаблонов.
Компоненты могут размещаться в папке фронтенда (application/frontend/components), в шаблоне и в плагине, как на уровне приложения, так и на уровне фреймворка. При этом если компонент размещен в папке приложения, он может независимо использоваться как в плагине, так и в шаблоне. Так же поддерживается переопределение компонентов, например компонент в папке с шаблоном переопределяет компонент из папки фронтенда с тем же именем.
Большая часть js кода полностью переписана и оформлена в виде виджетов библиотеки Widget Factory. Многие вендорные библиотеки обернуты в виджет, это позволит без проблем заменить их при желании на какую-нибудь другую библиотеку, сохранив работоспособность шаблона и плагинов.
Небольшой пример использования компонентов:
Подключаем компонент через конфиг (при этом подгрузятся все компоненты необходимые для работы указанного компонента):
$config['components'] = array( ..., 'button');
Это подключит все скрипты и стили компонента. И теперь с помощью спец функции smarty
component
добавляем кнопку в шаблон:{component 'button' mods='primary' text='Отправить'}
В ближайшее время будет написана подробная документация по использованию компонентов.
Bootstrap
Компоненты по возможности разрабатываются с использованием классов и разметки из популярного фронтенд фреймворка bootstrap, это упростит как знакомство с компонентами, так и частично адаптацию шаблонов заточенных под этот фреймворк. Но тем не менее, мы пока не планируем использовать bootstrap полностью. Почему? Ниже несколько аргументов которые останавливают нас:- В большинстве js библиотек бутстрапа нет нужного для LS функционала
- В js библиотеках бутстрапа идет жесткая привязка к классам которые отвечают за оформление
- В компонентах планируется добавить BEM подобное именование классов (и частично уже добавлено), которое позволит избежать конфликтов между плагинами/шаблонами, в бутстрапе же используется обычное именование
- Бутстрап официально не поддерживает вендорные библиотеки, т.е. возможны конфликты с множеством подключаемых в LS библиотек (как минимум из за глобально border-box)
- Док-ия бутстрапа, которая по идеи должна быть плюсом перехода, по большей части окажется бесполезной, т.к. разработчикам плагинов/шаблонов/приложений придется все равно смотреть специфичную док-ию ls компонентов (которую придется писать даже при переходе на бутстрап)
- Обновление бутстрапа (которое мы не можем контролировать и которое отвечает за базовое оформление) может сломать многие шаблоны
- В базовых компонентах (кнопках, алертах итд) будут отсутствовать ассеты, т.к. они будут подключаться вместе с бутстрапом, что не удобно при разработке
После всего этого остается несколько базовых бутстрап-компонентов/стилей (типографика, хелперы, лэйблы итд) которые можно использовать в ls-компонентах, но стоит ли ради них подключать весь фреймворк? Предлагаем пользователям высказать свое мнение по этому поводу в комментариях.
Оформление, Юзабилити и Функционал
Оформление и юзабилити шаблона были существенно доработаны, больше никаких запутанных меню и сложной рейтинговой системы, рядовой пользователь без труда разберется что к чему зайдя на ваш сайт.- Внешний вид шаблона developer был полностью обновлен и стал более легким и современным
- Переделана страница блога и пользователей
- Удобный аякс поиск по пользователям и блогам
- Добавлен новый загрузчик медиа-файлов, который был написан полностью с нуля и позволяет загружать и управлять любыми файлами (сейчас поддерживается загрузка только изображений, но с помощью плагинов можно будет добавить любой другой тип файлов).
- Рейтинговая система упрощена и работает по аналогии с плагином SimpleRating
- Превью-изображение для топика
- Стена теперь выводится на странице профиля
- Переделана загрузка фотографии/аватары у пользователей и блогов
Что планируется
- Отзывчивый дизайн
Сайт будет нормально отображаться на всех мобильных устройствах. - Поддержка RTL языков компонентами
- Доступность компонентов
Пользователи с ограниченными возможностями смогут без труда пользоваться сайтом. - Документация к компонентам
Каждому компоненту будет написана подробная док-ия, которую можно будет просмотреть в спец. плагине, таким образом у каждого шаблона будет готовый styleguide, который можно будет использовать при разработке шаблона и плагинов. - Визуальный редактор
- Шаблон Synio
Дефолтный шаблон из LS 1.0.3 с немного обновленным под современный лад дизайном будет сделан ближе к релизу. - Переход на SASS
Переход на препроцессор планируется, но в новой версии, скорее всего, будет все еще использоваться чистый CSS.
48 комментариев
1. Местами все ещё встречается подключение компонентов через инклуд, с чем это связано?
2. Будут ли гайды по обязательным элементам/классам/структуре шаблонов для полной совместимости со стандартным?
2. Будут
Скрипты использовать Бутсраповкие по возможности, что лишнее — отключаем на той же странице кастомизации, чего не хватает — дописываем.
А в чем она станет быстрее? Если переделывается все, то все равно по всем компонентам шерстить и менять, в одном они файле или разложены по папкам. В Бустрапе же на одной странице изменяется многое.
Тут надо учитывать, что не все знакомы с бутстрапом, возьмем для примера новичка с базовыми знаниями CSS, перед ним стоит задача оформить компонент button, для этого он идет в соответствующую папку со стилями и просто заменяет фон, цвет итд, все кажется простым и понятным. В варианте с бутстрапом — стилей в компоненте нет, что уже кажется не логичным, надо создавать свои и переопределять бутстраповские, либо идти знакомится с less и бутстрапом и генерить темы в кастомизаторе, потом их еще подключать. Первый вариант мне кажется проще и снижает порог входа в разработку шаблонов для ЛС.
Достаточно перейти на страницу getbootstrap.com/customize/, изменить необходимое, скачать архив и залить в папку Бутстрапа шаблона.
А к чему там знания less? Все интуитивно понятно.
Но в целом, ок — нет, так нет. Закроем тему. Меня любой вариант устраивает. Радею за снижение порога вхождения в разработку шаблонов, не более того.
Знакомится с новым фронтендом ЛС можно уже сейчас, но переделывать свои шаблоны я бы пока не рекомендовал и подождал бы беты, где уже будет отзывчивый дизайн, доступность компонентов итд, чтобы все это можно было использовать в своих шаблонах.
Примеров можно массу придумать, но не в этом основное удобство. Сдается мне, что с обновлениями шаблонов дела пошли бы куда лучше:
1. Делаем на основе девелопера свой шаблон, все изменения производим на уровне темы (на 100%, как правило, шаблоны не меняются), обновился движок — перезалили девелопер, сравнили измененные файлы с новыми в шаблоне, внесли соответствующие правки при необходимости.
2. Качает пользователь готовый шаблон, вносит свои правки (на уровне темы), обновился шаблон — залил в него свою тему, сравнил измененные файлы, поправил, если необходимо.
Вы тут описали, то, что спрашивал PSNet чуть выше, этот функционал лучше реализовать с помощью наследования тем. Плюс компоненты тоже можно наследовать — по дефолту в девелопере папка с компонентами будет пустая и подключаться компоненты будут из папки frontend/components, а в сам шаблон разработчики будут добавлять только те компоненты, которые хотели бы изменить, таким образом в шаблоне не будет дублируещего кода (которые не отличается от дефолтного кода компонентов).
Это всего лишь пример. Ну надо в теме в менюшке местами пункты поменять, что проще условие писать: при такой теме одно, при второй другое или просто в тему файл закинуть с измененным меню, который автоматом подхватиться взамен того, что в шаблоне?
Но помимо компонентов есть же и другие файлы: экшены, лэйауты, навигация…
Опять же пример (более подробный пункт 2 из коммента выше): обновляется шаблон регулярно, вносятся какие-то изменения, правки и проч. Пользователь качает себе версию. Пользователь новичок и вставить один код метрики для него уже подвиг, но он пошел дальше — где-то пару тройку стилей поменял, где-то менюшку под себя прописал, еще какие изменения, и тут выходит новая версия шаблона пользователь стучиться в личку с вопросом, а что поменялось, чтобы у себя аналогичные изменения внести и проделывать все свои изменения снова. А поменялось то многое и приходится отписывать, что ему проще свои шаги повторить опять. С выходом новой версии опять… и опять.
Если же он мог бы все свои изменения выносить в тему переопределяя файлы шаблонов, то с обновлением шаблона ему оставалось бы глянуть в теме какие файлы он изменял и сравнить их с файлами в обновленном шаблоне.
Как уже выше написал, эта проблема лучше решается наследованием шаблонов.
Так я не предлагаю добавлять лишний уровень, я предлагаю существующий сдвинуть на ступень вверх. Не к приложению привязываться, а к шаблону, а в темах сделать наследование.
Прописывать в шаблоне условия и в зависимости от настроек в конфиге шаблона подключать тот или иной компонент? Так этих условий может быть тьма. Проще ведь различные варианты разбросать по темам и ограничится переключением темы в конфиге.
Но выше и отвечали:
Но это не значит что надо добавлять функционал от которого в будущем придется отказаться.
А почему бы плагинам не использовать компоненты шаблона, если их все туда перенести?
Т.е. на первом месте забота о разработчиках движка, а не о сторонних разработчиках?
Ладно, нет — так нет, закроем тему.
Это забота о всех разработчиках, вам не нужно будет думать о компонентах которые вы не изменяли/не переопределяли — которые подключаются из папки с приложением (в 1.0 это были общие скрипты), т.е. если мы что-то изменим в компонентах в новых версиях, разработчикам понадобится меньше времени на адаптацию своих шаблонов, в отличии от варианта
где все находится в шаблоне — там бы пришлось просматривать все на наличие изменений.
И это исключает возможность создания своего базового шаблона на котором на уровне тем можно было бы создавать другие шаблоны.
Да и почему бы не вынести все что касается визуального оформления в шаблон?
Как выше уже написал, у разработчиков будет такая возможность, по дефолту же выносить все в шаблон не вариант, по той же причине, по которой в 1.0 все общие js файлы были вынесены в common.
Да, но это исключает дальнейшее наследование своего, модифицированного шаблона. И для каждого нового шаблона, строящегося на нем надо будет просто его переделывать каждый раз.
Т.е., по факту, приходим к тому, что либо используешь свой базовый шаблон и работаешь без наследования, либо используешь базу приложения и имеешь наследование.
Я, видимо, пропустил это, что за причина?
Чуть выше ответил
В старом варианте была таже незадействованная фотка и любая ава, но учитывая то, как в новой версии можно задавать размеры изображений эту незадействованную фотку можно было бы использовать в качестве редактируемой фоновой картинки в шапке профиля (твиттер, гуглоплюс), т.е. +1 к функциональности фото профиля.
В предложенном мной варианте фон можно сделать без дописывания плагинов, если не требуется фото. Если же нужен и фон, и фото, и ава, то без плагина будет не обойтись, да, но каков процент таких случаев?
За все время, прошедшее с появления фото в каталоге был лишь один плагин использующий его и то, он лишь позволял ставить ему оценку.
Да и не у всех же шаблонов будет фото использовано в качестве фона (хотя спрос на это и есть) просто появиться возможность реализовать это без плагинов. Ну а при возникновении ситуаций с плагином использующим фото всегда по месту можно будет решить вопрос.
Возможно, получится сделать так, что поле, которое сейчас используется для превью в топике, можно будет встраивать в другие сущности (юзер, блоги), тогда необходимости в плагине не будет, но это уже вопрос не ко мне.