Чтобы можно было выбирать сущности прямо из результатов поиска. Это, кстати, не развернутый вид. Он при поиске показывает своего родителя (чтобы визуально отличать одноименные вложенные сущности).
Для моих микропроектов не нужен громадный слон под названием Зенд. Хотя вообще Зенд мне нравится и я ничего против этого фреймворка не имею.
Возможно, в моем случае, проще было бы создать пачку методов и свойств для работы с курлой в классе «паука». Но помимо аггрегатора комиксов у меня еще есть аггрегатор IRC-логов в формате Эггдропа. И еще пара схожих штуковин. Копипастить в них один и тот же код я счел не комильфой. Писать единого «паука» для них и вовсе невозможно из-за довольно разных подходов к добыванию контента для разбора.
Вот почему на выходе получился все-таки отдельный модуль.
1. У меня не было задачи переносить весь функционал Курлы в ООП.
2. Подчеркивание в именах методов в большом объеме ИМХО кода читаются гораздо лучше, нежели конструкции вроде $this->myMethodName();. Впрочем, это вкусовщина и холиворить я на эту тему не собираюсь. Равно как и менять этот синтаксис.
3. Я не вижу, чем конструкторы в виде статических методов будут объективно лучше той структуры работы, которая есть сейчас. Другое дело, что скорее всего я выделю респонс и реквест в отдельные классы, как тут уже советовали выше.
4. Если не затруднит, поделитесь, пожалуйста, ссылками на свои обертки. Я их вывешу в топике в разделе «Альтернативы», чтобы другие люди могли выбрать ваши скрипты для своих нужд.
Куки автоматически разбираются в объект $Snufkin->response->head->cookies, откуда их можно легко доставать при необходимости. И сохраняются в файл, если путь к нему указан в настройках.
Кстати, спасибо что напомнили про Пеар. Пойду добавлю в аналоги.
Возможно, в моем случае, проще было бы создать пачку методов и свойств для работы с курлой в классе «паука». Но помимо аггрегатора комиксов у меня еще есть аггрегатор IRC-логов в формате Эггдропа. И еще пара схожих штуковин. Копипастить в них один и тот же код я счел не комильфой. Писать единого «паука» для них и вовсе невозможно из-за довольно разных подходов к добыванию контента для разбора.
Вот почему на выходе получился все-таки отдельный модуль.
2. Подчеркивание в именах методов в большом объеме ИМХО кода читаются гораздо лучше, нежели конструкции вроде $this->myMethodName();. Впрочем, это вкусовщина и холиворить я на эту тему не собираюсь. Равно как и менять этот синтаксис.
3. Я не вижу, чем конструкторы в виде статических методов будут объективно лучше той структуры работы, которая есть сейчас. Другое дело, что скорее всего я выделю респонс и реквест в отдельные классы, как тут уже советовали выше.
4. Если не затруднит, поделитесь, пожалуйста, ссылками на свои обертки. Я их вывешу в топике в разделе «Альтернативы», чтобы другие люди могли выбрать ваши скрипты для своих нужд.
Ссылка вот: www.silkleo.ru/comix/html/twenty/
«html» в урле можно заменить на rss или atom, чтобы получить соответствующий формат.