Один xPath для на разных выпадающих меню на основе contains()

программирование
, ,
#1

Может кому понадобится.
Описываю сейчас блок фильтров из полей и выпадающих меню.
И заметил одну удобную штуку:

%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5

Каждый div в списке это выпадающее меню. Внутри выглядит так:

2

Строка "ul ", выделенная синим, это сам список с каким то количеством элементов.

А теперь немного кода:

$x("//div[@class=‘data-row’]//div[@class=‘scrollbox’]/div/ul/li[contains(.," + “/”" + recipAccount + “/”" + “)]”).click();

Рассмотрим эту жуть в частях :slight_smile:

  1. //div[@class=‘data-row’] это класс из первого скрина.
  2. //div[@class=‘scrollbox’] промежуточный, чтобы избавиться от тысяч div-ов.
  3. /div/ul/li[ ] ближайший div и сам список, пока “пустой”.
  4. 3
    p.s. слэши не печатались, будет скрин. recipAccount заменить на свой String.

Так вот. В последнюю часть (contains) можно передавать параметр типа String для поиска
элемента в списке.

А вот как выглядит xPath без каких либо преобразований :killMePlease:

/html/body/section/aside[2]/div/div/div[2]/div[4]/div/div[1]/div[4]/div[2]/div[1]/div/div/div[1]/ul/li[5]

Итоги:

Это, конечно, не панацея, но, все таки, сэкономит хоть немного времени на лишний кофибрэйк.
Есть возможность сократить тело метода (чего я пока не сделал)
А вообще, просто хотел поделиться. Добро за добро, так сказать.

Пример. Получается примерно так:

4

Всем добра :slight_smile:

#2

если честно, я не понимаю что это и зачем. если человек регулярно пишет xpath, то и проблем у него не будет

#3

По сути, скорее для оптимизации. Чтобы не писать один и тот же код 6 раз (конкретно в этом случае). Ну и, возможно, сам принцип кому то подойдет для других целей.

#4

Принцип он всегда один - писать менее хрупкие локаторы, в контексте xpath - опираться на уникальные атрибуты и использовать оси

2 лайка