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