1. Как быть с лицензией? Как она будет сама подцепляться, если надо пересобрать и оттестировать всю систему? И фраза " Перейти на страницу Обновление платформы" из документации, вообще у них разорвала все шаблоны. Обновление в работающем продуктовом контейнере?!
Для обновления функционала изнутри контейнера, чтобы встроить это в пайплайн можно использовать CLI команду встроенную в продукт "update:modules", с её помощью можно запускать обновление только до конкретных указанных версий (типа как composer.json, только updates.json).
Детальной документации на эту команду к сожалению пока что нет, можете с помощью встроенного в команду хелпа посмотреть примеры использования.
2. Как быть с шаблонами сайтов? На github не увидели документации.
А какая с ними проблема? Они также являются частью исходного кода проекта и живут рядом с остальными исходниками.
3. Ссылку на официальный форум по контейнерному решению не нашли на сайте 1С-Битрик Разработчикам.
Передал информацию коллегам.
Также стоит упомянуть, что различные проблемы и предложения лучше сразу оформлять в виде issue или pull request в самом репозитории. При таком подходе и проблемы и их решения будут ближе к коду и можно будет предметно разговаривать.
По хорошему ваши пожелания нужно озвучить в поддержку, чтобы они зафиксировали ваше обращение в качестве заявки на фичу (а возможно и добавили в уже существующее), и чем больше будет обращений на одну тему, тем сильно больше вероятность, что мы начнём делать её ;-)
Да, команды работают на базе пакета symfony/command, но в поставке этот пакет не поставляется, нужно установить зависимость через композер, по ссылке выше есть инфа на этот счет.
Внутри продукта константа всегда true если подключен файл пролога main/include/prolog_before.php , но никогда не знаешь, чего можно ожидать от кастомных интеграцией :)
Тут скорее правильней задать вопрос вопрос про популяризацию CMS в целом, т.к. планов отчуждать отдельно фреймворк на текущий момент нет.
Данный блог мы как раз используем как один из инструментов общения с разработчиками и популяризации продуктов компании, в частности и фреймворка.
Также ведутся работы по переработке документации конкретно по фреймворку и CMS, чтобы документация стала более френдли к разработчикам.
Плюс не прекращается регулярная доработка ядра продукта, внедряем новые инструменты и технологии. В качестве спойлера могу сказать что в этом году подвезём пару-тройку хороших нововведенией, которые вероятно многие долго ждали ;-)
Не очень понял, что имеется в виду. forSql используется в SqlHelper, фактически, только один раз, для реализации convertToDbString.
В любом случае, нет ни одной причины использовать forSql вместо convertToDb где бы то ни было.
Один раз, зато какой :) Тут я имел ввиду сам класс как кейс использования forSql.
Если говорить про конструирование SQL запросов без ORM, даже банальных LIKE конструкций, то convertToDb не подойдёт, и там нужно использовать только forSql :
$sql = "WHERE name LIKE '%" . $sqlHelper->forSql($value) . "%'";
Ну так он и должен быть на две строки. Если больше, то надо вынести формирование запросов в отдельные методы. Тогда любой код транзакции будет содержать столько строк, сколько в ней запросов. Плюс "на простыне кода разница уже не будет заметна", и функция не нужна - так себе аргумент.
С таким примером соглашусь, что наличие замыкания имеет смысл и будет удобно.
Я не очень люблю когда в качестве аргументации приводят очень простые примеры, которые чаще всего далеки от жизни, поэтому не упустил возможности указать на это :) Саму реализацию через коллбэк возьмём на заметку и возможно реализуем, спасибо!. Насколько знаю уже во всех фреймворках и ORM такая история есть, не будем отставать от устаревающих трендов :)
Тут вполне можно было согласиться, что да, такой метод в Битриксе не помешал бы
Если со всем соглашаться, то времени не хватит ни на ответы, ни на реализацию, поэтому приходится достаточно консервативно подходить ко всему новому :D
Такой экзотики из коробки нет :) В данном случае можно добавить свое поле:
Кастомное поле
use Bitrix\Main\ORM\Fields\ScalarField;
abstract class Geometry
{}
class GeometryField extends ScalarField
{
public function cast($value)
{
if ($this->is_nullable && $value === null)
{
return null;
}
if ($value instanceof Geometry)
{
return $value;
}
return Geometry::createFromWKT($value);
}
public function convertValueFromDb($value)
{
return $this->cast($value);
}
public function convertValueToDb($value)
{
if ($value === null)
{
if ($this->is_nullable)
{
return null;
}
throw new Exception('Is not nullable');
}
if ($value instanceof Geometry)
{
return $value->toWKT();
}
throw new Exception('Invalid value');
}
}
Конкретно с JSON справляется: можно использовать поле Bitrix\Main\ORM\Fields\ArrayField , при сохранении/чтении будет выполнятся преобразование данных в/из JSON.
Про работу с бинарными данными в статье упоминание есть.
На счет "прочих типов", тут уже нужна конкретика :)
Удивился, полез посмотреть, и действительно, на самом деле выполняется более логичный запрос с LIMIT 0.
Действительно, опечатка в статье. Спасибо!
Всё-таки, слово "подготовленный" имеет строго определённое значение. Здесь лучше подойдёт "отформатированный".
Верное замечание, убрал по тексту использования термина, чтобы не путать умы юнных читателей :)
и видимо поэтому показаны максимально невнятно, и без исходника в них разобраться довольно сложно
Раскрыл использование методов convert* детальнее ;-)
Спасибо, кстати, некоему А.В.Шаталову за то что код можно нормально посмотреть. Самому Битриксу это, судя по всему, не нужно.
Зачем, если исходники у нас всегда под рукой? :) Если серьезно, то проблема с докой и справочником API известная, мы ей занимаемся!
Судя по всему, автор статьи сам не понимает, что делает метод convertToDb, и почему его всегда следует предпочесть методу forSql
Завидую вашей способности читать чужие мысли, но в данном случае это лишь вопрос неверной терминологии, а не непонимания)
Не всегда стоит использовать convertToDb , вместо forSql . В целом сам класс SqlHelper , является хорошим примером когда стоит использовать forSql .
Если мы говорим про клиентский код, то тут да, почти всегда нужно использовать метод convertToDb , либо его конкретные реализации.
Вот эта привычка молча обрезать строку по длине наверняка подпортила нервов не одному поколению программистов: они думали что данные записались норм - ошибок ведь не было - а потом через полгода выплывает, что там какие-то обрезки.
Надеюсь мы оба понимаем, что это неправда ;) Обрезка происходит не "молча", а только в случае указания длинны в методе convertToDbString , либо при указании размера в ORM в некоторых классов Bitrix\Main\ORM\Fields\* .
В случае ORM, вместо указания размера и обрезки, можно использовать Bitrix\Main\ORM\Fields\Validators\LengthValidator
И снова термин, который во всём остальном мире означает одно, а в битриксе - что-то совсем другое.
Более подходящего термина к сожалению не нашлось, т.к. в любом случае это именно подготовка SQL запроса.
... Но при этом что именно другое - в статье не объясняется!
Очень жаль, что вы не заметили блок кода который следует сразу за этой фразой :(
И никто не догадался сделать простую онанимку
Пока вы пишите простой код на 2 строки, то действительно выглядит лучше. Если речь уже про более большие куски кода, что замыкание, что try/catch выглядят одинаково ;)
Для обновления функционала изнутри контейнера, чтобы встроить это в пайплайн можно использовать CLI команду встроенную в продукт "update:modules", с её помощью можно запускать обновление только до конкретных указанных версий (типа как composer.json, только updates.json).
Детальной документации на эту команду к сожалению пока что нет, можете с помощью встроенного в команду хелпа посмотреть примеры использования.
Подробнее про Bitrix CLI можно посмотреть туц: https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=11685
А какая с ними проблема? Они также являются частью исходного кода проекта и живут рядом с остальными исходниками.
Передал информацию коллегам.
Также стоит упомянуть, что различные проблемы и предложения лучше сразу оформлять в виде issue или pull request в самом репозитории. При таком подходе и проблемы и их решения будут ближе к коду и можно будет предметно разговаривать.
По хорошему ваши пожелания нужно озвучить в поддержку, чтобы они зафиксировали ваше обращение в качестве заявки на фичу (а возможно и добавили в уже существующее), и чем больше будет обращений на одну тему, тем сильно больше вероятность, что мы начнём делать её ;-)
Прямо сейчас вы самостоятельно можете зарегистрировать свои роботы через REST и навешивать на них необходимую функциональность: https://apidocs.bitrix24.ru/api-reference/bizproc/bizproc-robot/index.html
Если гибкости реста не хватает для облака, то тут уже стоит задумать про перевоз клиента в коробку.
Как видите на вашу проблему есть как минимум 2 решения прямо сейчас, нужно проявить лишь чуть больше прыткости :)
Да, команды работают на базе пакета
symfony/command, но в поставке этот пакет не поставляется, нужно установить зависимость через композер, по ссылке выше есть инфа на этот счет.Уже вышли в main 24.100.0
Внутри продукта константа всегда
trueесли подключен файл прологаmain/include/prolog_before.php, но никогда не знаешь, чего можно ожидать от кастомных интеграцией :)Начиная с версии main,24.0.0 вы можете регистрировать свои команды через конфигурацию модуля ;-)
Дока: https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=11685
Поверите если скажу что это действительно в работе? :-)
Тут скорее правильней задать вопрос вопрос про популяризацию CMS в целом, т.к. планов отчуждать отдельно фреймворк на текущий момент нет.
Данный блог мы как раз используем как один из инструментов общения с разработчиками и популяризации продуктов компании, в частности и фреймворка.
Также ведутся работы по переработке документации конкретно по фреймворку и CMS, чтобы документация стала более френдли к разработчикам.
Плюс не прекращается регулярная доработка ядра продукта, внедряем новые инструменты и технологии. В качестве спойлера могу сказать что в этом году подвезём пару-тройку хороших нововведенией, которые вероятно многие долго ждали ;-)
Отсутствия адекватного инструмента, это прям сильно тормозящий фактор :/
Неужели вендоры Android и iOS не могут дать нормальной тулзы?
Они хотя бы делают что-то в этом направлении? :D
Этот набор компонентов используется только для REST приложений, он коррелирует с имеющейся библиотекой внутри продукта.
Это был пример когда нужно вшивать какой-то кусок в какой-то SQL.
При желании можно использовать и
convertToDb:Один раз, зато какой :) Тут я имел ввиду сам класс как кейс использования
forSql.Если говорить про конструирование SQL запросов без ORM, даже банальных LIKE конструкций, то
convertToDbне подойдёт, и там нужно использовать толькоforSql:С таким примером соглашусь, что наличие замыкания имеет смысл и будет удобно.
Я не очень люблю когда в качестве аргументации приводят очень простые примеры, которые чаще всего далеки от жизни, поэтому не упустил возможности указать на это :)
Саму реализацию через коллбэк возьмём на заметку и возможно реализуем, спасибо!. Насколько знаю уже во всех фреймворках и ORM такая история есть, не будем отставать от устаревающих трендов :)
Если со всем соглашаться, то времени не хватит ни на ответы, ни на реализацию, поэтому приходится достаточно консервативно подходить ко всему новому :D
Такой экзотики из коробки нет :) В данном случае можно добавить свое поле:
Кастомное поле
Конкретно с JSON справляется: можно использовать поле
Bitrix\Main\ORM\Fields\ArrayField, при сохранении/чтении будет выполнятся преобразование данных в/из JSON.Про работу с бинарными данными в статье упоминание есть.
На счет "прочих типов", тут уже нужна конкретика :)
Действительно, опечатка в статье. Спасибо!
Верное замечание, убрал по тексту использования термина, чтобы не путать умы юнных читателей :)
Раскрыл использование методов
convert*детальнее ;-)Зачем, если исходники у нас всегда под рукой? :) Если серьезно, то проблема с докой и справочником API известная, мы ей занимаемся!
Завидую вашей способности читать чужие мысли, но в данном случае это лишь вопрос неверной терминологии, а не непонимания)
Не всегда стоит использовать
convertToDb, вместоforSql. В целом сам классSqlHelper, является хорошим примером когда стоит использоватьforSql.Если мы говорим про клиентский код, то тут да, почти всегда нужно использовать метод
convertToDb, либо его конкретные реализации.Надеюсь мы оба понимаем, что это неправда ;) Обрезка происходит не "молча", а только в случае указания длинны в методе
convertToDbString, либо при указании размера в ORM в некоторых классовBitrix\Main\ORM\Fields\*.В случае ORM, вместо указания размера и обрезки, можно использовать
Bitrix\Main\ORM\Fields\Validators\LengthValidatorБолее подходящего термина к сожалению не нашлось, т.к. в любом случае это именно подготовка SQL запроса.
Очень жаль, что вы не заметили блок кода который следует сразу за этой фразой :(
Пока вы пишите простой код на 2 строки, то действительно выглядит лучше. Если речь уже про более большие куски кода, что замыкание, что try/catch выглядят одинаково ;)
Дизайн - сущность, дизайнить - процесс ;-)
UserStoryMapping тут не рассматривается, потому что он сильно хуже данных подходов? Кажется он самый попсовый :)
Ясно, понятно. В целом могли сразу ответить что сами не понимаете о чем пишите ;-)
Много буковок и ни одной картинки :( Диаграмма C4 это про системный дизайн или про архитектуру?
Можете в картинках привести пример: вот схемка архитектуры, вот схемка системного дизайна?
Или разница вообще не в схемках? :)
Спасибо за развернутый ответ!