Я задолбаюсь ваять из него отдельное приложение, все скрипты плотно завязаны на фанфикс, от авторизации до БД.

Вот основные скрипты парсинга шапок и глав: https://pastebin.com/5RGemsi4
Там где-то полный трэш, где-то более-менее код, где-то комментарии от кэпских до важных.

ReFeRy
Ми-ми-ми, спасибо, будем пилить :)

Мдя, парсить лапше-html регэкспами — это боль.

Реф, есть неплохая библиотека для парсинга html: DiDOM (а также всякие phpQuery и simplehtmldom). Есть штатный класс DOMXPath. Это я так, на будущее и на всякий случай подкидываю.

О скоко их разных.

Wave
Это что за тест? Цифры страшные. У меня бывало, что ФвФ за день по 20000 произведений обновлял - в одном потоке и незаметно для работы всех сайтов на том же сервере. Или тут время на 100 или там 1000 циклов?

На тест я не посмотрел, я просто случайно ухватил краем глаза и скопипастил ради перечисления библиотек на пыхе, предназначенных для парсинга html.
Зы. DomCrawler — это компонент Симфонии.

Ага, это как раз
https://github.com/Imangazaliev/DiDOM/wiki/Сравнение-с-другими-парсерами-(1.6.3)



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

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

Как будто перестановки и редизайн не ломают разбор регулярками. Если глянуть на подобный ужас:

Не, я тебя понимаю, дубовые простые надёжные способы — наш бро. Но ты сам писал когда-то, что когда устраивался на работу и сказал на собеседовании, что не владеешь даже ООП, с тебя офигели и не поняли, зачем ты вообще туда пришёл. И т.д.

Wave
Год назад. Тимлид так растеряно отложил листочек с вопросами и сказал, что даже не знает, о чем меня тогда спрашивать. Хорошо, что кроме него там же был более опытный товарищ - поговорили о моем опыте и навыках. Через три дня я вышел на работу, у них оказалось очень много работы именно для меня, а не для современных джунов, знающих только фреймворки.

То есть, ты всё-таки будешь отрицать полезность использования ООП, паттернов, средств командной разработки, деплоя, тестирования, контроля версий и тому подобного?

Wave
Конечно, нет. Я лишь считаю, что в некоторых случаях можно всё это и не использовать.

Ого, что я пропустил. Склонил себе, на всякий случай.

ReFeRy, преимущество использования библиотек для парсинга DOM в том, что они не сломаются, если в разметку добавятся новые аттрибуты, например, а твоя регулярка — сломается. Да даже вон из примера выше, если шрифт изменят, то работать регулярка твоя уже не будет.

Styx
Тут все очень спорно, поменять можно много что. Регулярки тоже можно по-разному писать. Я особо не заморачивался. Собственно, вы оба похоже невнимательно прочитали тот мой комментарий - я не писал, что регулярки устойчивее к изменениям кода, я писал, что библиотеки не имеют в этом отношении особого преимущества.

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

ReFeRy, xpath, например. А шрифт может и не меняться, может пробел добавиться, или точка с запятой убраться — и всё, регулярка уже не работает. Они вообще не совсем для этого.