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

делаете внутри виджета

public SelenideElement should(Condition condition) {
  return self.$("проверяемый_элемент").should(condition)
}

да, оверайд методов селенидЭлемента во врамере на селф.. тоже имеем.

Да, всем спасибо, я щас либо еще один пример приведу, либо пойму что он глупый, и на этом закончу. Спасибо всем за время потраченое

тебе спасибо за идеи! мы часто не знаем как пользователи используют тул. любой фидбек полезен

у меня много новых коллег после HtmlElements не принимали селенидовский посыл. Благо я прошел мимо этого. Но, в конечном итоге, все эти коллеги больше не вспоминают про HtmlElements вовсе. Вероятно, вы тоже проходите эту стадию непринятия =)

ну оно решало задачу что нельзя написать

public class ExchangeRates {
    private WebElement self;
    private WebElement currencyRates = self.findElements(".foo");

    public ExchangeRates(WebElement self) {
        this.self = self;
    }


    public String getRates() {
        return currencyRates.getText();
    }
}

поэтому все эти фабрики, прочее

Написал вариант вложенных компонентов, так по идеи (по той идеи о которой думаю) PO и тест может выглядить вот так. (ненаписано command классы). Разница - колво строк, относительно варианта с враппером. на каждый класс, полагаю + this.self = self / constructor / getSelf(). Возможно оверайды SelenideElement. Если для такой структуры, вариант с враппером всем все еще кажется норм. то всеспасибояпошел.

п.с. сразу же хочется сделать BaseWrapperElement, но потом вероятно будут проблемы с наследованием (классы != интерфейсы, и тут или выкручивайся, или не наследуй и не будет проблем...)

public class MyPage {
    private MyElement1 one = $(".q",MyElement1.class);
    private MyElement2 two = $(".w",MyElement2.class);
    private MyElement3 three = $(".e",MyElement3.class);
}

public interface MyElement3 implements SelenideElement {
    private MyElement4 one = $(".r",MyElement4.class);
    private MyElement5 two = $(".t",MyElement5.class);
}

public interface MyElement5 implements SelenideElement {
  public void doSomething(String foo)
}

public interface MyElement4 implements SelenideElement {
  public MyElement4 doOther(String foo)
}
Test:
new MyPage().getThree().getOne().doOther("wow").shouldHave(text("text"))

когда у тебя $() ничего не ищет, можно на джава программировать вместо аннотаций.

запрети себе наследование просто. станет проще жить.

понимаю.. но в данном примере или оверайд + доп.self methods. или BaseWrapper c  дальнейшими наследованиями. Щас по 2му пути, отсюда и боль, отсюда мысль, отсюда писанина выше. Но да, предложение дельное)

простите за портянку

public static class Table {
    private final SelenideElement table;
​
    public Table(SelenideElement table) {
      this.table = table;
    }
​
    public Header header() {
      return new Header(table.$("thead"));
    }
​
    public List<Row> rows() {
      $(".....").shouldBe(Condition.exist);
      return table.$$("tbody tr").stream().map(Row::new).collect(Collectors.toList());
    }

​
    public static class Header {
      private final SelenideElement header;
​
      public Header(SelenideElement header) {this.header = header;}
    }
​
    public static class Row {
      private SelenideElement row;
​
      public Row(SelenideElement row) {this.row = row;}
​
      @Step()
      public ModalPage openModal() {
        domain().click();
        new ModalPage().title().shouldBe(visible, Duration.ofSeconds(10));
​
        return new ModalPage();
      }
​
      public SelenideElement domain() {return row.$$("td").get(0);}
    }
​
  }

вложенность

если вам нужен атлас пишете на нем. судя по гитхабу кроме вас он никому не нужен.

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

Жостко :)

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

То есть виджет должен называться на Table, а какой-нибудь там Weather или CurrencyRates. Типа что-то ценное именно для вашего домена.

имхо: вижу с тем что спрашиваю текущую имплементацию но через враперы => фукнционал один и тот же. а повторяемость конструкций (врап + колеции (Row::new) навевают DRY. желание убрать BaseWrap (который да, сейчас у меня есть) и использовать интерфейсы через проксю собстно эту тему и вызвало. по мне так логично.
Но оке, я понял, по последнему примеру что прислал (по факту конкретный кейс этой темы)
1) атлас не нужён
2) по примеру андрея (и бориса). Живем с враперами и нормально, просто меньше наследуйтесь.