В новом ядре жизненный цикл страницы не изменился. По сути новое ядро - это новая идеология разработки. При этом в продукте продолжает работать весь старый API. И добавляется новый API для разработки в новом стиле.
По возможности, постепенно, старый API должен стать чем-то типа адаптера. Для совместимости. А вся логика с соответствующим рефакторингом должна переехать в новое ядро. [spoiler]
Приложение, контекст
Приложение в терминах нового ядра - это объект, отвечающий за инициализацию ядра. Кроме того, приложение является базовой точкой входа (маршрутизатором) для обращения к глобальным сущностям ядра - соединение с источниками данных, управляемый кеш и т.п. Также приложение содержит глобальные данные, которые относятся к самому сайту и не зависят от конкретного хита. Т.е. приложение является неизменяемой частью, не зависящей от конкретного хита.
Любой конкретный класс приложения является наследником абстрактного класса Bitrix\Main\Application. Мы планируем поддержку как минимум двух конкретных классов приложения: Bitrix\Main\HttpApplication и Bitrix\Main\CliApplication. Конкретный класс Bitrix\Main\HttpApplication отвечает за обычный http-хит на сайте.
Приложение поддерживает шаблон "Одиночка". Т.е. в рамках хита существует только один экземпляр конкретного типа приложения. Его можно получить инструкцией
$application = Application::getInstance(); |
Любой конкретный класс контекста является наследником абстрактного класса Bitrix\Main\Context. Мы планируем поддержку как минимум двух конкретных классов контекста: Bitrix\Main\HttpContext и Bitrix\Main\CliContext. Конкретный класс Bitrix\Main\HttpContext отвечает за обычный http-хит на сайте.
Для того чтобы получить контекст выполнения текущего хита, можно воспользоваться кодом
$context = Application::getInstance()->getContext(); |
Контекст содержит в себе запрос текущего хита. Для того, чтобы получить запрос, можно воспользоваться кодом
$context = Application::getInstance()->getContext(); $request = $context->getRequest(); |
Запрос представляет собой экземпляр класса, являющегося наследником класса Bitrix\Main\Request. В случае обычного http-запроса запрос будет являться экземпляром класса Bitrix\Main\HttpRequest, расширяющего Bitrix\Main\Request. Этот класс является по сути словарем, предоставляющим доступ к парам "ключ-значение" входящих параметров.
Для того чтобы обратиться к входящему параметру, переданному методами GET или POST, можно использовать код
$value = $request->get("some_name");
$value = $request["some_name"]; |
$value = $request->getQuery("some_name"); // получение GET-параметра
$value = $request->getPost("some_name"); // получение POST-параметра
$value = $request->getFile("some_name"); // получение загруженного файла
$value = $request->getCookie("some_name"); // получение значения кука
$uri = $request->getRequestUri(); // получение запрошенного адреса
$method = $request->getRequestMethod(); // получение метода запроса
$flag = $request->isPost(); // true - POST-запрос, иначе false |
Исключения
В новом ядре используется механизм исключений. При этом под исключительной ситуацией (в которой может быть выброшено исключение) подразумевается нетипичная ситуация, при которой не имеет смысла продолжать выполнение базового алгоритма.
В новом ядре введена иерархия классов исключений, наследуемая от встроенного базового класса \Exception. Общая схема иерархии имеет вид:
\Exception Bitrix\Main\SystemException - базовый класс всех системных исключений Bitrix\Main\IO\IoException - базовый класс всех исключений файлового ввода-вывода Bitrix\Main\IO\FileDeleteException - исключение при удалении файла Bitrix\Main\IO\FileNotFoundException - отсутствие требуемого файла Bitrix\Main\IO\FileOpenException - исключение при открытии файла Bitrix\Main\IO\InvalidPathException - не корректный путь Bitrix\Main\Config\ConfigurationException - ошибка в конфигурации Bitrix\Main\Security\SecurityException - ошибка безопасности Bitrix\Main\ArgumentException - базовый класс исключений, связанных с входящими параметрами методов Bitrix\Main\ArgumentNullException - параметр должен быть не пустым Bitrix\Main\ArgumentOutOfRangeException - параметр вне допустимого диапазона Bitrix\Main\ArgumentTypeException - параметр не допустимого типа Bitrix\Main\DB\DbException - базовый класс для исключений БД Bitrix\Main\DB\ConnectionException - исключение при соединении Bitrix\Main\DB\SqlException - исключение при выполнении запроса Bitrix\Main\NotSupportedException - вызывается, если функционал не поддерживается Bitrix\Main\NotImplementedException - вызывается, если функционал должен поддерживаться, но пока не реализован Bitrix\Main\LoaderException - исключение в загрузчике Bitrix\Main\CustomException - базовый тип всех частных исключений |
События
В новом ядре несколько изменена система событий. Снижены требования к знаниям, которые должен иметь код, порождающий событие. Пример отправки события:
$event = new Bitrix\Main\Event("main", "OnPageStart");
$event->send(); |
foreach ($event->getResults() as $eventResult)
{
if ($eventResult->getResultType() == \Bitrix\Main\EventResult::ERROR)
{
. . .
}
} |
Автор текста: Алексей Кирсанов.
1)Текущие _дефолтные_ компоненты я так понимаю не будут переписаны ибо работы там непочатый край?
2)Когда будет доступно апи для чтения?
2) В документации? В исходных кодах уже доступно. Думаем о генерации из phpDoc.
Пароль от БД хранится в 2х местах bitrix/php_interface/dbconn.php - то что было до D7
И в bitrix/.settings.php
Поменял пароль от БД, получил проблему на 2 часа:
После замены пароля на БД и на dbconn.php, думал все, сменил пароль.
А не, система кричит что Bitrix\Main\DB\ConnectionException и указывает на ядро. И никакой подробной информации.
Ковырял весь ядро целых 2часа еще с нервами, потом нашел что пароль к бд дублируется еще в .setting.php файле на папке битрикс.
Теперь понимаю всю суть слова "руки из жопы" =))
С разработчиками действительно "весело" ))
Если бы не твой пост - меня ждало бы такое же увлекательное времяпрепровождение.
Как я тебе благодарен....
Ядро D7 живет и развивается, я продолжаю писать свой код в рамках старого api. И наши пути никак не пересекутся.
Ибо если для старого api все разжевано в соответствующем мануале, с примерами и советами разработчиков, то для нового ядра даже банальная операция превращается в увлекательнейший квест - что? как? куда?
Берем самые используемые операции. Получение списка элементов инфоблока с одновременным получением свойств элементов инфоблока.
То, что в старом api схематично CIBlockElement::GetList(Array(), Array(), false, Array(), Array("PROPERTY_*";));
Или, допустим, получение списка разделов инфоблока со значениями пользовательских свойств. Те, что UF_MY_OWN_PROPERTY и четвертым параметром в CIblockSection::GetList()
Такое впечатление, что об удобной реализации этих вещей в рамках нового ядра еще даже и не думали. А если думали и как-то это делается проще, чем запрос по одной таблице, составлении на основе полученных ID фильтра для другого запроса, то, может быть, сделать пост и об этом?
Чтобы уже можно было ваш спейс-шаттл под названием D7 как-то приспособить к повседневной практике программирования под 1С-Битрикс.
вот кстати обертка для старых методов, чтобы пользоваться ими в едином формате и с поддержкой всех старых полей
а почему AddHeadScript
не доступен для Application::getInstance() ?
вроде метод должен заменять global APPLICATION, а в итоге нет((