Структурно пока это отдельная глава курса Разработчик Bitrix Framework. Без тестов, без вопросов.
Работа над документацией по 14-ой версии ведётся, но тема нового ядра - особой важности, поэтому и спешим вам сообщить о выходе документации не откладывая.
Кстати да, откуда global, если декларируется отказ от них (или что то не так все поняли)?
Highloadblock подразумевает использование версии сервера MySQL 5.6 или что? Обязательно ли использование memcached или это условие ИЛИ? Очень мало информации.
И где примеры, примеры, примеры?
И что с производительностью?
"Пример компонента добавления записи в сущность Highloadblock"
Возникает вопрос, а где будут хранится значения полей, если используется $USER_FIELD_MANAGER?
Или $USER_FIELD_MANAGER - это просто структура и типизация полей, а все сущности и поля сущностей будут в таблицах Highloadblock?
Поддерживаются базы данных: MySQL (mysqli, Mysql), MS SQL, Oracle, NoSQL
Для MySQL поддерживается только драйвер MySQL Improved, который поддерживает ООП и имеет ряд других преимуществ.
Наверное, надо:
Поддерживаются базы данных: MySQL (MYISAM, INNODB), MS SQL, Oracle, NoSQL
Подправили.
"Пример компонента добавления записи в сущность Highloadblock"
Нашел ошибку
Любой конкретный класс приложения является наследником абстрактного класса Bitrix\Main\Application. Поддерживаются два конкретных класса приложения: Bitrix\Main\HttpApplication и Bitrix\Main\CliApplication, которые являются наследниками класса Bitrix\Main\HttpApplication, но реализуют несколько разную логику выполнения.
А надо
Любой конкретный класс приложения является наследником абстрактного класса Bitrix\Main\Application. Поддерживаются два конкретных класса приложения: Bitrix\Main\HttpApplication и Bitrix\Main\CliApplication, которые являются наследниками класса Bitrix\Main\Application, но реализуют несколько разную логику выполнения.
Когда можно будет пощупать?
Пример добавления обработчика события абсолютно не рабочий для своих сущностей.
Просьба поправить.
hint: при использовании кастомых\своих сущностней явно надо использовать не "main" в 1м параметре
$eventManager->addEventHandler
За обновление спасибо.
Нашел такой новый файл:
after_connect_d7.php
И еще был разговор, что хотят отказаться от:
<?require($_SERVER["DOCUMENT_ROOT"]."/bitrix/header.php" ) ; ?>
<?require($_SERVER["DOCUMENT_ROOT"]."/bitrix/footer.php" ) ; ?>
И, как следствие, от отложенных функций.
Так ли это? Или останется как есть?
понимать бы, в каких местах происходит "инъекция" нового ядра в старое.
к примеру, этот файл after_connect_d7.php когда подключается?
Пример неправильного форматирования:
$arArray = array(
"key1" => "value1",
"key2" => "value2",
);
Выше по тексту(1.2.4) предлагается форматировать массивы именно таким образом:
$arFilter = array(
"key1" => "value1",
"key2" => array(
"key21" => "value21",
"key22" => "value22",
)
);
А так судя по всему, куда более гибкое API будет и это круто. Ждем полного выхода всего нового!
Зачем это сделали? Табами ведь намного удобнее и гибче, каждый разработчик может настроить внешний вид кода "под себя" и настроить в своём редакторе нужное число пробелов для символа табуляции. Да и места меньше код занимает, один символ вместо нескольких.
По фтп намного быстрее зайти поменять текстовый файл, особенно когда сайт недоступен или выдает критическу ошибку в работе.
- Пространства имен должны должны именоваться "ВерхнимКэмелКейсом".
одно лишнее слово "должны".Надеюсь это только для программистов битрикса?
Я всегда ставлю блоки так:
if(...) { .... } else { .... }И считаю это более правильным.
if (...)
{
....
}
хотя в css использую сокращенную запись
.style {
color:red;
}
На вкус и цвет товарищей нет.
if (COption::GetOptionString("main", "new_user_registration", "N";) == "Y"
&& $_SERVER['REQUEST_METHOD'] == 'POST' && $TYPE == "REGISTRATION"
&& (!defined("ADMIN_SECTION";) || ADMIN_SECTION !== true)
$result2 = $connection->query($sql, $limit);
$result3 = $connection->query($sql, $offset, $limit);
$cnt = $connection->queryScalar("SELECT COINT(ID) FROM table";);
После обновления они перестали работать
Был модуль в папке modules, теперь же необходимо переносить свои модули в папку /local/modules, из описания кажется, что переносить надо в корень. Как теперь их подключать?
Что именно перестало работать? Обратитесь, пожалуйста, в службу технической поддержки для решения вашей проблемы.
или я что-то не так понял?
Я вот думал ставить в новых проектах использование папки local как стандарт де-факто...
Открывающая скобка должна ставится под соответствующим оператором и на одном отступе с ним. Закрывающая скобка должна ставится под соответствующей открывающей.
if ($condition) { ... }При установке курсора на закрывающую скобку, я увижу в подсказке только открывающую скобку "{".
Другой вариант:
if ($condition) { ... }И код во втором варианте получается компактнее.
Код не становится менее читаемым на мой взгляд.
Подсветка начала/конца блока работает одинаково хорошо в обоих случаях.
Принципиальной разницы никакой, только визуально или, как написал Александр, может влиять на подсказки IDE. К тому же любой вменяемый IDE сам понимает и выделяет блоки.
Такой стиль привил мне еще в лохматых годах автор небезызвестного языка C++ Бьярне Строуструп, который использовал именно такой стиль расставления блоков в своих книгах.
К тому же многие IDE по-умолчанию используют такой стиль и проставляют их автоматически.
Мне кажется использовать стиль по-умолчанию более логичным.
if($aaaaaaaaaaaa == 1111 || $bbdfsdf == 123213123 || $cvgc != 123123123 || $bbdfsdf == 123213123 || $cvgc != 123123123 || $bbdfsdf == 123213123 || $cvgc != 123123123 || $bbdfsdf == 123213123 || $cvgc != 123123123){ $cvgc = 123123123; $bbdfsdf = 123213123; $bbdfsdf = 123213123; $a = 2; }if($aaaaaaaaaaaa == 1111 || $bbdfsdf == 123213123 || $cvgc != 123123123 || $bbdfsdf == 123213123 || $cvgc != 123123123 || $bbdfsdf == 123213123 || $cvgc != 123123123 || $bbdfsdf == 123213123 || $cvgc != 123123123){ $a = 2; }if($aaaaaaaaaaaa == 1111 || $bbdfsdf == 123213123 || $cvgc != 123123123 || $bbdfsdf == 123213123 || $cvgc != 123123123 || $bbdfsdf == 123213123 || $cvgc != 123123123 || $bbdfsdf == 123213123 || $cvgc != 123123123) { $a = 2; }if ( $aaaaaaaaaaaa == 1111 || $bbdfsdf == 123213123 || $cvgc != 123123123 || $bbdfsdf == 123213123 || $cvgc != 123123123 || $bbdfsdf == 123213123 || $cvgc != 123123123 || $bbdfsdf == 123213123 || $cvgc != 123123123 ) { $a = 2; }разработчики Битрикса используют стиль one-true-brace,
мы у себя используем "trailing braces", при этом все счастливы
if ( $aaaaaaaaaaaa == 1111 || $bbdfsdf == 123213123 || $cvgc != 123123123 ) { $a = 2; }if ($aaaaaaaaaaaa == 1111 || $bbdfsdf == 123213123 || $cvgc != 123123123 ) { $a = 2; }if ( $aaaaaaaaaaaa == 1111 || $bbdfsdf == 123213123 || $cvgc != 123123123 ) { $a = 2; }Просачивается все же некая нестабильность, лукавлю, но все же))
if (true) { //body }зато благодаря ему:
- хочется сокращать условия, чтобы они были не двухстрочными
- не хочется писать длинные конструкции, т.е. пропадают ветвления, циклы и тд. на три-и-более экрана, т.к. они при таком написании не очень то читабельны.
но это плюсы, которые мне нужны, наверняка у вас тоже куча своих плюсов.
Как верно сказал Кирсанов Алексей - это вопрос религии, как больше нравится, и главное больше подходит по концепции - такой стиль и используем.
if ($aaaaaaaaaaaaa == 111 || . . .) { $a = 2; }А для стабильности лучше всегда писать так:
Там же есть и другие статьи.
У меня все еще есть вопросы:
1. Меня не устраивает система компонентов сейчас, и с введением класса - компонента в поддержку ядра, я уж было обрадовался, а когда на партнерке сказали что новые компоненты будут писаться как классы с публичными методами, которые можно переопределить при наследовании - так вообще подумал что вот оно счастье, но нет. Все новые компоненты (highload blocks, склады, новые компоненты для каталога) написаны так же простыней в файле component.php с кучей повторяющегося кода (типа проверок на дефолтные значения). Где же они эти классы - компоненты, от которых можно наследоваться и с сохранением обратной совместимости и поддержки пилить свои компоненты для заказчика ?
2. Так и не понял что в битриксе с приложением и контекстом ? Неужели так сложно запилить "одиночку" ? Или проблема в том что публичный админский интерфейс плохо работает (а точнее никак не работает) с любыми переменными хранящими объект приложения, кроме $APPLICATION ? Я как то попробовал сократить эту переменную до $app. Удобнее на много, но "Код вызова компонента не найден" при таком раскладе.
3. И конечно извечный вопрос - где документация с описанием интерфейса? Неужели только в исходных файлах ? Да любой OpenSource проект все равно имеет документацию по интерфейсу, не смотря на то что ее можно почитать в исходных файлах, а платный проект уж тем более должен иметь доку с передаваемыми переменными, типами переменных и типами возвращаемых значений. А так же желательно небольшой Hello World гайд по новому ядру, а не просто описание возможностей.
p.s.
4. Есть ли сейчас возможность унаследоваться от основного класса приложения, переопределить методы (или добавить свои) и вызвать его как основной объект приложения, без страха потери обратной совместимости ?