vrska
Client
- Регистрация
- 07.02.2010
- Сообщения
- 590
- Благодарностей
- 410
- Баллы
- 63
А что лучше?Ну да, погорячился о том, что ХPath не справится. Справится с помощью условия and, но точно также как и классический метод.
Ничем не лучше.
А что лучше?Ну да, погорячился о том, что ХPath не справится. Справится с помощью условия and, но точно также как и классический метод.
Ничем не лучше.
ничем не хужеНичем не лучше.
Кому как удобно. Кому-то классический поиск элементов, кому-то xPath.А что лучше?
проще, быстрее, надежнее , но это бред же.Ты же с кубиками работаешь? Так сравнение будет некорректным.ничем не хуже
астрыч, давай так, чтобы понят что лучше, раз и то и то работает одинаково, то надо понять, что быстрее пишется, то есть надо взять одно условие и составить к нему пути, у кого короче путь выйдет, тот и папа...
Тесты, сравнения, бенчмарки, опросы, голосования будут? Или это просто личное мнение в вакууме?Кому как удобно. Кому-то классический поиск элементов, кому-то xPath.
Просто постоянно советуют xPath потому чтопроще, быстрее, надежнее, но это бред же.
Это пусть доказывают те, кто утверждает что проще, быстрее, надежнее.Тесты, сравнения, бенчмарки, опросы, голосования будут? Или это просто личное мнение в вакууме?
Еще вчера хотел спросить, решил обождать, вдруг будут интересные решения в плане парсинга DOM
а при чем тут кубик не кубик?Ты же с кубиками работаешь?
ну раз другим нечем в данном случае то вот так. ну а че, в целом думаю будет интересноДа и вообще мериться длиной строки как-то странно))
+++Кому как удобнее.
Это пусть доказывают те, кто утверждает что проще, быстрее, надежнее.
Я утверждал лишь, что разницы никакой нет. Кому как удобнее.
Нда... Ну я так и думал, что ответ будет таким.
Я думаю "быстрее" в данном случае, значит быстрее написать чем регуляркуНате вам https://stackoverflow.com/questions/5279786/performance-of-xpath-vs-dom/5281733
Поиск по DOM уделывает xPath. Значит "быстрее" уже вычеркиваем.
Так в xPath тоже возможны регулярки, которые в 99% случаев с поиском элементов не нужны.Я думаю "быстрее" в данном случае, значит быстрее написать чем регулярку
Ты просто зацепился за слово быстрее?Так в xPath тоже возможны регулярки, которые в 99% случаев с поиском элементов не нужны.
backoff же вообще не о регулярках спорит постоянно, а о преимуществах работы xPath vs classic DOM search.
А я зацепился за этот ответ и ожидал, что ты накидаешь что-то интересное, но никак не вопрос на стаке 10-летней давности, где пытаются сравнить производительность Xpath и DOM Api.Можешь доказать как сделать в предложенном случае проще, быстрее и надежнее (жесть) через xPath?
HTML и регулярки злейшие врагиРегулярки более гибкие(можно "виртуозить" так что огого).. но что бы эту гибкость оценить надо быть ну прям профи...
xpath более прост и понятен... чистая логика, даже запоминать почти нечего не надо... шпаргалок хватит ! это потом уже "not, and, |"
Все средства хороши в умелых руках.
нет, я считаю что поиск по xpath конкретно быстрее, чем регулярки, ЕСЛИ изначально НЕ готовить dom под это (а дом никто обычно не готовит (не тримит/экранирует) )Ты просто зацепился за слово быстрее?
Астрыч, я вызываю тебя на дуэль по написанию кратчайшего путиПоиск по DOM уделывает xPath. Значит "быстрее" уже вычеркиваем.

Я к Астрапорту обращался
Остынь, взрослые уже во всём разобралисьАстрыч, я вызываю тебя на дуэль по написанию кратчайшего пути![]()

Смотри там сознание не потеряй, от оттока кровиОстынь, взрослые уже во всём разобрались![]()

(?<=<button).*?>ПодписатьсяДобрый помогите с регуляркой, измучился. Нужно отловить "Подписаться"
Всегда присутствует в начале <button class="c-button далее меняется data-id="рандом">Подписаться</button>
<button class="c-button c-button--primary c-button--subs " data-role="subscribe" data-type="user" data-id="332322">
Подписаться</button>
Заранее Спасибо !


