Как стать автором
Обновить

Комментарии 30

«уменьшает изображение в ширину до 100px и в высоту до 150px, а затем делает crop полученного изображения»
я, может спросонья, но не понял, зачем в данном случае еще и crop?
Это просто пример, что можно использовать crop из запроса. Убрав "-c", мы просто делаем ресайз картинки.
Что такого серьезного в ресайзе картинок? Рутина, бытовуха.
Как и большинство задач )
Красивое название фреймворка — по-украински кохана это возлюбленная :)
Спасибо КО.
Как всегда этот комментарий в 1-й десятке.
Согласитесь, красивое название )
Соглашаюсь :)
Я джуниора напрягал делать генерацию превьюшек, причем скрипт должен был отрабатывать только при условии что кешированной картинки нет, он справился за несколько часов под надзором… + его скрипт не деграл пхп без надобности и тем самым разгружал сервер от лишних телодвижений.
Но в любом случае я рад что вы открыли для себя модуль из стандартной документации вашего фреймверка, это великолепно, а учитывая что щас версия последняя 3.2, вы быстро это сделали!
Интересно увидеть реализацию
Тоже самое, что и у вас. Только нужно после первой генерации создать картинку по точно такому же адресу. В следующий раз до PHP запрос не дойдет.

Я делал подобное без Kohana… php файл + .htaccess, после которых все файлы в папке можно было ресайзить.
Делали именно как написал sdevalex
Можно вообще это сделать на уровне nginx-а при желании:)
собственно это логично что «скрипт должен был отрабатывать только при условии что кешированной картинки нет» — иначе в чем еще смысл кэшированиея? что бы каждый раз обрабатывать картинку, еще и кэшировать сверху? O.o
Смысл в том что камент мой был выражен в саркастичной форме, дабы показать людям что открытие для себя новых компонентов в своем рабочем фреймверке, не есть великое событие коми нужно делиться со всеми. Лично я так думаю.
полезнее этих, я хотел сказать.
Любая статья дополняет знания, согласитесь )
Не согласен. Статья повторяющая другую статью не несет дополнительных знаний. А в этой разве что упоминается ссылка на Imagefly
А я не согласен с ваше гипотезой. Да, это замечание в данном случаи подходит, но когда я писал свой первый пост(Работаем в дороге), оказалось, что до меня была такая статья, но не хватала пару программ которые были представлены у меня…
TimThumb? Более универсальное решение.
А что будет, если сделать запрос к вашему сайту по адресу
/image/resize/2000x2000/path_to_file
и
/image/resize/2001x2001/path_to_file
и так далее?
Судя по исходникам, все закончится предсказуемо плохо.

Модуль написан весьма нехорошо — там нет даже перечня настраиваемых допустимых размеров превью.

Мы генерируем превью при заливке файла, ложим их на винчестер и отдаем потом статику «легким» вебсервером.

Есть мнение, что предложенная автором концепция на высоконагруженном ресурсе приведет к проблемам в производительности.
Раз уже статья про этот замечательный фреймворк, то позволю себе спросить в треде: как происходит разработка фреймворка? Давно не отслеживал активности на форуме и что-то на гитхабе не видно новых коммитов.

Как быть? Можно считать Kohana канула в небытие? Мне искренне нравиться этот фреймворк из-за элегантности, но по долгу службы ушел в другие фреймворки, но к этому дальше дышу неровно.
dev.kohanaframework.org/projects/kohana3/activity

Имхо, наоборот, разработка идет слишком быстрыми темпами, так как идет явно не туда, в 3.х ветке постоянно ломают работавшие ранее вещи ради непонятных преимуществ. Я бы на месте авторов забил бы на время на ядро и занялся окружением — сделал бы централизованный репозиторий модулей, cli-установщик оных, переработал бы и расширил бы документацию.
Был ощутимый простой в разработке, но сейчас в ближайшее время стоит ожидать последовательно релизы веток 3.1 (там вообще один тикет остался незакрытым), 3.2 и 3.3.
А почему не генерировать превью при загрузки файла? Или если элементов много делать это демоном.
На одном из сайтов на CMF ModX REVO делал также как и вы, при открытии галереи с более чем 100 фотографиями в изначальном разрешении под 1600px возникали немаленькие нагрузки на сервер, и генерация всех превью занимала секунд 30 минимум, что было выглядело не очень приятно.
Извините, но отдавать картинки через контроллер это просто ужасно. Для отдачи картинки, каждый раз будет создаваться экземпляр приложения. Я понимаю что можно заставлять браузер кешировать, но при большой посещаемости это не поможет. Как написал Grox, вас просто заспамят разными размерами. Если вы сделаете проверку на размеры, то придется постоянно дописывать их в конфиги при изменении шаблонов и тд.
Если не хотите генерировать превьюшки при загрузке, генерите их при отдаче файла один раз. Что-то типа
<img src="<?php echo Image::show('path_to_original', array('width', 'height', 'crop', ...etc)) ?>">
Скрипт проверит существование превьюшки соответствующей параметрам, и при наличии сразу вернет ссылку на нее. При отсутствии также вернет ссылку, предварительно, создав саму картинку. Но ссылка будет на сам файл, который можно раздавать как статику.
> «автогенерация» админ панели для работы с типовыми объектами данных, использование smarty

Вот эти темы было бы интересно осветить
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.