Движок iLance CMS - взляд изнутри

Источник: intval

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

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

К сожалению мне довелось увидеть эту систему не со стороны красивых админок и замечательных обзоров, а изнутри.Честно говоря я очень давно программирую и мне нравится колупать именно чужой код, это очень обогащает идеями, и я не ожидал увидеть там четкой объекто-ориентированной вылизанной системы, но некоторые решения просто убили на месте... Стоит отметить что iLance сам по себе по тому_что_он_может и что_там_можно_настроить довольно функционален. Действительно, на уровне самой цмски заложена мультиязычность с легкой возможностью настраивания через файлы конфигурации. И первое что отвалилось в процессе установки русской версии была именно она. В программировании мультиязычных сайтов есть 2 основных подхода:

  • Каждая языковая версия - это логически отдельный сайт со своей внутренней системой страниц, данных и т.п;
  • Структура данных одна и та же, но чуть ли не каждая запись сопровождается полем с идентификатором языка.

Ребята же решили не париться со всеми этими сложными ссылками и прочей лабудой и просто продублировали каждую запись с языковым префиксом: title стал title_en и title_ru к примеру. И действительно зачем напрягаться, если title_en заполнен - значит английская, а нет - русская. И я честно понимаю разработчиков. Если бы я знал, что на сайте будет 2 языковые версии и только они - то в рамках баланса время/деньги действительно не стал бы заморачиваться. Принцип "делай то что нужно, а не то что может быть понадобится потом когда-нибудь а может и нет" знаете ли. Но парни явно забыли, что iLance - это система на продажу. И я не буду писать про расход памяти, про то какая задница добавить новую версию через тупое дублирование всех полей везде с дополнительным языковым префиксом - это хрен с ним, потому что даже эти 2 несчастных языка система не могла сожрать без глюков: Регионы глючили и глючили жестоко... И тут начался мой выход.

Первая попытка установить сайт на локальную площадку с треском провалилась. Мне искренне интересно, какой индусский программист указал для половины полей в каждой таблице not null default null ? Но на удивление это работало на "живом" сайте, и не работало у меня. Любая попытка что-то записать в базу падала на инсерте когда такие поля были не заполнены. А система ведь на продажу, должна запускаться везде, ага :) Признаюсь честно, я не осилил переколбасить все эти поля, успел только то, что касалось моей работы. И как только у меня это получилось полез в код. Тут меня ожидал большой сюрприз :)

Как известно, многие продукты, которые выставляются на продажу пишутся на функциях без ООП. Это делается для того, чтобы система действительно работала абсолютно везде, при любой сборке php и на любом сервере. Если это не учитывается - строится мощная объектно-ориентированная архитектура приложения, все абстрагируется, пишутся требования к серверу и т.п. Но не тут. Действительно нет. Разработчики iLance настолько крутые ребята, что используют ООП в лучших традициях Индии. Первым делом я встретил антипаттерн God Object. Объект $ilance действительно настолько крутой что управляет и переменными реквеста, одновременно он и шаблонизатор и хранит настройки и вообще (я до многого не добрался, тут все его фичи описать не могу). Есть у объекта-бога и пару приспешников - объекты  некоторых сущностей (функционально это не объекты вообще, а статические либы),  некоторых  означает примерно 10% сущностей, все же остальное хранится в файле с функциями на 4 тысячи строк и тотальной копипастой.

К слову об объектах. В php никогда не было толком никаких соглашений. Да, были попытки, но такого явного как скажем в java чтобы только camel hump и все, не было. И каждый мог выбрать то что ему нравилось. Но называть классы с маленькой буквы через подчеркивание, увольте.

А ужас нарастал. Вместо хоть какой-нибудь пародии на контроллеры и хотя бы уже черт с ним я бы смирился, чтобы отдельная страница отрисовывалась в отдельном php-файле без классов и функций. Пусть говногод ну да и ладно, в одном месте хотя бы, а значит - разобраться можно. Вместо этого меня встретили файлы по 3-5 тысяч сторок php кода, в очень редких местах были вызовы функций из либ (примерно таких же по объему и каше). Копипаста наполнила проект чуть более чем полностью. Некоторые записи вставляются через либы, а апдейтятся тут же через sql-ник. Кстати, очень много sql-ников и никакой абстракции под их генерацию даже для простейших тупых запросов из серии select * from table where че_то_там. Рендеринг страниц с помощью шаблонизатора идет вперемешку с расово индусским спагетти-кодом.

Кстати о шаблонизаторе. В iLance он есть, но лучше бы его не было. Все что он умеет - это условия (if-else) и циклы (loop). Кстати, я так и не нашел как же в цикл вставить условие :) а все потому, что эти шаблоны никуда не транслируются. Обычно ж как, если есть псевдоязык - он транслируется в php файлик, который затем каждый раз подключается (чтобы не транслировать его еще раз) и уже по внутренностям этого файла можно догадаться о том как нужно писать в шаблонах чтобы оно работало. Но сохранения результатов нет, они есть в памяти черт знает где и потом по всему этому счастью происходит eval. Вот так-та.

Казалось бы, что уже после всего, что я увидел, сложно наляпать еще где-то. Я искренне в это верил пока не узнал как в iLance происходит работа с css. Надо отметить что во всех проектах, с которыми я работал (а это порядка 80 штук от самых мелких до монстров) я не встречал такого. Разработчики iLance действительно гении, они первые придумали хранить стили в базе данных! Нет, они не хранят там целые файлы стилей, это было бы еще полбеды. Каждый css-класс - это запись в базе. Имя записи к примеру .blog и код стиля padding: 0px; к примеру. А потом это все собирается в css-ку, которая ложится в кеш и подключается при запуске страниц. Редактирование этого всего - только через админский интерфейс. А в нем мегафишка! : область видимости стилей можно указать. Например можно чтобы определенный стиль был и в админке и на фронте, а другой только на фронте. Почему нельзя было сделать 3 файла скажем global.css, front.css и admin.css, как делают все нормальные люди? Да потому что там есть подсказки для стандартных стилей, наверное для того чтобы люди непросвященные в css легко могли добавлять и менять там что-то свое. Возможно, разработчики и не знали, но мы то точно знаем, что ни один нормальный человек, который в этих ваших стилях ничего не понимает никогда в жизни не попрется туда что-то править, а если уже человек решил разобраться в css, то в самих файлах ему будет куда проще (хотя бы потому что все доки именно по .css-файлам, а не по хренпойми чему), не говоря уже о профессиональных верстальщиках, которые скорее всего и будут делать редизайн в случае чего.

Подводя итоги моей работы с ее величеством iLance CMS хочу отметить, что, хотя она и ужасная внутри, работать с ней можно. Если ничего не нужно менять - работать она будет как 95% аналогичных систем по всему интернету. Парням из iLance искренне хочется пожелать хотя бы иногда включать мозг и прочитать пару книжек по ООП, их менеджерам - никогда не нанимать студентов, тем, кто прочитал эту статью и думает работать с этим или нет, подсказать уже нечего - вы и так молодцы, что не ограничиваетесь только тем что пишут на сайте самой cms-ки о ней, ну а программистам - никогда не повторять этих ошибок.


Страница сайта http://test.interface.ru
Оригинал находится по адресу http://test.interface.ru/home.asp?artId=26128