Промежуточные выводы
Значит в ходе дискуссии возникли корректировки. Было предложено вынести весь дополнительный функционал в плагины. Я согласен с такой идеей. Плагины по сути в livestreet — это есть отдельные куски приложения имеющие в себе контроллеры модели и вьюхи, как пакеты, модули или бандлы в других архитектурах. Сразу появляется возможность отключить/включить нужный функционал. Чтобы сэкономить время можно брать готовые куски кода из модулей и расфасовать их по плагинам с некоторыми корректировками. По ходу перенести все модули на ORM. Кстати возникает возможность подключить готовую библиотеку к фреймворку, например Doctrine или другую, до переноса на ORM.
Пусть основное приложение будет иметь определенный набор модулей и экшенов, самых основных.
Например:
пользователи и авторизация,
типы контента,
категории,
комментарии,
может еще что то.
Расставляем в ключевых местах хуки и приступаем к плагинам.
Плагинами окажутся:
Создание блогов
Подписки
Избранное
Друзья
Rbac, Acl
Ну и другое
По ходу работы над основными плагинами можно корректировать расстановку хуков.
Шаблон основного приложения станет выполнять рекомендательную функцию. В него можно сложить основные стили, компоненты, а плагины будут иметь и свою часть шаблона. Это усложняет работу по фронтэнду. Можно это компенсировать рекомендациями к разработке плагина — как можно меньше стилей и использование layouts основного шаблона. Но это тоже не выход, некоторые компоненты все равно останутся в плагине. Придется чем то жертвовать.
Пусть основное приложение будет иметь определенный набор модулей и экшенов, самых основных.
Например:
пользователи и авторизация,
типы контента,
категории,
комментарии,
может еще что то.
Расставляем в ключевых местах хуки и приступаем к плагинам.
Плагинами окажутся:
Создание блогов
Подписки
Избранное
Друзья
Rbac, Acl
Ну и другое
По ходу работы над основными плагинами можно корректировать расстановку хуков.
Шаблон основного приложения станет выполнять рекомендательную функцию. В него можно сложить основные стили, компоненты, а плагины будут иметь и свою часть шаблона. Это усложняет работу по фронтэнду. Можно это компенсировать рекомендациями к разработке плагина — как можно меньше стилей и использование layouts основного шаблона. Но это тоже не выход, некоторые компоненты все равно останутся в плагине. Придется чем то жертвовать.
24 комментария
Возможность конечно замечательная. Но зачем? Например кто то будет использовать livestreet без блогов, пользователей, подписок и т.д., именно ради этих функций в большинстве случаев используют livestreet. Опционально в админке иметь возможность выключить любую из этих функций — да, но выносить в плагины мне кажется это уже перебор.
Кто нибудь знает более сложную в разаработке фронтенда систему, чем livestreet?
Чтобы попробовать расширить аудиторию движка.
Тогда по фронту нужно будет всю работу все равно выполнять, а если нужна только часть функционала, зачем это делать. Правильнее идти от меньшего к большему, а не наоборот.
Чтобы расширить аудиторию, логичнее работать с аудиторией.
Аудитория ЛС в данном контексте, это кто? Программисты, дизайнеры, верстальщики, вебстудии, маркетологи, школьники, гос или ком учреждения?
Если «копаться с кодом», то по факту получите перекладывание из пустого в порожнее. Какие-то «доработки» привлекут в лучшем случае единицы разработчиков или возможно чуть-чуть улучшат жизнь текущих разработчиков. Коих, кстати, не так уж и много…
Хотите расширять аудиторию, работайте в первую очередь с аудиторией.
Например, примерно год назад Максиму предлагал выход на московскую аудиторию школьников и студентов. Чтобы провести курс обучения, чтобы ребята освоили основы программирования и сделали свои первые сайты на ЛС. Максим ответил, что он не верит в эту историю. Мол он пробовал, не получилось и забил. Как-то так. Вариант еще был выхода на Банки, у банков клиенты предприниматели, им нужны сайты. Закончилось все тем, что не нашлись программисты, которые готовы были «воять» на ЛС.
Могу сказать, что есть веб студия, в которой когда-то я работал, заключила контракт с одним из топ банков на CMS сервис, теперь сидят как на нефтяной вышке.
Слабое место, это отсутствие разработчиков. Разработчики нет из-за отсутствия спроса. Спроса на сам ЛС движок нет, так как никто не работает с аудиторией.
Ну у меня, к примеру, периодически возникала необходимость сделать тот же личный блог и лендинг на ЛС и всегда либо не хватало каких-то мелочей, либо лишнего через чур много было. Знаю, что можно было выбрать более подходящие движки под это, но нравится ЛС и привык к нему. И если у него эти возможности будут почему не использовать?
А имея возможность оставить минимальный функционал можно ведь с помощью сторонних плагинов и что-то другое сделать: выключаем все не нужное, ставим плагин магазина — получаем сугубо магазин без всей лишней атрибутики ЛС и т.п.
А в чем сложность то? Разве что работы больше только по сравнению с тем же Вордпресом, так и функционала больше…
Кстати для лендингов лучше всего подходит modx, если у вас есть готовый каркас с настроенными модулями, все это разворачивается и делается под клиента в течении пары часов.
Ага, ливстрит «сложный» потому что не разработчик не может разработать на нём интернет магазин. Логично.
Раньше js и css «компонента» были глобальны и его шаблон использовался через {include ...}
Сейчас js и css перенесли в папку с компонентом, а его шаблон используется через {component ...}
Единственное, что надо изучить — так это jquery виджеты, но можно их и не использовать, а писать js модули в том же стиле какой был раньше.
И на этом этапе у меня есть вопросы — новый livestreet будет CMS или фреймворком?
Логично все это будет, если вы имете какую-то базу (свой/чужой сайт, относительно стабильный рабочий проект) и от нее отталкиваетесь. Делаете и себе, и косвенно для других, проверяя и оттачивая сделанное «тестерами» лайвстрита, и т.д/т.п.
В обратном случае непонятно, что будет заставлять вас постоянно заниматься кодом/создавать абсолютно новый продукт, имеющий с лс общее — только одно название.
Так пока вроде отличия серьезного от 2-й версии не планируется, просто перемещение существующих вещей в другие места.
В любом случае что-то полезное из него можно будет использовать в своем 1,0,3. Поддерживаем начинания.
Почему усложнит? Фронт работы останется прежним с тем лишь различием, что файлы будут разбросаны по плагинам ядра. Как по мне, так даже проще будет в том плане, что работа разобьется по логическим кускам — сделал одно, переходи к другому. А если нужен минимальный функционал, так и еще лучше — не нужно будет перелопачивать все, достаточно будет сделать необходимое.
Тег «обратная совместимость» (с последнего успешного сохранения) или есть у проекта, или проект не взлетит.
© Альтернативная точка зрения.
Проведу параллель: Не стоит лепить кастом велосипед из легкового автомобиля (лэндинг, хотя это возможно), не стоит лепить и грузовой автомобиль (интернет-магазин).
Для каждой задачи есть свои инструменты, которые оптимально заточены по определенные задачи и аудиторию.
Как вариант, возможно стоит сделать «новый движок» основанные на ЛС и заточенный под определенные задачи. Что-то вроде как Linux Mint, которые отпочковался и был основан на Ubuntu. Например, если есть спрос на лэндинги, сделайте продукт для лэндингов. Чтобы клиент взял коробочную версию, установил/зарегистрировался легко и начал пользоваться, наполнять.
Кому нужно сможет легко сделать свой фронт или мобилку на iOS/Android, приложения под любые другие девайсы и операционки.
А текущий движок уже серьезно устарел, не думаю что будет правильным и целесообразным пытаться воскресить труп. Сделать скрипты миграции будет достаточно, кому надо — перейдут.
Я немного думал последнее время над этим, возможно скоро кое-что представлю на суд общественности.