LiveStreet на первый взгляд

Привет сообществу.

Хотелось бы поделиться своими соображениями, которые появились в голове после изучения внутренностей свежеустановленного LiveStreet. Меня в первую очередь интересовала архитектура движка и ее гибкость (читай: возможность добавить свой функционал).


Сперва хочу поблагодарить Максима за его труд, проект действительно очень перспективный и богатый функционалом.
Начну с того, что понравилось:
  • Высокая скорость работы

  • Разделение логики (MVC)

  • Хорошо прокоментированный код


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

    Совершенно неясно, почему модули comment, acl, blog и пр. содержат в себе только соответствующую модель, а контроллеры (экшены) находятся в ядре движка. Получается, что единица функционала размазана по системе: часть в ядре, часть в модуле.

    Так же мне не ясна причина выноса Вида (View) в отдельный модуль. Вид — на 100% компонент ядра системы, и делать его заменяемым не имеет никакого смысла. Конечно, должна быть возможность заменить шаблонизатор (меня, например, воротит от смарти), но это не означает замену всего Viewer-а. Как минимум логика передачи переменных из ивента в шаблон, а так же набор функций-хелперов для генерации html должна остаться в ядре.

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

  • Отсутствие видов для мэйлов и как следствие — ненужные настройки что включать в письмо, а что — нет. Передайте мне в вид мэйла необходимые переменные: $user, $comment, $post и т.д., а я сам решу, какие данные и в какой форме отправлять.

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

  • Плохое форматирование исходного кода. Конечно, о вкусе и цвете споров может быть очень много, но все же есть негласное правило. Оно заключается в том, что код любого opensource-проекта должен быть написан так, чтобы с ним могли работать разные люди (читай: на разных ОС, в разных редакторах, на разных мониторах). На практике это означает: читабельность кода (пробелы вокруг операторов, после запятых в аргументах ф-ии), ширина строки не более 80 символов (разрешения у всех разные), пробелы вместо табов (у всех разные редакторы).
    Дома я работаю на Asus EeePC 7.1, и исходники LiveStreet у меня элементарно не умещаются в монитор по горизонтали. На работе монитор 22 дюйма, но обычно я работаю с 4 файлами одновременно (т.е. правило 80 символов сохраняется).
    Что касается табов, то при ограничении в 80 символов гораздо удобнее использовать 2-пробельные табы вместо 4-пробельных. Они сильно экономят место, и в то же время сохраняют визуальный отступ.

  • Непонятно, зачем в качестве шаблонизатора был выбран Smarty. На сайте Smarty давно пора написать большими жирными буквами «ЕДИНСТВЕННАЯ ОБЛАСТЬ ПРИМЕНЕНИЯ SMARTY — РЕДАКТИРУЕМЫЕ ПОЛЬЗОВАТЕЛЯМИ ШАБЛОНЫ. ДЛЯ ШАБЛОНОВ, КОТОРЫЕ ПОЛЬЗОВАТЕЛЬ САЙТА НЕ МОЖЕТ ИЗМЕНИТЬ, ПРЕКРАСНО ПОДОЙДЕТ САМ PHP». Повторю: PHP сам по себе прекрасный шаблонизатор. Смарти был написан для того, чтобы у автора шаблона не было возможности сделать какую-нибудь гадость (вызвать system(), например). Если автору шаблона можно доверять (в 99% случаев это так), то использование Смарти НИЧЕМ НЕ ОПРАВДАНО.



Объясню, для чего все это мне нужно. Правильно держать ядро и стандартные модули без изменений, чтобы периодически обновлять их через SVN. Функционал, специфичный для моего проекта я бы хотел организовать в виде отдельных модулей.

Так же не хватает полнотекстового поиска. Есть идея реализовать его на Sphinx.

Пока все. Сегодня вечером продолжу изучение LiveStreet, быть может допишу еще что-нибудь в комменты.

12 комментариев

avatar
Забыл еще один момент. Непонятно, почему аякс-запросы не обрабатываются в экшенах наравне со всеми остальными запросами. Если это сделано из соображений производительности, то ИМХО можно было найти решение гораздо лучше, чем просто вынос их в отдельные файлы.
avatar
Хоть и не программист, поддерживаю… Всё хорошо аргументировано!
Особенно удобно было бы модули по папкам сделать, чтобы редактировать надо было в одном месте…
И делиться с остальными.
avatar
надо было перечитать пост перед тем, как отправлять — получилось очень сбивчиво. сейчас подчищу немного :)
avatar
Интересное мнениу конечно… думаю Макс ответит автору что как и почему, а может что то и возьмет на вооружение. Приятно, что высказано грамотное, аргументированное мнение, а не бестолковая критика, как часто бывает.
avatar
В LiveStreet по модулей понимается скорее некая локальная библиотека, реализующая какую то часть общего функционала. Все такие библиотеки-модули находятся в одном месте. Экшен — это уже обработка некой логики сайта, которая может использовать любые библиотеки(модули), они все тоже лежат в одном месте. А само ядро движка лежит в classes/engine/, где нет никакой логики. Т.е.нет блочно-модульной структуры. Хочешь новую логику — добавь экшен, не хватает стандартных библиотек — добавь новую, хочешь аякс — добавь обработчик аякса, хочешь блок — добавь обработчик блока. Получаем более мелкое дробление функционала и каждая такая мелкая часть лежит в одном месте. Т.е. был преднамеренный уход от функциональных массивных кирпичей-моделей.
Смарти — позволяет «обуздать» разработчика в шаблонах, контролировать данные в шаблоне. И мои личные предпочтения на стороне смарти, чем на кашу хтмл+пхп.
Про шаблоны писем согласен.
Про захаркоженные строки согласен.
Да, и на счет «большинство модулей не может работать друг без друга» — это касается в основном только системных модулей(sys_), пользовательские независимые друг от друга. Единственное что может быть так это использование модуля user, т.к. это основной объект движка соц сети.
И View это не 100% часть ядра, это обычный дополнительный системный функционал, оснавная функция ядра — диспетчеризация
  • ort
  • +2
avatar
Тогда понятию «модуль» больше подходит «библиотека», я правильно понимаю?
avatar
абсолютно верно
avatar
вот это, видимо, и путает…
У меня лично с понятием «модуль» ассоциируется нечто целое, обособленное… а вот с библиотекой как раз набор кусочков, которые можно использовать в разных местах.
avatar
реализованы шаблоны писем(уведомлений)
avatar
я уже практически прикрутил уже Sphinx для поиска по топикам и комментариям. в настоящее время разукрашиваю код.

как сделаю готовым к опубликованию, выложу.
avatar
было бы здорово )
avatar
Да. На счет смарти поддерживаю — он еще и ко всему подтормаживает,
даже не смотря на компилацию шаблонов. Все равно нужно вызывать код самого smarty — а это лишний код, без которого прекрасно можно было бы обойтись самим PHP.
Но все равно LiveStreet нравится.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.