Модуль Faceted Search — поиск с помощью "уточнений". Ищем втрое быстрее: мульти-запросы и фасеточный поиск. Раздел Results page

Новости 12.04.2019
Новости

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

Поисковые алгоритмы

Поддерживайте оператор расширенного поиска «кавычки»

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

Кавычки - единственное исключение. Если заключить фразу в кавычки, то поиск будет вестись по полному совпадению с фразой. Такой оператор используется в поиске Google, и широко известен среди продвинутых пользователей интернета.

Автоматически сортируйте результаты в выдаче по степени совпадения с запросом

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

Пример. В предыдущих исследованиях пользователи сайта The Container Store жаловались на неточные результаты поиска на сайте. Один пользователь хотел приобрести комплект контейнеров для хранения из нержавейки с прозрачной крышкой. По запросу «сталь стекло контейнер» он получил в выдаче ёршики для унитаза и стеклянные банки. Пользователю пришлось переформулировать поисковый запрос несколько раз, но безуспешно.

Проблема поисковой системы на сайте заключалась в том, что в выдаче отображались все товары, которые удовлетворяли хотя бы одному слову запроса («сталь», «стекло» или «контейнер»), не отсортированные по степени совпадения с оригинальным запросом. Товар, соответствовавший всем трем ключевым словам, мог находиться в любом месте списка, не обязательно в начале. Впоследствии сайт обновил поисковый алгоритм: теперь в начале выдачи можно было видеть товары, соответствующие всем или большинству ключевых слов запроса.

Улучшенная выдача на сайте containerstore.com: первый же результат по запросу steel and glass canister соответствует потребности пользователя

При сортировке выдачи по оценке товара учитывайте ее взвешенное, а не среднее значение

Сортируя товары по средней оценке покупателей, пользователи не хотят видеть товары с единственной оценкой, даже если это 5 звезд. Люди не хотят наткнуться на заказной обзор, и средняя оценка товара, основанная на паре-тройке отзывов, вызывает у них подозрения. При сортировке по взвешенной оценке продукт со средней оценкой 4,9 из 5 и с 342 отзывами будет расположен выше, чем продукт со средней оценкой 5 из 5 и 3 отзывами. Таким образом пользователь сможет получить объективное представление о популярности и качестве товара.

Оформление и положение поисковой строки

Отображайте поисковую строку в одном блоке с навигационным меню в шапке сайта

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

На сайте Wildberries большая и хорошо заметная поисковая строка находится прямо в шапке сайта

Отображайте на экране поисковую строку и иконку лупы

Когда посетители сайтов интернет-магазинов хотят воспользоваться поиском, они ищут взглядом широкое пустое поле или иконку лупы. При этом явно подписывать поисковую строку и называть ее «Поиск» больше не обязательно, хотя и не помешает.

Многие сайты в версиях для смартфонов успешно используют иконку лупы и не показывают саму строку, что позволяет им экономить место на экране. Но если продажи на вашем сайте зависят от поиска, лучше отображать поисковую строку сразу, даже на маленьких экранах. Тем более это актуально для ПК-версий сайтов, где места на экране более чем достаточно. Используйте пустое поле с кнопкой «Найти» или иконкой лупы. Поле должно быть заметно на каждой странице.

Сужение результатов поиска

Не используйте расширенный поиск и поиск по категориям, если вы не Amazon

Раньше многие интернет-магазины использовали функции расширенного поиска и поиска по категориям, чтобы помочь пользователям сокращать количество товаров в выдаче. Однако на самом деле люди не пользуются расширенным поиском и часто путаются в поиске по категориям, поэтому постепенно эти функции вышли из моды.

Такие продвинутые способы поиска сейчас остались только на тех сайтах, где они действительно полезны. Это либо сайты с особыми сценариями поиска, вроде eBay, либо интернет-магазины с огромным количеством товаров, такие, как Amazon и Wal-Mart .

В остальных случаях лучше использовать фасетный поиск. Его ключевое отличие от поиска по категориям заключается в том, что пользователи сужают выборку товаров ПОСЛЕ того, как получили выдачу по поисковому запросу, а не ДО.

Используйте фасетный поиск

Фасетный поиск позволяет пользователям сократить результаты поиска с помощью фильтров, основанных на атрибутах товаров, которые пользователи рассматривают. Если раньше фасетный поиск был приятным дополнением в интернет-магазине, то сейчас пользователи так привыкли к нему, что ищут его на сайте и выражают недовольство, если его нет. Сейчас e-commerce сайты без фасетного поиска - скорее исключение, чем правило.

Фасетный поиск на сайте интернет-магазина «Утконос»: фильтры слева позволяют сузить выдачу

Автодополнение в поисковой строке

Поддерживайте функцию автодополнения

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

Функция автодополнения присутствовала на большинстве изученных NNGroup сайтов. При этом исследование показало, что пользователи выбирали варианты из списка предложенных не так уж и часто - всего в 23% случаев. Как правило, они просто продолжали вводить свой запрос.

Тем не менее, автодополнение полезно. Даже если пользователи не выбирают вариант из списка, они могут увидеть и понять, какие товары доступны на сайте, и что ищут другие покупатели./p>

Поддерживайте расширенное автодополнение

Поиск с автодополнением, содержащий рекомендованные товары, фотографии и другой контент помимо списка запросов - тренд, набирающий популярность на некоторых e-com сайтах. Он появился лет пять назад, но быстро исчез, а сейчас вернулся в новой форме, напоминающей мегаменю - выпадающее поле с рекомендованными вариантами запросов занимает довольно значительное место на экране.

Поиск с расширенным автодополнением в интернет-магазине «Лабиринт»

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

Основные проблемы поиска

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

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

Как компания USABILITYLAB может помочь улучшить поиск на сайте вашего интернет-магазина

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

Если вы хотите оценить или улучшить поиск на вашем сайте, обратитесь к нам. Мы проведем . Для юзабилити-тестирования мы привлечем представителей вашей целевой аудитории. Они будут работать с вашим сайтом под наблюдением нашего эксперта. Наша лаборатория оборудована односторонним зеркалом, так что вы тоже сможете присутствовать на тестировании и видеть всё, что делают респонденты. По результатам тестирования мы сделаем выводы о том, насколько поиск на вашем сайте соответствует потребностям пользователей и сформулируем рекомендации по его улучшению, которые вы сможете передать своим разработчикам.

Чтобы больше узнать о наших услугах, оставьте заявку на нашем сайте или напишите Дмитрию Силаеву:

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

Но сначала 15 секунд политинформации (сам себя не похвалишь, никто не похвалит). В этом году Sphinx прошел во в номинациях SysAdmins и Enterprise (говорят, в номинации Developers не добрали совсем чуть-чуть). Голосование продлится еще неделю (до 20го числа). Кроме рабочего email адреса, ничего не нужно. Заранее спасибо всем, кто не даст нам пропасть!

И обратно к разработке. Что вообще такое мульти-запросы, и откуда берется обещанное втрое быстрее?

Мульти-запросы (multi-queries) - это механизм, который позволяет отослать несколько поисковых запросов одним пакетом.

Методы API, реализующие механизм мульти-запросов, называются AddQuery() и RunQueries() . (Кстати, «обычный» метод Query() внутри использует их же: один раз вызывает AddQuery(), и затем сразу RunQueries()). Метод AddQuery() сохраняет текущее состояние всех настроек запроса, выставленных предыдущими API вызовами, и запоминает запрос. Настройки уже запомненного запроса более меняться не будут, любый вызовы API их не тронут, соотв-но для последующих запросов можно использовать любые другие настройки (другой режим сортировки, другие фильтры, итп). Метод RunQueries() фактически отсылает все запомненные запросы одним пакетом и возвращает несколько результатов. На участвующие в пакете запросы никаких ограничений не накладывается. Количество запросов на всякий случай ограничено директивой max_batch_queries (добавлена в 0.9.10, ранее фиксированным числом 32), но это в общем-то только проверка против битых пакетов.

Зачем использовать мульти-запросы? Вообще говоря, все сводится к производительности. Во-1х, отсылая запросы к searchd одним пакетом, всегда экономим немножко ресурсов и времени на том, что отсылаем туда-сюда меньше сетевых пакетов. Во-2х, что значительно более важно, searchd получает возможность провести некоторые оптимизации над всем пакетом запросов. Со временем постепенно добавляются новые оптимизации, поэтому имеет смысл всегда, когда можно, отсылать запросы пакетами - тогда при обновлении Sphinx новые пакетные оптимизации включатся полностью автоматически. В случае, когда никаких пакетных оптимизаций применить нельзя, запросы просто будут обработаны по одному, без каких-либо видимых отличий для приложения.

Зачем (точнее когда) мульти-запросы НЕ использовать? Все запросы в пакете должны быть независимы, но иногда это не так, и запрос Б может зависеть от результатов запроса А. Например, можем хотеть показывать результаты поиска из дополнительного индекса только тогда, когда в главном индексе ничего не нашлось. Или просто выбирать разное смещение во 2й набор результатов в зависимости от количества совпадений в 1м наборе. В таких случаях придется использовать отдельные запросы (или отдельные пакеты).

Есть две важные пакетные оптимизации, про которые стоит знать: оптимизация общих запросов (доступна начиная с версии 0.9.8), и оптимизация общих поддеревьев (доступн начиная с находящейся в разработке версии 0.9.10).

Оптимизация общих запросов работает так. searchd выбирает из пакета все запросы, у которых отличаются только настройки сортировки и группровки, а полнотекстовая часть, фильтры итп совпадают - и проводит поиск только один раз. Например, если в пакете 3 запроса, текстовая часть у всех «ipod nano», но 1й запрос выбирает 10 самых дешевых результатов, 2й группирует результаты по ID магазина и сортирует магазины по рейтингу, а 3й запрос просто выбирает максимальную цену, поиск «ipod nano» отработает только один раз, но из его результатов будут построены 3 по-разному отсортированных и сгруппированных отклика.

Так называемый фасеточный поиск является частным случаем, для которого применима данная оптимизация. В самом деле, его можно реализовать, запустив несколько поисковых запросов с разными настройками: один для основных результатов поиска, еще несколько с таким же поисковым запросом, но разными настройками группировки (top-3 авторов, top-5 магазинов, итп). Когда все, кроме сортировки и группировки одинаковое, оптимизация включается и скорость неплохо растет (пример ниже).

Оптимизация общих поддеревьев еще более интересная штука. Она позволяет searchd использовать сходства между разными запросами внутри пакета. Внутри всех пришедших отдельных - разных! - полнотекстовых запросов выявляются общие части, и если такие есть, промежуточные результаты расчета кешируются и разделяются между запросами. Например, вот в таком пакете из 3 запросов

Barack obama president barack obama john mccain barack obama speech

Есть общая часть из 2х слов («barack obama»), которую можно для всех трех запросов вычислить ровно один раз и закешировать. Именно этим оптимизация общих поддеревьев и занимается. Максимальный размер кеша на каждую пачку жестко ограничивается директиваи subtree_docs_cache и subtree_hits_cache, так что если общая часть «i am» найдется в ста миллионах документов, память у сервера внезапно таки не кончится.

Вернемся обратно к оптимизации про общие запросы. Вот пример кода, который запускает один и тот же запрос, но с тремя разными режимами сортировки:
sorting modes:

Require ("sphinxapi.php"); $cl = new SphinxClient (); $cl->SetMatchMode (SPH_MATCH_EXTENDED2); $cl->SetSortMode (SPH_SORT_RELEVANCE); $cl->AddQuery ("the", "lj"); $cl->SetSortMode (SPH_SORT_EXTENDED, "published desc"); $cl->AddQuery ("the", "lj"); $cl->SetSortMode (SPH_SORT_EXTENDED, "published asc"); $cl->AddQuery ("the", "lj"); $res = $cl->RunQueries();

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

0.040 sec x3 the 0.040 sec x3 the 0.040 sec x3 the

Обратите внимание на «x3», это именно оно - означает, что запрос был оптимизирован и обработан в числе пакета из 3 запросов (включая этот). Для сравнения, вот так выглядит лог, в котором те же самые запросы были отправлены по одному:

0.059 sec the 0.091 sec the 0.092 sec the

Видно, что время поиск на каждый запрос в случае с мульти-запроса улучшилось от 1.5 до 2.3 раз, в зависимости от режима сортировки. На самом деле, это не предел. Для обоих оптимизаций известны случаи, когда скорость улучшалась в 3 и более раз - причем не на синтетических тестах, а вполне себе в продакшне. Оптимизация общих запросов довольно хорошо ложится на вертикальные поиски по товарам и онлайн магазины, кеш общих поддеревьев соовт-но на data mining запросов; но, разумеется, строго этими областями применимость не ограничивается. Например, можно делать поиск вообще без полнотекстовой части и считать несколько разных отчетов (с разной сортировкой, группировкой итп) по одинаковым данных за один запрос.

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

Мы выпустили новую книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».

Подписаться

Фасетная навигация – это проблема всех e-commerce сайтов. Чрезмерное количество страниц, которые используются для разных вариантов одного и того же элемента, создает угрозу эффективности поиска. Это может негативно повлиять на SEO и пользовательский опыт. Что такое фасетная навигация, и как ее улучшить, рассказали специалисты из блога SEO Hacker.

Фасетная навигация: определение

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

Фасеты и фильтры отличаются друг от друга. Вот в чем заключается разница:

  • Фасеты – индексированные категории. Они помогают уточнять списки товаров и действуют как расширение основных категорий. Фасеты добавляют уникальное значение для каждого выбора, который делает пользователь. Так как фасеты индексированы, они должны отправлять релевантные сигналы поисковой системе, гарантируя, что страница содержит все важные атрибуты.

  • Фильтры используются для сортировки и уточнения элементов внутри списков. Они необходимы для пользователей, но не для поисковых систем. Фильтры не индексируются, потому что они не меняют содержимое страницы, а лишь сортируют ее в другом порядке. Это приводит к множественному URL-адресу, имеющему дублированный контент.

Потенциальные проблемы

У каждой возможной комбинации фасетов есть собственный уникальный URL-адрес. Он может стать причиной некоторых проблем с точки зрения SEO. Вот основные из них:

  • Дублированный контент.
  • Трата бюджета на сканирование.
  • Устранение разницы в ссылках.

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

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

Решения для фасетной навигации

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

AJAX

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

AJAX может быть эффективен только до запуска сайта e-commerce. Для решения проблем уже существующих ресурсов он не используется. Также этот метод требует определенных трат с вашей стороны.

Тег noindex

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

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

Атрибут rel=canonical

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

София Ибрагимова

Контент-маркетолог

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

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

Robots.txt

Закрытие части страниц от индексации позволяет добиться хороших результатов. Это простой, быстрый и надежный способ. Удобнее всего установить настраиваемый параметр для указания всех возможных комбинаций фасетов и фильтров, которые вы хотите заблокировать. Включите его в конец каждого URL-адреса, который хотите скрыть (http://полный адрес страницы/robots.txt) или используйте метатег Robots в области HEAD кода страницы.

При изменении в URL-адресе необходимо помнить, что роботам требуется 3-4 недели, чтобы заметить эти изменения и среагировать на них.

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

Консоль Google Search

Это отличный способ временно исправить свои проблемы, пока вы работаете над созданием более совершенной и удобной системы навигации. Вы можете использовать консоль Google Search, чтобы сообщить поисковику, как сканировать ваш сайт.

  • Нажмите на кнопку «Параметры URL» (URL Parameters):

  • Укажите влияние каждого из ваших параметров на страницу и то, как Google должен обрабатывать эти страницы.

Помните, что этот способ скрывает дублированный контент только от поисковых роботов Google. В Bing и Yahoo станицы по-прежнему будут отображаться.

Как улучшить фасетную навигацию

Рассмотрим вкратце все методы, которые позволяют создать правильную фасетную навигацию:

  • Использование AJAX
  • Удаление или скрытие ссылок на категории или страницы фильтров, на которых отсутствует контент.
  • Разрешение индексирования определенных комбинаций фасетов, которые имеют большой объем поиска трафика
  • Установка иерархии сайтов через хлебные крошки в категориях и подкатегориях.
  • Создание канонических (основных) страниц для дублированного контента.
  • Консолидация индексирующих свойств со страниц компонентов на весь ряд с помощью разметки страницы с rel = "next" и rel = "prev" .

Заключение

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

Содержание статей:
Предыдущая статья:

Фасеты - это определенные ограничения на тип значений XDTO. Один фасет определяет тип ограничения и значение ограничения. Например [Максимум включающий - 5]. Тип значения XDTO может хранить в себе несколько фасетов, но их типы должны быть уникальны, то есть нельзя указать два фасета [Максимум включающий - 5] и [Максимум включающий - 3].

В данной статье хочу показать как можно при помощи фасетов сделать проверку входных и как сделать параметр ws-операции составного типа.

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

Создадим новую базу и добавим новый пакет XDTO, назовем его ПакетXDTO, укажем пространство имен.

Далее добавим в пакет Тип значения как показано на рисунке.


Давайте создадим тип "Код" для организации отбора по уникальному идентификатору номенклатуры. Соответственно, новый тип "Код" можно получить из типа string, добавив ограничение на количество символов. Символов должно быть 9, то есть количество символов в коде номенклатуры. Для фасета "Пробельные символы" установим значение "collapse", это позволит вывести ошибку, если в коде имеются пробелы.


Теперь таким же образом создадим ТипЗначения "Цена". Для него установим минимум 0, максимум 1 000 000.


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


Ну, теперь приступим к созданию веб-сервиса. Назовем его "Остатки" и добавим 3 параметра:
  • Код - тип Код, который мы ранее создали. По данному параметру будем устанавливать отбор на код номенклатуры;
  • ЦенаОт - тип Цена. Это нижняя граница цены товара;
  • ЦенаДо - тип Цена. Это верхняя граница цены товара.

Для того что бы веб сервис вывел массив товаров, у каждого из которых есть код, наименование, цена и остаток создадим ОбъектXDTO "Номенклатура", в котором укажем поля:

  • Код - тип Код;
  • Наименование - тип string;
  • Цена - тип Цена;
  • Остаток - тип int

И создадим ОбъектXDTO "Товары", который будет иметь одно свойство "Номенклатура", но с возможностью вывода списком. В качестве типа поля "Номенклатура" объекта "Товары" укажите объект "Номенклатура". Подробнее о том как передать массив через веб-сервис можно прочитать .

Перейдем к свойствам операции "Остатки". Укажем тип возвращаемого значения - "Товары" и откроем ее модуль. Напишем такой код:

Функция Остатки (Код , ЦенаОт , ЦенаДо )

Запрос = Новый Запрос;
Запрос . Текст =
"ВЫБРАТЬ
|Номенклатура.Код,
|Номенклатура.Наименование,
|Номенклатура.Цена,
|Номенклатура.Остаток
|ИЗ
|Справочник.Номенклатура КАК Номенклатура
|ГДЕ
|1 = 1
|И 2 = 2" ;

Если ЗначениеЗаполнено (Код )
И Код <> " 000000000 " Тогда
Запрос . Текст = СтрЗаменить (Запрос . Текст , " 1 = 1 " , " Номенклатура.Код = &Код " );
Запрос . УстановитьПараметр (" Код " , Код );
КонецЕсли;

Если НЕ ЦенаОт = ЦенаДо Тогда
Запрос . Текст = СтрЗаменить (Запрос . Текст , "2 = 2" , "Номенклатура.Цена МЕЖДУ &ЦенаОт И &ЦенаДо" );
Запрос . УстановитьПараметр ("ЦенаДо" , ЦенаДо );
Запрос . УстановитьПараметр ("ЦенаОт" , ЦенаОт );
КонецЕсли;

РезультатЗапроса = Запрос . Выполнить ();

ВыборкаДетальныеЗаписи = РезультатЗапроса . Выбрать ();
ТипXDTOТовары = ФабрикаXDTO . Тип (, "Товары" );

Товары = ФабрикаXDTO . Создать (ТипXDTOТовары );
ТипXDTOНоменклатура = ФабрикаXDTO . Тип ("http://codenotes-1c.blogspot.ru/" , "Номенклатура" );
Пока ВыборкаДетальныеЗаписи . Следующий () Цикл
Номенклатура = ФабрикаXDTO . Создать (ТипXDTOНоменклатура );
Номенклатура . Код = ВыборкаДетальныеЗаписи . Код ;
Номенклатура . Наименование = ВыборкаДетальныеЗаписи . Наименование ;
Номенклатура . Цена = ВыборкаДетальныеЗаписи . Цена ;
Номенклатура . Остаток = ВыборкаДетальныеЗаписи . Остаток ;
Товары . Номенклатура . Добавить (Номенклатура );
КонецЦикла ;

Возврат Товары ;

КонецФункции

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

  • без параметров. Если быть точным то укажем код "000000000", цену от =0, цену до = 0. Потому что, пустые параметры недопустимы.

Ну и у параметра "Код" ws-операции "Остатки" укажем этот тип. После чего мы сможем указывать код номенклатуры как в виде числа, так и в виде строки. Без переделки кода можем указать только 0, что соответствует пустому значению параметра, и отбор не будет установлен.

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

Далее, в качестве справки приведу значение каждого поля свойства. Данное описание взято по ссылке: К чему относится понятие «Фасет» в рамках модели XDTO? Что такое фасет? Авторам большое спасибо!

  • Базовый тип - тип, который используется как основа. По умолчанию anyType. От этого значения зависит допустимый набор фасетов.
  • Длина — фасет длины. Содержит количество единиц длины, причем единица длины имеет различный смысл для различных типов. Для типов «string» и «anyURI» длина содержит количество символов. Для типов «hexBinary» и «base64Binary» длина содержит количество байт двоичных данных. Для типов, определяемых списком, длина содержит количество элементов списка;
  • МаксВключающее — фасет максимума, включающего границу. Ограничивает пространство значений данного типа максимальным значением. Любое значение данного типа меньше либо равно указанному значению;
  • МаксДлина — фасет максимальной длины. Содержит максимальное количество единиц длины, причем единица длины имеет различный смысл для различных типов. Для типа «string» максимальная длина содержит максимальное количество символов. Для типов «hexBinary» и «base64Binary» максимальная длина содержит максимальное количество байт двоичных данных. Для типов, определяемых списком, максимальная длина содержит максимальное количество элементов списка;
  • МаксИсключающее — фасет максимума, не включающего границу. Ограничивает пространство значений данного типа максимальным значением. Любое значение данного типа меньше указанного значения;
  • МинВключающее — фасет минимума, включающего границу. Ограничивает пространство значений данного типа минимальным значением. Любое значение данного типа больше либо равно указанному значению;
  • МинДлина — фасет минимальной длины. Содержит минимальное количество единиц длины, причем единица длины имеет различный смысл для различных типов. Для типа «string» минимальная длина содержит минимальное количество символов. Для типов «hexBinary» и «base64Binary» минимальная длина содержит минимальное количество байт двоичных данных. Для типов, определяемых списком, минимальная длина содержит минимальное количество элементов списка;
  • МинИсключающее — фасет минимума, не включающего границу. Ограничивает пространство значений данного типа минимальным значением. Любое значение данного типа больше указанного значения;
  • Перечисление — фасет перечисления. Определяет набор допустимых значений данного типа;
  • ПробельныеСимволы — фасет пробельных символов. Может принимать одно из трех значений:
    • Сохранять — строка может содержать любые пробельные символы;
    • Заменять — строка не должна содержать #x9 (табуляция), #xA (перевод строки) и #xD (возврат каретки). Если они существуют, то они должны быть заменены символом #x20 (пробел);
    • Сворачивать — дополнительно к требованиям, указанным для значения replace, строка не должна содержать парных символов #x20 (пробел), а также лидирующих и завершающих символов #x20 (пробел);
  • ЦифрВсего — фасет общего количества цифр. Содержит общее количество разрядов числа (целая часть плюс дробная часть);
  • ЦифрДробнойЧасти — фасет количества цифр дробной части. Содержит количество разрядов дробной части числа.


Рекомендуем почитать