IPB 3.0.0 - Вышел новый движок. Разбор структуры ядра.

[never-never]

Странно, недавно вышел новый релиз IPB 3.0.0 (с открытым кодом без IC) - а ни форума, ни отдельной ветки по предварительному обсуждению нового творения от IPB нет.

*Если тема не уместна здесь - просьба модераторов пристроить ее в нужном по их мнению разделе.

 

Признаться честно - весьма долго и не без интереса ждал новый релиз эры IPB 3.0 - в том смысле, что томил интерес - куда будет двигаться IPB дальше и что будет за ядро движка, ибо у конкурентов в лице VB уже давно тянется релиз серии (3.)

Очень было интересно - чем же ответит МЭТТ.

 

 

Поверхностные впечатления:

 

Вчера установил себе IPB 3.0 и долго изучал структуру нового движка.

Если честно, то не ожидал от IPB того, что я увижу, ибо та же эволюция движка 1.3 --> 2.0 --> 2.1 --> 2.2 --> 2.3 хоть и имела кардинальные и отличительные перемены в структуре, начиная от полностью переписанных и видоизмененных функций, классических классов (class_session, class_display), задействования кеширования, последовательности подключения модулей, работы c TEMPLATES, а так же преобразование а супер класс $ipsclass-> -- все это имело некую зримую последовательность формирования и развития структуры.

Например можно было наглядно открыть движок 2.0 и 2.3 и несложным образом проследить изменения в видоизменениях структуры (например для правки модуля под новые версии IPB)

 

В IPB 3.0 можно смело забыть про то, что было раньше.

СТРУКТУРНОЕ ЯДРО ПЕРЕПИСАНО ПОЛНОСТЬЮ.

 

Когда я открыл index.php - задался вопросом... а IPB ли это?

 

define( 'IPB_THIS_SCRIPT', 'public' );
require_once( './initdata.php' );

require_once( IPS_ROOT_PATH . 'sources/base/ipsRegistry.php' );
require_once( IPS_ROOT_PATH . 'sources/base/ipsController.php' );

ipsController::run();

exit();

 

Это для примера полный код файла index.php

 

 

Копая структуру движка дальше и пытаясь уловить последовательность работы новой логики в структуре ядра - удивление лишь возрастало. Хотя некоторые отголоски от 2.3 и остались, начиная от некоторых построений функций, логики в классах, SQL запросов, но это лишь ОТГОЛОСКИ...

Множество новых функций, модулей и современных возможностей от PHP 5.0

Полностью переписанная админ панель и принцип распределения permissions + многое другое.

 

Скажу одно - IBP 3.0 это абсолютно новый и ничем не похожий на предыдущие релизы продукт.

 

Время безусловно расставит все на свои места и покажет УЛУЧШИЛО ли данное решение в моделировании нового ядра IPB 3.0 или наоборот все УСЛОЖНИЛО.

Да, новый движок несет в себе не мало новых функций, внешне красив и привлекателен + имеет более расширенный функционал - но БУДЕТ ЛИ ОН ТАК ЖЕ ПРАКТИЧЕН как предыдущие релизы... будет ли он УДОБЕН И ГИБОК для МОДЕЛИРОВАНИЯ и трансформаций. В этом аспекте я пока не берусь судить, ибо надо более глубже изучать структуру.

 

Я отношусь к тем людям, которые не обращают внимание на ВНЕШНИЕ ФИШКИ - для меня они вторичны.

Для меня больше важна гибкость внутренней структуры... просто иногда когда заглядываешь в структуру кода ВНЕШНЕ КРАСИВОГО ДВИЖКА - ХОЧЕТСЯ ПЛАКАТЬ (Битрикс тому подтверждение).

Посему про IPB 3.0 мне пока сложно объективно судить.

 

Читая первые отзывы на официальном сайте - я нашел не мало не лестных отзывов и не довольных людей новой структурой движка. Многие отмечают запутанность и громоздкость новой структуры, но это лишь поверхностное восприятие, которое в основном будет касаться сложностей для разработчиков модулей/хаков для нового IPB 3.0, а не обычных пользователей.

Но суть в том, что как известно за функционал и автоматизированные возможности для ленивых - надо будет платить скоростью и снижением "поворотливости" в работе.

 

Поживем - увидим.

 

 

P.S.: Просьба тех, кто уже имел возможность узреть новую структуру кода IPB 3.0 - поделиться своими впечатлениями, размышлениями и соображениями...

Что на первый взгляд понравилось, что нет. (не внешне, а ВНУТРЕННЕ)

Особенно интересно мнение людей, которые написали не один модуль/хак для IPB.

[MiksIr]

Это не хуки, это обычное наследование. Хорошо при написании своего продукта используя форум как фреймворк, и то только если нормально все разбили на методы (а если "как обычно", многоэкранные методы - то в сад таких пограммистов). Не очень хорошо для написания модулей, которые, к тому же, еше и кем-то отдельным инсталируются.

[Song]

Форум для ленивых админов, которые с таким продуктом будут деградировать дальше и дальше.

Производительность упадёт ещё больше.

[GiV]

Это не хуки, это обычное наследование. Хорошо при написании своего продукта используя форум как фреймворк, и то только если нормально все разбили на методы (а если "как обычно", многоэкранные методы - то в сад таких пограммистов). Не очень хорошо для написания модулей, которые, к тому же, еше и кем-то отдельным инсталируются.

А под настоящими хуками мы понимаем сигналы?

[GiV]

Не очень хорошо для написания модулей, которые, к тому же, еше и кем-то отдельным инсталируются.

Ну модуль в терминологии IPB 3 это отдельное приложение с набором всех причиндалов (в том числе и хуков). Вроде модуль ядра, модуль форумов, пользователей, календаря, блогов и тп.

 

А "хук" в ИПБ это больше изменение стандартного поведения чего-либо внутри модуля. В общем что-то крайне не значимое. В виде вывода списка похожих тем внизу страницы темы. Так что тут скорее не чистое наследование, а еще и примешанный полиморфизм (хотя в ООП все его каноны идут рука об руку =) ).

 

Лучше скажите в чем потайной смысл использования рефлексии во фронт контролере ips. Что-то я там особой магии необходимой для применения рефлекшена не нашел. Не туда смотрел?

[MiksIr]

А под настоящими хуками мы понимаем сигналы?

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

[GiV]

По поводу сигнальной структуры хуков ИПС обрекло это дело по причине: "будет необходимо поддерживать точки вызова хуков ака fireevent, добавьте мне здесь, мне не хватает тут". А если дать возможность изменять реализацию, то соответственно этой проблемы уже нет, но появляются другие =)

[MiksIr]

"Дали возможность" =) На самом деле "забрать" эту возможность можно только одним способом - написанием говноклассов =) Чем тщательнее все разбито на методы, тем легче писать что-то свое.

 

Правда, даже если забыть о гиморе с инсталляцией таких модулей (исходные файлы форума все-равно править придется - класс переименовывать, а если там есть автолоадер - то и сам файл), тут еще один подводный камень. Требуется неукоснительное сохранение интерфейсов всех классов от версии к версии... извините, я в это не верю... особо в случае с IPS. Хуки, да, пришлось бы рассматривать заявки на добавление новых, но зато уж добавил - так добавил, хранить неизменное API в виде хуков легче.

[WildRAID]

Потихоньку собираю первые хуки и пишу "приложение".

 

Конечно же, довольно непривычно. Постоянно приходится лазить по ядру и искать функции, которые делают за тебя всю "грязную работу". Если раньше прямо посреди компонента можно было писать какое-нибудь низкоуровневое копание в переменных, то теперь как-то неприлично.

 

Вообще, довольно здорово. Когда натаскаешься, скорость разработки должна заметно повыситься.

[GiV]

Постоянно приходится лазить по ядру и искать функции, которые делают за тебя всю "грязную работу".

Сказывается недостаток документации.