Новое ядро продукта строится на принципах ООП с применением всех возможностей, имеющихся в PHP версии 5.3 (минимальные технические требования).
Модули, пространства имен и API
Продукт остается модульным. Модули располагаются в системной папке /bitrix/modules. Кроме того, появляется еще одна значимая папка /local/modules, в которой могут располагаться пользовательские модули. Такое разделение позволит сторонним разработчикам просто организовать контроль версий своих разработок с сохранением обновляемости продукта стандартной системой обновлений. [spoiler]
API (классы, логика) модуля в новом ядре располагается в подпапке /lib папки модуля.
Новое ядро вводит в продукт понятие пространств имен. Это позволяет давать элементам системы более четкие имена, избавиться от множества префиксов имен, а также избежать потенциальных конфликтов. Все классы, поставляемые в стандартном дистрибутиве, должны находиться в пространстве имен Bitrix. Каждый стандартный модуль определяет в пространстве имен Bitrix свое подпространство, совпадающее с именем модуля. Например, для модуля forum пространством имен будет Bitrix\Forum, а для модуля main - Bitrix\Main.
При необходимости модуль может организовывать подпространства внутри своего пространства имен. Например, Bitrix\Main\IO, Bitrix\Forum\Somename\Somename2. Но такой возможностью следует пользоваться только если это оправдано для организации правильной архитектуры данного модуля.
API (классы) модуля не делятся по базам данных. В названиях классов не должны использоваться какие-либо префиксы или суффиксы.
Каждый класс API модуля может лежать в отдельном файле с названием, совпадающим с именем класса, написанном в нижнем регистре. Классы, лежащие к корне пространства имен модуля, должны быть расположены в файлах, лежащих в корне папки /lib модуля. Классы, лежащие в подпространствах внутри пространства имен модуля, должны быть расположены в файлах, лежащих в соответствующих подпапках папки /lib модуля.
Например, класс Bitrix\Main\Application должен быть расположен в файле /lib/application.php относительно корневой папки модуля main, класс Bitrix\Main\IO\File должен быть расположен в файле /lib/io/file.php относительно корневой папки модуля main, класс Bitrix\Forum\Message должен быть расположен в файле /lib/message.php относительно корневой папки модуля forum.
При соблюдении этих правил именования после подключения модуля его классы подгружаются автоматически при первом обращении к ним. Никаких дополнительных действий для регистрации и подключения файлов с классами не требуется.
Исключением из правил именования классов и файлов являются классы сущностей ORM (наследников класса Bitrix\Main\Entity\DataManager). Имена таких классы формируются с суффиксом Table. Например, CultureTable, LanguageTable. А имя файла не содержит суффикса table. Такие классы также подключаются автоматически.
Существует возможность вручную зарегистрировать класс в системе автозагрузки с помощью метода Loader::registerAutoLoadClasses($moduleName, array $arClasses). Это можно использовать для объединения маленьких классов в один файл.
Нестандартные классы (классы партнеров), должны находиться в пространствах имен, совпадающих с названиями соответствующих партнеров. Каждый партнерский модуль определяет в пространстве имен партнера свое подпространство, совпадающее с именем модуля без имени партнера. Например, для модуля mycompany.catalog партнера mycompany пространством имен будет MyCompany\Catalog. Остальные правила совпадают с правилами для стандартных модулей.
Для подключения модуля в новом ядре используется инструкция \Bitrix\Main\Loader::includeModule($moduleName);
Ошибки
В старом ядре API пытался додумывать за пользователя/разработчика, прощал ему ошибки и неточности. Результатом такого поведения обычно бывают сложно-отлавливаемые ошибки. К тому же такой подход порождает массу неявных соглашений, которые нужно знать.
Например, пользователь/разработчик выбирает записи для удаления по фильтру. При этом он случайно описывается в названии фильтра. Типичное API старого ядра проигнорирует этот фильтр и вернет все записи. Следующая инструкция эти все записи успешно удалит.
В новом ядре идеология меняется. API ничего не должен додумывать за пользователя. API должен адекватно реагировать, если он встречается с неожиданной для него ситуацией, такой как не знакомый фильтр, не передан id, не хватает значения, лишнее значение, не должно вызываться в этом режиме и т.д.
Исключения
В новом ядре используется механизм исключений. При этом под исключительной ситуацией (в которой может быть выброшено исключение) подразумевается нетипичная ситуация, при которой не имеет смысла продолжать выполнение базового алгоритма. Например, если пользователь отправил форму с пустым полем "Имя", то это - не исключительная ситуация. Это обычная ожидаемая ситуация, которая должна быть обработана соответствующим образом. Если же при вызове API-метода изменения элемента инфоблока был указан пустой id элемента, то это исключительная ситуация. Она не ожидаема и продолжать изменение элемента не имеет смысла.
Автор текста: Алексей Кирсанов.
А ведь еще совсем недавно, в лихих 90-х, операторы goto считались ересью
Эволюция страшная вещь.
Во-первых, о том почему goto в языках программирования само по себе это лютый п.. - можно найти 100500 объяснений в гугле.
Во-вторых, говорить так словно это ключевая особенность версии 5.3 - это создавать впечатление, что больше ничего интересного в 5.3 не появилось.
Вы как продукт - лидер отрасли, на вас люди смотрят. Зачем такую фигню писать? Будьте лидером, держите марку.
Далее, вы начали использовать неймспейсы, семантическое именование классов и автолоад (автозагрузку по именам). Молоды. Но
а) почему бы не сказать об этом прямо, используя соответствующие термины,
б) нафига изобретать велосипед с lib и local, когда есть composer с устоявшейся практикой именования.
А в целом поздравляю с релизом, событие хорошее само по себе.
Я спрошу на всякий случай еще раз: 2 ядра будут работать параллельно какое-то количество версий?
Как планируется переход?
Переход заключается в том, что старое API ядра постепенно будет превращаться в прослойку к новому, где это возможно и оправданно.
CModule::AddAutoloadClasses('', array( // ИМЯ КЛАССА => Путь к файлу, где его искать 'phpQuery' => '/bitrix/php_interface/phpQuery/phpQuery/phpQuery.php' ));Интересуюсь с целью понять а когда можно забить на обратную совместимость и писать по новому уже.
Или такого пока не предвидится?
новое ядро используется с 12 версии или что-то не так понимаю?
на 12,5 работает код
use Bitrix\Main\UserTable;
$res= \Bitrix\Main\UserTable::getList(array(
//"select"=>array("UF_STUD_ACT";),
'filter'=>Array()
));
));
что изменилось в 14-ой?
Что подразумевают high load инфоблоки, только хранение данных в своей таблице для блока или что-то еще?
загон инфоблока в свою таблицу есть на 12,5, возможно на 12
что в данном смысле привносится в 14?
например для файла /local/modules/my.test/lib/helloworld.php
namespace My\Test; class HelloWorld { . . . }как в данном виде заменить конструкцию вида:
if(!CModule::IncludeModule('iblock')){ ShowError("IBLOCK MODULE IS NOT INSTALLED"); return false; }Старое ядро:
if (!CModule:IsModuleInstalled('iblock'))if (!\Bitrix\Main\ModuleManager::isModuleInstalled('iblock'))$is_iblock_installed = \Bitrix\Main\Loader::includeModule('iblock'); if(!$is_iblock_installed){ ShowError("IBLOCK MODULE IS NOT INSTALLED"); return false; }