Идеи пользователя

Есть проблема при разработке используя git. Допустим мы создаем миграцию, которая создаст инфоблок Статьи и его ID будет равен 1. Далее мы выводим статьи через комплексный компонент Новости. Позже мы понимаем, что в нашем инфоблоке не хватает какого-то свойства, мы его добавляем в миграцию создания Статей, откатываем её и накатываем вновь. У нового инфоблока будет ID равный 2. И наш комплексный компонент Новости будет ругаться так как в нем жестко указан ID=1. Более того выкатим миграции на продакт и накатив их, мы получим id инфоблоков отличающиеся от develop. И ситуацию эту довольно трудно поправить. Предложение - либо дать возможность в CIBlock::Add дать возможность задать id инфоблока, либо переделать все шаблоны компонентов на поддержку указания не ID инфоблока, а его символьного кода

Так будет легче изучать недокументированные возможности,  порой это очень нужно

Пересчет цены сейчас происходит в двух трех случаях (из тех, что понятны посетителю):

• Добавление товара в корзину.
• Открытие страницы корзины (bitrix:sale.basket.basket)
• Открытие страницы заказа (bitrix:sale.order.ajax)
  

Если при добавлении в корзину вмешательство в расчет оптимальной цены возможно при знании только самого добавляемого товара, то при обновлении корзины это может быть недостаточно.

Примеры:

• Требуется учесть ценовое предложение (а соответственно и группу каталога), которые были выбраны той же (через событие OnGetOptimalPrice) процедурой выбора оптимальной цены еще при добавлении в корзину.
• Процедура пересчета цены позиции корзины может нуждаться в дополнительных данных, которые могут быть записаны в свойство позиции корзины (учитываем, что один и тот же товар в разных комбинациях свойств в корзине может появиться не один раз!).
  

В обоих случаях требуется ИД самой позиции и знание ИД товара здесь точно недостаточно, требуется контекст (конкретная позиция корзины).

Что сейчас есть

• CSaleBasket::UpdateBasketPrices. Метод используется в коде компоненты для обновления цены.
• Аналогичный метод CSaleBasket::ReReadPrice делает тоже самое для одного товара, и тоже без сведений о позиции корзины (он используется пока только при добавлении в корзину, так что может и не страшно).
• Так или иначе, все сводится к вызову провайдера каталога CCatalogProductProvider::GetProductData. Этот метод провайдера в состоянии получить BASKET_ID, но его туда не передают (это недоразумение обещано исправить).
• Уже сам провайдер вызывает метод CCatalogProduct::GetOptimalPrice и здесь информация о позиции корзины теряется (и разработчик отказался это исправлять).
• Само собой обработчику события OnGetOptimalPrice не может быть передана информация о позиции корзины
• Нормально пересчитать цену товара, уже добавленному в корзину, нельзя.
  

Какие есть костыли

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

Но зачем так делать, если можно сделать нормальный API?

Идея рождена по предложению сотрудника поддержки (обращение 500340).

Во всех методах Add, Update, Delete, сделать возможность отключать отработку событий OnBefore* и OnAfter*

По умолчанию конечно все должно срабатывать.

Было бы не плохо добавить последний параметр:

function Add2BasketByProductID(
  $PRODUCT_ID,
  $QUANTITY = 1,
  $arRewriteFields = array(),
  $arProductParams = false,
  $arFilterToCheckElementExistsRewrite = array()
)

и использовать его для проверки существования элемента перед выбросом исключения:
"NO_IBLOCK_ELEMENT".

Сейчас для этой проверки используется жесткий фильтр:
array(
"ID" => $PRODUCT_ID,
"ACTIVE" => "Y",
"ACTIVE_DATE" => "Y",
"CHECK_PERMISSIONS" => "Y",
"MIN_PERMISSION" => "R",
 )

Довеской кроме ID хочется управлять.

UPD Как я понял смысл минуса:
нецелесообразно. Хотите изменить - копируете функцию и меняете

Сейчас, когда мы в клиентских проектах используем собственные таблицы в базе данных и обращаемся к ним через $DB->Query() с запросами, на нас ругается автотест монитора качества, который запрещает использовать прямые запросы к базе данных.

Предлагаю либо сделать другой вариант обращения к запросу (скажем, RawQuery()), который монитором учитываться не будет, либо просто смотреть на часть FROM запросов и следить, не появится ли в них системная таблица.

Первое проще.

Предлагаю разработчикам Битрикс обновить требования к оформлению кода в соответствии с общими стандартами — http://www.php-fig.org/

Присоединяемся или «у нас тут своя атмосфера»?

PSR-0 — Автозагрузка
PSR-1-basic-coding-standard
PSR-2-coding-style-guide
PSR-3-logger-interface

Понравилась идея? Напиши о ней в twitter!

Если хотите поставить минус, пожалуйста объясните вашу позицию в комментарии.

а если бы во всех штатных компонентах, да и в ядре не использовались бы стaтические методы - это жалкое подобие ооп,
а везде вначале создавался объект, тот же СiblockElement   например и с ним шла работа

И

лежал бы гденить каталог, в котором КАЖДЫЙ класс типа

т.е. все классы наследовались бы  от системных классов(которые менять нельзя - часть ядра),
а сам этот каталог чтобы НЕ ЯВЛЯЛСЯ ЧАСТЬЮ ЯДРА,   (ну или не каталог, а 1  файл со списком всех классов -пустышек - не суть как организовать )
т.е. если мне нужно переопределить какие методы в СiblockElement  то я в нём бы переопределил, или добавил свои методы, и во всём ядре, во всех компонентах это бы работало

тут конечно нужно потходить с умом, чтобы при обновлении допустим структура бд может поменять или ещё  что ... но в целом, была бы сама ВОЗМОЖНОСТЬ  это делать...
очень часто помогла бы я думаю

как думаете?

В ходе расширения имеющегося функционала иногда нужно изменить запрос.
Например CIblockElement::GetList - добавить к нему свои таблицы. В данный момент есть вариант лишь выноса (модифиация не рассматривается) данной функции в новый класс, который будет расширять имеющийся (extends) CIblockElement. Но тут необходимо создавать кастомные компоненты и везде заменять CIblockElement:GetList на (например) CCustomIblockLement::GetList.
Это все опять же внесет свои коррективы при установке модуля, такие как копирование шаблонов компонентов в кастомизированные и др., что для пользователя сложно.

В последнее время стал очень популярный редактор, много обсуждений на хабре и прочее. В принципе очень удобный и хороший. Почему бы не написать, сниппеты для данного редактора для удобства программирования, весь API Битрикса перенести в него. Будет удобно как и разработчикам самого Битрикса так и партнером и простым людям... улучшиться качество и меньше ошибок

Создайте наконец функцию,что бы она была в ядре, вывода массива заключённого в тэги <pre>

Что-то типа:
Я более чем уверен, что все разработчики скажут ВАМ огромное спасибо!

Сортировка по ИМЕНИ, если имя является числом, в общем-то в любом софте, работает в порядке:
0
...
9
10
...
19
20
...
29
и т.д.
В БУС сортировка по имени работает
1
10
11
12
...
2
20
21
и т.д.

Проблематично, когда имя элемента или раздела это число, или начинается с числа.
1. Неудобно когда необходимо сформировать и не дай Бог выгрузить список в файл.
2. Препятствует при реализации на базе БУС многих задач, особенно задач связанных с автоматизацией, а так же при интеграции с иным софтом или оборудованием.

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

1. Разработка системы зашла в тупик
2. Очень нелогичные решения банальных задач, вводящие в заблуждение разработчиков (чего одно меню только стоит)
3. Напрочь отсутствуют стандарты форматирования кода
4. Совершенно отсутствуют общепринятые в мире стандарты написания кода (свой огород, ага?)
5. Много маркетинга - ноль практической части
6. Абсолютное отсутствие какой-либо оптимизации. В коде видно, что написано абы-как лишь бы быстрее и максимально глупым способом (Например для меня было удивлением, что разработчики понятия не имею что такое тип Boolean).
7. Безосновательные утверждения что "в битрикс работают специалисты", вводящие в заблуждение пользователей (на основе пунктов выше)
8. Про системы контроля не искал, но уверен что если и есть, то что-то типа svn с горой костылей
9. Неправильный html вообще - валидация отсутствует, наслушались Лебедева?

В России так плохо с программистами? Некому совсем работать?
Ощущение что разработкой занимаются студенты (что подтверждает обилие кэпс-лока) без опыта работы, знающие исключительно теоретическую часть, которая далека от реальности

Почему любая OpenSource CMS лучше в разы? Не за 2 копейки ж продаются услуги, можно было бы толковых разрабочиков нанять на пару месяцев, да привести в порядок все...

Предложение:
1. Найти людей
2. Переписать с нуля используя php 5 (да-да, php 4 не актуален, уже давно php 5.4 вышел; про отличия 5.3 от 5.2 и 5.2 от 5, тут, думаю, бессмысленно писать, все-равно не услышат)
3. Позиционировать как Bitrix 2.0
4. Написать нормальную документацию на английском языке. При этом все ввести стандарты форматирования исходного кода
6. Познать ООП, MVC (это страшные слова на первый взгляд, после изучения что это такое, становится понятно)
7. Познать принцип "не повторяй!", код повторяется миллион раз

Собственно необходим инструмент миграции между версиями работающего сайтаНужен класс миграции с методами update и down
в которых разработчик будет описывать изменения с базой

По типу как это реализовано в Доктрине например.

Реализовать поддержку сервиса https://flattr.com/ для элементов инфоблоков