Эта тема на forum.dklab.ru


БВ: Способ создания превью-страницы в Photo Album Add-on phpBB
Коллеги, объясните, пожалуйста, в чем заключен тайный смысл подхода, который использовал наш уважаемый вьетнамский друг Smartor, при создании своей популярной фото галереи для phpBB.
Суть способа:
Для создания каждой отдельной превьюшки вызывается внешний скрипт php
(album_thumbnail.php) с передачей ему по GET pic_id.
То есть, для создания одной странички, скажем, с 20-ю превьюшками (5х4) "album_thumbnail.php?pic_id=ххх" вызывается 20 раз! Кроме того, сам этот скрипт делает множество проверок и несколько запросов к базе(на мой взгляд, совершенно лишних, так как в вызывающем модуле все необходимые запросы уже сделаны и данные для анализа есть)
В связи с этим у меня вопросы:

Почему бы не сделать это обычной функцией? Какой смысл скрывается за таким подходом? Чем руководствовался автор кода, используя такой способ?

Дело в том, что у меня, даже на локальном хосте, вся эта бодяга жутко подтормаживает.

Очень нужно понять! Срочно! Помогите!

ЗЫ Прошу за сей вопрос ногами не пинать, я хоть и программист со "стажем":gigi:, но с web и php, до недавнего времени, дела не имел, многого не знаю.

Очень нужно разобраться и определиться. Ответьте, пожалуйста.
Спасибо.
Чебурген:
ответ на этот вопрос знает любой человек, когда-либо видевший исходный текст HTML
Для тех, же, кто не видел, есть специльное пояснение. Несколько излишне, по-моему, эмоциональное, но поясняющее суть проблемы: PHP FAQ. Самые основы. ОЧЕНЬ ВАЖНОЕ ЗАМЕЧАНИЕ
Чебурген:
А оно создает превьюшки, или показывает их?
Если именно создает, то нет ему оправдания.
Если картинки лежат в базе - то тем болеее.

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

Код основного сценария:


// Опускаем блок инициализации, проверок, запросов к базе и т.д.

for ($i = 0; $i < count($recentrow); $i += $album_config['cols_per_page'])
{
$template->assign_block_vars('recent_pics', array());
for ($j = $i; $j < ($i + $album_config['cols_per_page']); $j++)
{
// Здесь идет кусок не имеющий отношения к делу

$template->assign_block_vars('recent_pics.recent_col', array(
'THUMBNAIL' => append_sid("album_thumbnail.$phpEx?pic_id=". $recentrow[$j]['pic_id'])
)
// Здесь идет кусок не имеющий отношения к делу
}
}


Шаблон html:

<!-- BEGIN recent_pics -->
<tr>
<!-- BEGIN recent_col -->
<td class="row1" width="{S_COL_WIDTH}" align="center"><a href="{recent_pics.recent_col.U_PIC}" {TARGET_BLANK}><img src="{recent_pics.recent_col.THUMBNAIL}" border="0" alt="{recent_pics.recent_col.DESC}" title="{recent_pics.recent_col.DESC}" vspace="10" /></a></td>
<!-- END recent_col -->
</tr>
<tr>
<!--кусок не имеющий отношения к делу -->
</tr>
<!-- END recent_pics -->


Так вот, скрипт album_thumbnail.$phpEx возвращает изображение превьюхи (проверяет, в частности, есть ли готовый файл, если нет, то создает используя функции GD)
Он достаточно большой, с кучей запросов к базе и проверок (хотя почти все проверки и запросы к базе уже сделаны в основном модуле!)

Вопрос: зачем?
Что это, "криворукость" создателя или гениальная реализация, непонятная простым смертным?
Спасибо.
Евгений Галашин:
БВ:
Первое, что приходит в голову: автор решил перестраховаться.
БВ:
автор решил перестраховаться.
Перестраховаться от чего?
У меня нет большого опыта использования php, поэтому и хотелось узнать у Вас, у кого такой опыт есть, нет ли тут каких-то грабель (Особенно по части безопасности).
Единственное, с моей точки зрения, оправдание такого подхода состоит в том, что он позволяет создавать превьюхи "на лету", не создавая (не храня) файл. (Там даже предусмотрена такая опция, как "кешировать/не кешировать" превьюхи, хотя сам автор настоятельно рекомендует использовать кеширование).
У меня сейчас остро стоит вопрос скорости полного формирования html.

При включенном "кешировании" простая замена
append_sid("album_thumbnail.$phpEx?pic_id=". $recentrow[$j]['pic_id'])
на
"ALBUM_CACHE_PATH . $recentrow[$j]['pic_thumbnail']"
дает колоссальный прирост скорости генерации (происходит практически мгновенно). "Оригинальный код" работает секунд десять. И это на локальном хосте!
Я не вижу причины, чтобы не написать простенькую функцию генерации файла превьюхи (если таковой еще отсутствует) и изменить "оригинальный код" вьетнамского товарища.
Где грабли? Если они есть, то где?
Помогите, очень надо, срочно.
Спасибо.
БВ:
ЗЫ
Сорри, кавычки были лишними :(
Евгений Галашин:
БВ:
Это уже грабли phpBB и никуда от них не деться...
БВ:
Хм... тут какое-то "недоразумение"...
phpBB тут совсем не при делах. Абсолютно! Вопрос относится к php (и html).
Формулирую по-другому:
Чем может быть обусловлено решение вьетнамского товарища при создании документа HTML генерить 21 запрос к серверу, вместо того, чтобы обойтись одним единственным запросом?
Юрий Насретдинов:
при создании документа HTML генерить 21 запрос к серверу, вместо того, чтобы обойтись одним единственным запросом
Кривые лапы, да и только. Хорошо хоть еще что не 200 :) (а ведь бывает и такое, и даже на этом форуме...)
Евгений Галашин:
phpBB тут совсем не при делах.
append_sid("album_thumbnail.$phpEx?pic_id=". $recentrow[$j]['pic_id'])
Если это не phpbb, то я японский лётчик... Ну неважно...

Наконец понял, что Вы имеете в виду... Генерить thumbnail во время генерации html'я? Красиво. Так можно сделать.

Эта тема на forum.dklab.ru