vrska
Client
- Регистрация
- 07.02.2010
- Сообщения
- 589
- Благодарностей
- 408
- Баллы
- 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>
Заранее Спасибо !