Vigoros
|
Posted: Tue Oct 02, 2007 13:58 Post subject: Re: photofile 2.0.0 |
|
|
Hram wrote: | Выкладываю новую версию плагина с целью проверки его живучести, а точней его HTTP клиента. |
Качает как и прежде - без сучка и задоринки.
Если только удается добраться до альбома.
А не пускает в альбомы с эросодержанием - выкидывает табличку с надписью Access violation at address... (Тотал остается на плаву.) При этом в папке с плагином создается файлик с отчетом об ошибке.
В альбомы с защищенными оригиналами пускает, но вместо оригиналов или хотя-бы их large-копий скачивает только картинки no_photo.gif под именем запрашиваемой фотки.
Это конечно не самоцель, но может удасться преодолеть эти барьеры? Было бы здорово!
Hram wrote: | [+] новый проект на VC |
Прошу прощения за тупой вопрос - здесь идет речь о Visual C?
Hram wrote: | [+] заложен механизм работы по конфигу, что позволит самостоятельно расширять поддерживаемые плагином сайты |
За это особенная благодарность. Осталось только разобраться в синтаксисе и пунктуации Нельзя ли поделиться хотя бы минимальной информацией - кто есть кто? А то я уже всю голову сломал, делая предположения - как же это расшифровывается и где что подкрутить, чтобы внешний вид отображения привести к желаемому.
Какие-то схожие моменты нахожу, но элементы типа `[^\/]+` или `Match[6]` ставят меня, мягко говоря, в тупик. А откуда и каким содержимым наполняются переменные %s и %d? (Ну не программер я, а юзер; для меня это не очевидно.)
И еще, можно ли раскрыть (в общих чертах) секрет работы плагина? Я так понимаю - запрашивается определенный html-файл, он препарируется (парсинг?) с целью извлечения нужных ссылок и данных, и уже последние выводятся в удобоваримом виде. Где-то так? Если в открытую докладать не хочется, то можно в РМ? Я, если разберусь, то еще помогу где-нить.
А что если для ФФ парсить странички типа `http://photofile.ru/frame/{username}/{album_number}/`? По результатам моего анализа там присутствует вся необходимая информация о населяющих альбом фотках. Отпадает нужда в "перелистывании" страниц альбома. Более того там ява-скрипт заполняет какой-то массив. Может можно взять эти данные и использовать в личных целях? (Последнее предположение от чайника, может все и не так как на самом деле.)
Hram wrote: | [+] копирование сразу нескольких альбомов |
Это полный руль, благодарствую!
Hram wrote: | [+] короткие имена файлов вместо их url |
Но это же регулируется нужными строчками в конфиге, если кому нужно к другому виду прийти?
Hram wrote: | [+] хеширование скачаных фотографий |
Простите, ничего не понял из этого ругательства Чем нам это помогает жить?
Hram wrote: | [*] не "вылетает" при отсутствии соединения |
При переключении из приложения в приложение и обратно список фоток (альбомов) остается на месте.
А если в пределах одной панели ТС поиграться табами, то опять перезапрос соединения. Вернее так. Если альбом вызван из закладок, то этого не происходит, а если задан на соединение пользователем, то вот.
И еще выловился один глюк. Но это скорее ошибка формирования урла фотки.
Как выяснилось ФФ чувствителен к регистру букв в адресе ссылки. В нашем случае к расширению файла. И если мы запросим фотку с именем 27275705.jpg вместо положенного 27275705.JPG, то фиг чего получим от сервера, вернее получим но_фото.гиф.
Вот классический пример разнобоя - `http://photofile.ru/users/natalims/370929/`. В подписях к фоткам невооруженным глазом видно, где какой регистр используется.
И еще одно наблюдение. Не все залитое на ФФ имеет формат jpg, есть еще и png, и gif.
Это я к тому, что простое подставление к вычисленному адресу расширения jpg, не во всех случаях гарантирует скачку альбома целиком.
Отсюда следует, что инфу со страниц нужно выдирать тщательнЕе.
ЗЫ. Откуда бы еще выковыривать размеры фоток, хотя бы приблизительные? А то нолики в столбце "Размер" смотрятся как-то предательски, в то время как общий размер альбома может легко тянуть мег на 600
Спасибо за внимание. |
|