«Настройки значения» и «Настройки поля»: в чем разница?

Несколько значений в одном поле (17.71 КБ)

Многие пользователи сталкиваются с проблемой: где же делать настройки выгружаемых данных: в настройках значения или в настройках поля?

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

Поле - это то поле, которое выгружается в файл (или отправляется по API). Например, при выгрузке в Яндекс.Маркет есть поле «Название товара» - это одно поле.

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

  1. тип товара

  2. производитель

  3. модель

  4. дополнительные важные данные

В итоге поле будет содержать не просто название элемента инфоблока, а сгенерированную строку вида «Ультрабук ASUS ZenBook UX333FLC-A3151T черный». Таким образом, мы имеем всего 1 поле и целых 4 значения в нём!

Теперь Вы понимаете, что поле складывается из отдельных значений. Но вопрос актуален: где же делать настройки выгружаемых данных?

Продолжим рассматривать наш случай с ноутбком. Допустим, Вы настроили профиль. Но на Вашем сайте тип товара хранится в верхнем регистре, и модуль Вам выдает название «УЛЬТРАБУК ASUS ZenBook UX333FLC-A3151T синий». Это недопустимо для Яндекс.Маркета! Проверка укажет на ошибки и Ваш файл будет отклонен!

Что же делать!? Модуль предоставляет возможность изменения регистра текста. Но где же задать настройку изменения регистра - в настройках значения или в настройках поля? Думаю, Вы уже все поняли. Если мы изменим регистр в настройках поля, получим «Ультрабук asus zenbook ux333flc-a3151t синий» (тип регистра: предложение) или «Ультрабук Asus Zenbook Ux333flc-a3151t Синий» (тип регистра: первые буквы). Ни тот ни другой вариант не являются приемлемыми. Поэтому, в данном случае не может быть никаких сомнений: настройки регистра нужно прописать в то значение, которое выбирает тип товара. Всё! Вопрос решен.

У Вас наверняка возник другой вопрос - а для чего тогда нужны настройки поля? Рассмотрим другой случай. Вы компонуете описание товара из множества полей: подробное описание, дополнительное описание, дополнительный текст для продажи и т.п. Выгружая товары, Вы понимаете, что во всех этих значениях (или почти во всех) имеются html-теги, а они, хоть и поддерживаются Яндекс.Маркетом, но для данной выгрузки Вам нужны. Что делать? Модуль позволяет настроить удаление html-тегов, но где указать эту настройку - в каждом значении или в поле? Думаю, Вы и здесь всё поняли - проще один раз указать эту настройку в поле, чем указывать её для каждого значения в отдельности.

Кроме этого, есть и другие важные нюансы - они касаются логики. В настройках есть опция «Использовать значение без обработки» - она позволяет для значения типа «Привязка к элементам» выбрать не название товара, а чистое значение - это ID товара. Как Вы думаете, где логично размещать эту настройку - на этапе получения каждого из значений, или на этапе сборки полученных значений в одно поле? Правильно, на этапе получения значений, т.к. эта опция логически относится только к значению. Есть обратные ситуации - в модуле имеется возможность выгружать поле как CData (это когда все поле оборачивается в специальную XML-конструкцию CData чтобы в нём можно было использовать html-теги). Как Вы думаете, эта настройка должна быть в настройках значения или в настройках поля? Конечно же в настройках поля, т.к. логически относится именно к полю.

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

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

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

P.S.: Для полного понимания осталось сказать, по какому алгоритму работает выгрузка значений и полей и учет их настроек: сначала модуль для каждого поля получает все значения, к каждому из которых применяет свои настройки (настройки значения). На этом этапе всегда получается <b>массив</b> значений, даже если значение всего одно. Затем этот массив обрабатывается настройками поля, где первая настройка - это настройка преобразования массива в строку (для некоторых полей, где поддерживается множественные значения, добавлена возможность сохранить множественность). И далее, если выбрано преобразование в строку - модуль применяет настройки для этой полученной строки, а если массив - настройки применяются для каждого элемента массива.



Возврат к списку