Пост по следам сегодняшнего поста про D7. В комментариях с Олегом вышел спор, где он доказывал надуманность нового подхода. Отчасти он прав. Вот простой ответ почему лучше приучать себя к новому стилю:
//наш правильный док.рут
echo $_SERVER["DOCUMENT_ROOT"];
//тут вставляем компонент новичка, который делает вот что (например, из-за ошибки новичка):
$_SERVER["DOCUMENT_ROOT"] = '/newpath';
//и вы к нему ниже радостно обращаетесь:
echo '<br/>';
echo $_SERVER["DOCUMENT_ROOT"];
//а наш "монстро-код" по-прежнему обработал нормально:
$context = \Bitrix\Main\Application::getInstance()->getContext();
$server = $context->getServer();
echo '<br/>';
echo $server->getDocumentRoot();
Надо какой-то единый стиль принять и использовать, чтоб еще форматтер помогал, а то не все места в форматтере PHPStorm получается настроить, приходится кодить и поправлять...
Когда я изучал ООП, там было написано, что Максимальная длина любой строки PHP-кода не должна превышать 120 символов , а когда познакомился с Битрикс вообще все стало мифом))
Сейчас да, опять надо вспоминать, че там, как там, какой длины.
Я даже CMS свою писал, как многие дураки, на ООП, в самом начале, когда ни капли опыта и вот прошло уже 3 года, так она в душе и живет, зараза))
Когда я изучал ООП, там было написано, что Максимальная длина любой строки PHP-кода не должна превышать 120 символов
Ну, во-первых, длина строки к ООП отношения не имеет, во-вторых, это правило придумали, когда больших мониторов еще не было, а в-третьих, никто не мешает разбивать эту строку на читаемые части.
use \Bitrix\Highloadblock\HighloadBlockTable as HL
$hlblock = HL::getList([
"filter" => [
'TABLE_NAME' => $arOneSKU['USER_TYPE_SETTINGS']['TABLE_NAME']
]
])->fetch();
Я кстати не проникся классами модуля HL-инфоблоков. Не вижу их плюсов (именно классов модуля).
Я делаю так:
- завожу HL-инфоблок (по сути это отдельная таблица)
- под эту таблицу создаю свой D7-класс автоматически (на данном моменте абстрагируюсь уже от HL-модуля)
- и уже со своим классом работаю
Что-то типа такого получается:
\Bitrix\Test\LogTable::waitNextTurn()
(классы складирую в php_interface в данном случае)
Ну и что изменилось, у меня монитор 1920 по ширине, 2015 год, ограничитель всегда стоит 120, вы думаете все разработчики сейчас с такими мониторами? Ничего подобного, не о ширине монитора речь.
Да мой, пример тоже очень сильно натянут, хотя можно, например, исходить из того, что разработчик ожидает расширение (array_merge) входящего параметра в get метод, а не полного его переопределения.
И да, новый стиль хорошо, однако он еще не в той кондиции, чтобы им реально можно было бы пользоваться. Плюс полное отсутствие Dependency Injection, сводит на нет его реальное использование, постоянно приходится делать пройслойки с помощью других Фреймворков (Речь идет про сложные проекты, а не про сайты взитки или витрины =) ).
Почему-то не могу комментить в блогах разработчиков, поэтому пишу здесь.
Насчет временной отсутствии документации.
В одном из проектов использовались свои таблицы и ORM для доступа к ним. Названия полей таблиц были набраны lowercase'ом, т.к. это банально удобнее маразма битрикса с повсеместным капсом. Все прекрасно работало до одного из обновлений месяц назад, где такие названия полей были запрещены в ядре (дописали strtoupper(field)).
А самое главное, лаконичный ответ техподдержки про ORM: "По сути, это не документированные возможности продукта, и пока они подвержены изменениям."
Но вот эта портянка меня больше всего напугала))
Прям в притирочку
Надо какой-то единый стиль принять и использовать, чтоб еще форматтер помогал, а то не все места в форматтере PHPStorm получается настроить, приходится кодить и поправлять...
Когда я изучал ООП, там было написано, что Максимальная длина любой строки PHP-кода не должна превышать 120 символов , а когда познакомился с Битрикс вообще все стало мифом))
Сейчас да, опять надо вспоминать, че там, как там, какой длины.
Я даже CMS свою писал, как многие дураки, на ООП, в самом начале, когда ни капли опыта и вот прошло уже 3 года, так она в душе и живет, зараза))
Я делаю так:
- завожу HL-инфоблок (по сути это отдельная таблица)
- под эту таблицу создаю свой D7-класс автоматически (на данном моменте абстрагируюсь уже от HL-модуля)
- и уже со своим классом работаю
Что-то типа такого получается:
\Bitrix\Test\LogTable::waitNextTurn()
(классы складирую в php_interface в данном случае)
//наш крутой разработчик использующий d7
$application = \Bitrix\Main\Application::getInstance()->getContext()->getServer()->set(['DOCUMENT_ROOT' => '/wup-wup']);
echo \Bitrix\Main\Application::getInstance()->getDocumentRoot();
// вывод: /wup-wup
Спасибо за пример!
Я в посте показал - что мол _может_ случиться ошибка. Не специально так новичок делает.
В вашем случае это целенаправленное изменение системы. Это не случайность.
В любом случае я был бы рад услышать более осмысленный ответ на вопрос сабжа. Мнения разработчиков разнятся везде.
И да, новый стиль хорошо, однако он еще не в той кондиции, чтобы им реально можно было бы пользоваться. Плюс полное отсутствие Dependency Injection, сводит на нет его реальное использование, постоянно приходится делать пройслойки с помощью других Фреймворков (Речь идет про сложные проекты, а не про сайты взитки или витрины =) ).
Насчет временной отсутствии документации.
В одном из проектов использовались свои таблицы и ORM для доступа к ним. Названия полей таблиц были набраны lowercase'ом, т.к. это банально удобнее маразма битрикса с повсеместным капсом. Все прекрасно работало до одного из обновлений месяц назад, где такие названия полей были запрещены в ядре (дописали strtoupper(field)).
А самое главное, лаконичный ответ техподдержки про ORM: "По сути, это не документированные возможности продукта, и пока они подвержены изменениям."
Очень даже красиво, опрятно и понятно даже новичку
ага,
а если в код добавить удаление папки с битрикс - то система как ни удивительно перестанет работать и D7 тут ничем не поможет