Новое во фронтенде в альфа версии LiveStreet

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


Компоненты

Многие слышали о 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 комментариев

avatar
Звучит очень интересно — буду ждать беты для тестов. С наступающим вас товарищи и успехов в Новом году) Спасибо за альфу.
avatar
Когда планируется выпустить релиз или хотя бы бету?
avatar
Что-то мало комментариев… Добавлю.

1. Местами все ещё встречается подключение компонентов через инклуд, с чем это связано?
2. Будут ли гайды по обязательным элементам/классам/структуре шаблонов для полной совместимости со стандартным?
avatar
1. Подключение компонентов доделаю в ближайшие дни, везде будет подключение через {component}
2. Будут
avatar
На счет Бутсрапа я бы все же подумал. Может найти какие компромиссные пути решения? Реально ведь удобнее и быстрее разрабатывать.
avatar
На самом деле это и есть компромиссное решение, html-разметка в большинстве бызовых компонентов будет от бутстрапа, соотвественно стили тоже «бутстраповские», т.к. привязаны к этой разметке, только с нашим дефолтным оформлением + будут лежать в папке с компонентом, где их можно изменять, что намного удобнее при разработке, вместо того чтобы переопределять стили бутстрапа. Скрипты придется в любом случае наши использовать, т.к. они еще используются как обертки (помимо того что обладают нужным нам функционалом). В итоге разработка шаблонов станет удобней и на мой взгляд быстрее, в отличии варианта с подключением всего бутстрапа.
avatar
А зачем что-то переопределять? Все необходимые изменения делаем на странице кастомизации Бутстрапа, возможности там не маленькие. Если что-то необходимо добавить — дописываем в компоненте.

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

В итоге разработка шаблонов станет удобней и на мой взгляд быстрее

А в чем она станет быстрее? Если переделывается все, то все равно по всем компонентам шерстить и менять, в одном они файле или разложены по папкам. В Бустрапе же на одной странице изменяется многое.
avatar
Все необходимые изменения делаем на странице кастомизации Бутстрапа, возможности там не маленькие.
Для этого и делаем разметку бутстрап-совместимую, чтобы можно было, при желании, использовать стили предназначенные для проектов на бутстрапе, т.е. сгенерированную тему, после небольших правок, можно будет использовать в ЛС.

А в чем она станет быстрее?
Тут надо учитывать, что не все знакомы с бутстрапом, возьмем для примера новичка с базовыми знаниями CSS, перед ним стоит задача оформить компонент button, для этого он идет в соответствующую папку со стилями и просто заменяет фон, цвет итд, все кажется простым и понятным. В варианте с бутстрапом — стилей в компоненте нет, что уже кажется не логичным, надо создавать свои и переопределять бутстраповские, либо идти знакомится с less и бутстрапом и генерить темы в кастомизаторе, потом их еще подключать. Первый вариант мне кажется проще и снижает порог входа в разработку шаблонов для ЛС.
avatar
либо идти знакомится с less и бутстрапом и генерить темы в кастомизаторе, потом их еще подключать

Достаточно перейти на страницу getbootstrap.com/customize/, изменить необходимое, скачать архив и залить в папку Бутстрапа шаблона.
avatar
Думаете, что новичок без знания less и bootstrap сходу разберется в этом кастомизаторе? Но, опять же, у тех кто знаком со всем этим, будет возможность, после небольших правок, использовать темы сгенеренные в кастомизаторе.
avatar
новичок без знания less

А к чему там знания less? Все интуитивно понятно.

Но в целом, ок — нет, так нет. Закроем тему. Меня любой вариант устраивает. Радею за снижение порога вхождения в разработку шаблонов, не более того.
avatar
Спасибо, круто! Вопрос по обновлению шаблонов. Так понимаю проще писать текущии шаблоны с нуля, чем переделывать на новую версию?
avatar
Да, структура шаблонов сильно изменена, придется с нуля делать, в ближайшее время будет написана документация по шаблонам и фронтенду, следить можно в wiki на гитхабе (сейчас там только док-ия по компонентам).

Знакомится с новым фронтендом ЛС можно уже сейчас, но переделывать свои шаблоны я бы пока не рекомендовал и подождал бы беты, где уже будет отзывчивый дизайн, доступность компонентов итд, чтобы все это можно было использовать в своих шаблонах.
avatar
Ясно, благодарю!
avatar
Предложение по верстке synio: если можно, сделайте так, чтобы html и js synio и developer'а были идентичными — плагины пишут под synio, шаблоны делают на developer'е, в итоге, нет-нет да вылезают косячки…
avatar
Сделаем, дефолтные шаблоны теперь не будут так сильно различаться структорой.
avatar
а наследовать шаблон шаблоном можно? т.е. построить синьйо на компонентах девелопера. чтобы как можно меньше тягать одинаковые файлы.
avatar
Наследование шаблонов другими шаблонами пока не реализовано, и в 2.0 думаю не стоит ждать этого функционала, но в планах есть.
avatar
В темах шаблона можно будет переопределять файлы шаблона? Или по-прежнему только подключение стилевых файлов?
avatar
Суть тем как раз в изменении только стилей, можете привести примеры где нужно переопределять шаблоны в темах?
avatar
Ну к примеру, у меня в «Developer-Kit» сейчас куча различных лент для топиков. Можно было бы в шаблоне оставить одну, а все остальные реализовать в темах. Кому не нужно лишнее — удалили темы и все.

Примеров можно массу придумать, но не в этом основное удобство. Сдается мне, что с обновлениями шаблонов дела пошли бы куда лучше:
1. Делаем на основе девелопера свой шаблон, все изменения производим на уровне темы (на 100%, как правило, шаблоны не меняются), обновился движок — перезалили девелопер, сравнили измененные файлы с новыми в шаблоне, внесли соответствующие правки при необходимости.
2. Качает пользователь готовый шаблон, вносит свои правки (на уровне темы), обновился шаблон — залил в него свою тему, сравнил измененные файлы, поправил, если необходимо.
avatar
Различные виды отображения топиков правильнее будет добавить в компонент topic и уже оттуда их подключать.

Сдается мне, что с обновлениями шаблонов дела пошли бы куда лучше:
Вы тут описали, то, что спрашивал PSNet чуть выше, этот функционал лучше реализовать с помощью наследования тем. Плюс компоненты тоже можно наследовать — по дефолту в девелопере папка с компонентами будет пустая и подключаться компоненты будут из папки frontend/components, а в сам шаблон разработчики будут добавлять только те компоненты, которые хотели бы изменить, таким образом в шаблоне не будет дублируещего кода (которые не отличается от дефолтного кода компонентов).
avatar
Различные виды отображения топиков правильнее будет добавить в компонент topic и уже оттуда их подключать.

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

Плюс компоненты тоже можно наследовать

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

Если же он мог бы все свои изменения выносить в тему переопределяя файлы шаблонов, то с обновлением шаблона ему оставалось бы глянуть в теме какие файлы он изменял и сравнить их с файлами в обновленном шаблоне.
avatar
А поменялось то многое и приходится отписывать, что ему проще свои шаги повторить опять. С выходом новой версии опять… и опять.
Вот поэтому сделайте текстовый файл, в котором сообщите пользователям что все свои изменения пусть записывают в файл и потом на новые версии сверху ставят.
avatar
Согласитесь, не самое лучшее решение…
avatar
Но экономит время и организовывает пользователей, иначе в поддержке можно если не утонуть так поплавать до упадка сил.
avatar
Поэтому я предлагаю такое решение (если оно конечно возможно), которое сэкономит время и нервы обеим сторонам.
avatar
так а разве компоненты не решают этой проблемы? все будет работать на них: список топиков, пользователей, поиск и т.п.
avatar
нет
avatar
Ну надо в теме в менюшке местами пункты поменять, что проще условие писать: при такой теме одно, при второй другое или просто в тему файл закинуть с измененным меню, который автоматом подхватиться взамен того, что в шаблоне?
Лишний уровень наследования усложнит как код, так и структуру шаблона, к тому же темы по задумке должны изменять только стили, все остальное я бы рекомендовал оформлять как опции шаблона. Например: опция отвечающая за отображение топиков, за какую-то особую структуру меню итд, а темы все это дело должны оформлять.

Опять же пример (более подробный пункт 2 из коммента выше): обновляется шаблон регулярно, вносятся какие-то изменения, правки и проч.
Как уже выше написал, эта проблема лучше решается наследованием шаблонов.
avatar
Лишний уровень наследования усложнит как код, так и структуру шаблона

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

все остальное я бы рекомендовал оформлять как опции шаблона

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

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

Но выше и отвечали:

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

Но выше и отвечали:
Но это не значит что надо добавлять функционал от которого в будущем придется отказаться.
avatar
Сдвинуть не получится, потому что компоненты из папки с приложением будут еще использоваться плагинами...

А почему бы плагинам не использовать компоненты шаблона, если их все туда перенести?

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

Т.е. на первом месте забота о разработчиках движка, а не о сторонних разработчиках?

Ладно, нет — так нет, закроем тему.
avatar
А почему бы плагинам не использовать компоненты шаблона, если их все туда перенести?
Компоненты из папки приложения могут использоваться плагинами независимо от компонентов в шаблоне, например кнопки в новой админке не будут зависеть от кнопок в шаблоне.

Т.е. на первом месте забота о разработчиках движка, а не о сторонних разработчиках?
Это забота о всех разработчиках, вам не нужно будет думать о компонентах которые вы не изменяли/не переопределяли — которые подключаются из папки с приложением (в 1.0 это были общие скрипты), т.е. если мы что-то изменим в компонентах в новых версиях, разработчикам понадобится меньше времени на адаптацию своих шаблонов, в отличии от варианта
где все находится в шаблоне — там бы пришлось просматривать все на наличие изменений.
avatar
по дефолту в девелопере папка с компонентами будет пустая и подключаться компоненты будут из папки frontend/components
т.е. все же можно будет сделать что я спрашивал только другими средствами — компоненты будут в самом приложении, а и девелопер и синьйо будут их брать оттуда?
avatar
Да, в какой то мере это заменит наследование шаблонов, чуть подробнее в вики.
avatar
по дефолту в девелопере папка с компонентами будет пустая и подключаться компоненты будут из папки frontend/components, а в сам шаблон разработчики будут добавлять только те компоненты, которые хотели бы изменить

И это исключает возможность создания своего базового шаблона на котором на уровне тем можно было бы создавать другие шаблоны.

Да и почему бы не вынести все что касается визуального оформления в шаблон?
avatar
И это исключает возможность создания своего базового шаблона на котором на уровне тем можно было бы создавать другие шаблоны.
Не исключает, разработчик сможет скопировать все компоненты в папку с шаблоном (таким образом переопределив те что находятся в frontend/components) и уже там их модифицировать.

Да и почему бы не вынести все что касается визуального оформления в шаблон?
Как выше уже написал, у разработчиков будет такая возможность, по дефолту же выносить все в шаблон не вариант, по той же причине, по которой в 1.0 все общие js файлы были вынесены в common.
avatar
Не исключает, разработчик сможет скопировать все компоненты в папку с шаблоном (таким образом переопределив те что находятся в frontend/components) и уже там их модифицировать.

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

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

по той же причине, по которой в 1.0 все общие js файлы были вынесены в common

Я, видимо, пропустил это, что за причина?
avatar
Да, но это исключает дальнейшее наследование своего, модифицированного шаблона.
Да, пока наследования шаблонов нет, единственный вариант это модифицирование базового шаблона (в общем то как и сейчас)

Я, видимо, пропустил это, что за причина?
Чуть выше ответил
avatar
Фотку и аву зря, наверное, объединяли. В итоге мы имеем по-прежнему ососбо незадействованную фотку и аву созданную из нее.

В старом варианте была таже незадействованная фотка и любая ава, но учитывая то, как в новой версии можно задавать размеры изображений эту незадействованную фотку можно было бы использовать в качестве редактируемой фоновой картинки в шапке профиля (твиттер, гуглоплюс), т.е. +1 к функциональности фото профиля.
avatar
Что если разработчику шаблона нужно и фото и фоновая картинка?
avatar
Тоже самое, что и сейчас: фото оставлять как есть, а для фона писать какой-нибудь плагин.

В предложенном мной варианте фон можно сделать без дописывания плагинов, если не требуется фото. Если же нужен и фон, и фото, и ава, то без плагина будет не обойтись, да, но каков процент таких случаев?
avatar
Можете рассматривать это как одно поле — аватар, где фото просто еще один из вариантов аватары. Если какой-нибудь плагин захочет использовать фото пользователя, то в вашем случае он получит фоновое изображение, а это уже нарушает совместимость. Лучше использовать фото для того, для чего оно предназначено, а фоновое изображение добавлять плагином.
avatar
Если какой-нибудь плагин захочет использовать фото пользователя, то в вашем случае он получит фоновое изображение, а это уже нарушает совместимость.

За все время, прошедшее с появления фото в каталоге был лишь один плагин использующий его и то, он лишь позволял ставить ему оценку.

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

Возможно, получится сделать так, что поле, которое сейчас используется для превью в топике, можно будет встраивать в другие сущности (юзер, блоги), тогда необходимости в плагине не будет, но это уже вопрос не ко мне.
avatar
Подскажите, а выход стабильной версии LS 2.0 ориентирован на какое время?
  • sv9t
  • 0
avatar
На неопределенное, нету сроков.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.