Всем привет. Текст состоит из двух частей:

  1. Небольшая шпаргалка, по параметрам настроек по умолчанию;

  2. Текст о том, почему вообще существование такой шпаргалки может кому то понадобиться.

Часть 1

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

  1. Создаем в корне модуля файл “default_option.php”

  2. В самом файле определяем массив:

/*
 * Файл local/modules/my_module_id/default_option.php
 */
<?
$my_module_id_default_option = array(
    "option_name"    => "default_option_value"
    );
?>

Название массива должно строится как ”${id_вашего_модуля"_default_option"}

  1. При использовании метода(D7):

<?
	$variable = Option::get("my_module_id", "option_name");
?>

или методов класса COption(старое ядро):

<?
  $variable  = COption::GetOptionString("my_module_id", "option_name");
  $intVariable  = COption::GetOptionInt("my_module_id", "option_name");
?>

передаем только два аргумента:

  • id вашего модуля

  • название параметра настроек.

   4. Названия параметра настроек должны быть идентичны, в файле option.php, default_option.php и конечно же при использовании методов класса Option или COption.


Часть 2

Надеюсь эта шпаргалка будет кому-нибудь полезна, потому как мне, она могла бы сэкономить почти два дня бесценного времени. И здесь, хотелось бы немного поговорить, о документации Битрикс.

Целями разговора не являются жалобы, укоры, упреки в адрес компании или разработчиков.

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

Сразу оговорюсь, что, я так называемый “вайтишник”, базовых и фундаментальных знаний нет. Я конечно же занимаюсь заполнением этих пробелов, но могу путать и не знать разницы между аргументами функции и параметрами. Да и в целом весь этот текст, является дилетантским. Поэтому, прошу неравнодушных к азам программирования, обсуждать не только уровень навыков и интеллекта автора, но и саму тему статьи. Заранее благодарю.

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

На первом же экране начинаются странности:

Вроде бы пока все хорошо. Но смущает непонятно откуда взявшийся id модуля “support”(больше он нигде нам так и не встретиться). Также обратим внимание на имена параметров в массиве, просто отметим что они есть, и как они называются.

Смотрим дальше:

Здесь нам говорят, что для работы с параметрами используется класс COption, правда ниже(цифра 4 на скрине), в одном из примеров, нам демонстрируют использование аналога этого метода из нового ядра Option::get(); С какой целью?

Ок. Дальше два примера методов этого класса, в которых id модуля уже называется почему то не “support”, как можно было бы ожидать, а “my_module_id”(цифра 1 на скрине).

В качестве имени параметра передается “MY_PARAMETER_ID”(цифра 2 на скрине), которого почему то нет в примере выше, в том самом массиве, из файла “default_option.php”

В примере метода get(), третьим аргументом указано значение параметра по умолчанию(цифра 3 на скрине), хотя если мы используем файл default_option.php, третий аргумент передавать не нужно, чтобы он “подтянулся” из массива $ID_модуля_default_option. На всякий случай, именно об использовании этой возможности и говорится в разделе “Параметры” этой страницы документации…

Исходя из этих примеров, лично у меня, возникает несколько вопросов:

  1. Какой в итоге класс лучше использовать, из нового или старого ядра, или сразу оба, как показано в примерах?;

  2. Если для использования настроек по умолчанию, я создаю файл с массивом, в котором устанавливаю эти параметры, то зачем в методе класса, передавать значение параметра по умолчанию еще раз?;

    А если нужно передавать при использовании метода, то зачем тогда использовать файл “default_option.php”?;

  3. Как должны называться параметры по умолчанию в файле “default_option.php” и в методах класса, одинаково или как угодно/удобно? Из примеров к сожалению это непонятно, и в тексте никаких указаний или рекомендаций на этот счет нет.

Хорошо. Давайте посмотрим на документацию по классам. Сначала по методу класса старого ядра COption::GetOptionString();

Предельно просто и понятно указано, как работать с методом.

Правда вопрос по “неймингу” для параметров остается открытым, и возникает вопрос, для чего же тогда в примере по созданию модуля, третий аргумент все таки передается, несмотря на то, что мы используем файл “default_option.php”.

Но в документации по созданию модуля, есть еще пример с классом из нового ядра Option, давайте посмотрим документацию по его методу get()

Здесь, уже более скудное описание по интересующему нас аргументу. 

Нет ни слова про файл “default_option.php”. И соответственно, если не пройти и не посмотреть аналог этого класса из старого ядра, эта информация останется недоступной. 


В итоге, документация - не снимает вопросы, а генерирует их. Я конечно отдаю себе отчет, что я неминуемо что то упустил, и/или из-за отсутствия навыков и опыта, неправильно понял что-то. И возможно, будь я более опытным разработчиком, этих вопросов бы просто не возникло.

Также я понимаю, что решение подобных “проблем”, исследование документации, хорошо прокачивают меня. Чтобы поддерживать хорошее настроение, можно даже представлять себя Индианой Джонсом, в очередном приключении…старое ядро…новое ядро…форум битрикс и его хранители. 

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

Повторюсь, этот текст не про упреки. А про то, что возможно, множество вопросов можно снять, просто немного подправив документацию?

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

Позволю себе некоторую наглость, и приведу пример того, как на мой взгляд, мог бы выглядеть раздел “Параметры”, страницы с описанием создания модуля:


Параметры

Параметры модуля доступны для изменения в административном интерфейсе на странице Настройки модулей (Настройки > Настройки продукта > Настройки модулей). При выборе модуля на данной странице, система подключает файл /bitrix/modules/my_module_id/options.php, предназначенный для управления параметрами модуля, назначения прав на модуль и т.п.

Параметры модуля хранятся в базе данных.

При получении параметров модуля, может использоваться значение по умолчанию, задаваемое в файле /bitrix/modules/my_module_id/default_option.php. В данном файле определяется массив $my_module_id_default_option, хранящий значения по умолчанию.

Пример файла /bitrix/modules/my_module_id/default_option.php:

<?
/*
 * Файл local/modules/my_module_id/default_option.php
 */
$my_module_id_default_option = array(
    "MY_PARAMETER_ID"  =>  "DEFAULT_VALUE"
    );
?>

Для работы с параметрами модуля предназначен класс COption. Методы класса:

  • SetOptionString - установка строковых параметров

  • SetOptionInt - установка числовых параметров

  • GetOptionString - получение строковых параметров

  • GetOptionInt - получение числовых параметров

  • RemoveOption - удаление параметра 

Примеры использования:

Строковый параметр

<?
// установим строковый параметр
COption::SetOptionString("my_module_id", "MY_PARAMETER_ID", "VALUE");
// получим строковый параметр
$value = COption::GetOptionString("my_module_id", "MY_PARAMETER_ID", "DEFAULT_VALUE");
?>

Прим. При использовании файла default_option.php, заданные в нем значения параметров по умолчанию, не нужно передавать третьим аргументом “def” при вызове метода COption::GetOptionString();

Названия параметров, должны быть идентичными в файле default_option.php и в методах класса COption.

Параметр типа файл. (Загрузка файла в модуле)

<table>
  <tr> <td width="40%">
       <?
       $path_file = COption::GetOptionString("my_module_id", 'CLEVERSCRIPT_IMG_DESCTOP_BTN');
       CAdminFileDialog::ShowScript
       (
           Array(
               "event" => "BtnClick_0",
               "arResultDest" => array("FORM_NAME" => "cleverscriptwantcheaper", "FORM_ELEMENT_NAME" => "CLEVERSCRIPT_IMG_DESCTOP_BTN"),
               "arPath" => array("PATH" => GetDirPath($path_file)),
               "select" => 'F',// F - file only, D - folder only
               "operation" => 'S',// O - open, S - save
               "showUploadTab" => true,
               "showAddToMenuTab" => false,
               "fileFilter" => 'jpg,jpeg,gif,png',
               "allowAllFiles" => true,
               "SaveConfig" => true,
           )
       );
       ?>
       <?echo Loc::getMessage("T_CLEVERSCRIPT_IMG_DESCTOP_BTN")?>
   </td>
   <td width="60%">
       <input type="text" name="CLEVERSCRIPT_IMG_DESCTOP_BTN" size="50" maxlength="255" value="<?echo $path_file?>"> <input type="button" name="browse_0" value="..." onClick="BtnClick_0()">
   </td>
</tr>
</table>

Что было изменено

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

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

Вот собственно и все. И не нужны одни и те же дополнительные разъяснения в чатах и форумах.

Пара разъясняющих предложений, целостный пример. И как минимум у одного человека, по конкретной задаче - не было бы абсолютно никаких вопросов.

Вот такой текст. Это первая моя статья на Хабре.

Надеюсь, что получилось неплохо, содержательно, интересно и главное полезно.

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

Всем добра!

Комментарии (14)


  1. DyoMin
    26.02.2022 19:55
    +2

    Это ещё хорошо, что документация по этому случаю нашлась. Там есть функционал, который или совсем не описан в документации, или описание настолько скудное, что надо лезть в код ядра Битрикс, чтобы разобраться, что происходит, что ожидается на входе и будет на выходе.

    Особенно в той документации радуют описания в стиле "Метод нестатический" (прямо выделено, чтобы никто никогда не подумал, что он статический), и в примере статический вызов этого метода.

    Кстати, много чего интересного в документации нет, но есть в их курсах.


    1. k0lim Автор
      28.02.2022 12:37

      Да, согласен. Так и приходится искать информацию по кусочкам: документация, курсы, сторонние блоги, исходные файлы.

      Я понимаю, везде бывают сложности, и в том числе возможно с переходом на D7, по всей видимости какие то сложности. Но при этом активно призывая к использованию D7, использовать в док-ии, на одном экране - оба метода, я не понимаю, если цель запутать


  1. Fahrain
    26.02.2022 21:15
    +4

    Документация битрикса — это просто куча устаревшего мусора, не имеющая ничего общего с реальностью. Хоть как-то там можно верить только тем страницам, которые описывают старое api, да и то — последнее время старые функции всё чаще работают неправильно/странно или не работают вообще.


    Документации по новому api нет вообще.


    Битрикс переходит на новое api уже больше 5 лет. За всё это время я так и не увидел в документации ничего, посвященного даже базовым вещам.


    До сих пор (5 ЛЕТ, ПЯТЬ!!!!) единственным источником информации о работе с заказом на новом api является единственная статья на чьем-то левом блоге (вообще не связанным с компанией битрикс!!!) где собраны все примеры кода. И нет, вы не сможете найти эти функции в документации. В лучшем случае там будет бесполезная страница-заглушка, в которой написано название функции и одно предложение в стиле "это функция, она функционирует".


    Более того, если на старом фзш работа с заказом шла в рамках хоть какой-то логики и использовались не сильно связанные друг с другом функции (т.е. если что-то пропустил и не вызвал — это не мешало работать другим функциям), то теперь у нас всё на объектах, функции которых принимают на вход другие объекты, которые надо правильно проинициализировать третьими объектами, которые — правильно! — тоже требуют на вход правильные объекты. При этом если в цепочке вызовов вот этого вот всего пропустить хотя бы одно действие — результат не будет получен вообще, никакой. Ошибок тоже не будет (ну зачем вам ошибки???).


    Раньше, на то, чтобы разобраться чем-то нестандартным используя код на старом api, я тратил от 20-120 минут. Теперь я трачу от 4 часов — и до нескольких дней просто на то, чтобы понять как вообще называются нужные мне функции, как их правильно вызвать и какие параметры им нужны.


    Я абсолютно, искренне не понимаю, кто в здравом уме сейчас будет изучать битрикс с нуля: это адские затраты на ковыряние в говнокоде при 100% отсутствующих документации и хоть чего-то полезного, что можно нагуглить. Т.е. единственный источник информации — код из модулей битрикса. И этот код не содержит даже комментариев.


    Если политика компании не поменяется (причем делать это надо было еще 5 лет назад!!!), то продукт умрет, т.к. притока новых разработчиков в него просто не будет. Что автоматом приведет к тому, что битрикс просто перестанут покупать и разработчики в дальнейшем никому и не будут нужны.


    1. navicrstl
      27.02.2022 13:15

      Они давным давно забили на 1С-Битрикс как на CMS. Сейчас делать на ней ИМ будет только отчаянный (технически)


      1. Fahrain
        27.02.2022 13:22
        +2

        Так CRM у них внутри — это всё тот же битрикс + другой шаблон и несколько доп. модулей. И документация там в таком же состоянии. Ну т.е. дорабатывать там CRM точно так же больно.


        1. udjin123
          27.02.2022 19:08

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


          1. Fahrain
            27.02.2022 19:18

            Ну и в итоге они растеряют всех тех, кто покупал сайты на битриксе и тех кто повелся на битрикс+црм. Останутся только те, кто чисто црм использует, а этих црм сейчас как собак.
            Причем я не вижу объективной замены битриксу, переходить-то особо и некуда (ну, фреймворки — это все-таки из другой оперы, их я не учитываю)


            1. udjin123
              27.02.2022 19:23

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


              1. Fahrain
                27.02.2022 19:32

                Ну конструкторы — это для совсем бедных. Слишком они ограниченные все-таки, с таким же успехом можно на дефолтном шаблоне в битриксе сидеть)


                Маркетплейсы последнее время постоянно какой-то негатив генерируют. Т.е. да, понятно, что покупателю они может и удобнее, но тот же я.маркет продавцы довольно активно покидают (особенно — крупные).


      1. fotobred
        28.02.2022 13:57

        да ладно!!!
        Больше половина вакансий - 1С-Битрикс, даже если в описании не указано, смотришь исходный код - там "/bitrix/"
        в почте/спам полно приглашений на кодерляйн...
        от этой пандемии ничто не спасет!


    1. k0lim Автор
      28.02.2022 12:40
      +1

      Чего уж там 5ти годам удивляться, почти в каждой теме официального форума, ведутся разговоры вида:

      Добавьте/исправьте пожалуйста(2005год)
      Привет из 2015го. Добавьте/исправьте пожалуйста
      Шел 2021й. Все по прежнему


  1. Baigildin
    27.02.2022 20:59

    Человек который отвечает за документацию Битрикс.
    image
    dev.1c-bitrix.ru/community/blogs/vad/2010.php#14210


    1. Fahrain
      28.02.2022 14:00

      Какой ужас… Таких людей нельзя подпускать к коду.