Комментарии 30
«уменьшает изображение в ширину до 100px и в высоту до 150px, а затем делает crop полученного изображения»
я, может спросонья, но не понял, зачем в данном случае еще и crop?
я, может спросонья, но не понял, зачем в данном случае еще и crop?
Что такого серьезного в ресайзе картинок? Рутина, бытовуха.
Красивое название фреймворка — по-украински кохана это возлюбленная :)
Я джуниора напрягал делать генерацию превьюшек, причем скрипт должен был отрабатывать только при условии что кешированной картинки нет, он справился за несколько часов под надзором… + его скрипт не деграл пхп без надобности и тем самым разгружал сервер от лишних телодвижений.
Но в любом случае я рад что вы открыли для себя модуль из стандартной документации вашего фреймверка, это великолепно, а учитывая что щас версия последняя 3.2, вы быстро это сделали!
Но в любом случае я рад что вы открыли для себя модуль из стандартной документации вашего фреймверка, это великолепно, а учитывая что щас версия последняя 3.2, вы быстро это сделали!
Интересно увидеть реализацию
Тоже самое, что и у вас. Только нужно после первой генерации создать картинку по точно такому же адресу. В следующий раз до PHP запрос не дойдет.
Я делал подобное без Kohana… php файл + .htaccess, после которых все файлы в папке можно было ресайзить.
Я делал подобное без Kohana… php файл + .htaccess, после которых все файлы в папке можно было ресайзить.
Делали именно как написал sdevalex
Можно вообще это сделать на уровне nginx-а при желании:)
собственно это логично что «скрипт должен был отрабатывать только при условии что кешированной картинки нет» — иначе в чем еще смысл кэшированиея? что бы каждый раз обрабатывать картинку, еще и кэшировать сверху? O.o
Скажите, чем ваша статья полезнее чем эти:
kohana3.ru/module/image
kohana3.ru/controller
kohana3.ru/route
kohana3.ru/module/image
kohana3.ru/controller
kohana3.ru/route
полезнее этих, я хотел сказать.
Любая статья дополняет знания, согласитесь )
Не согласен. Статья повторяющая другую статью не несет дополнительных знаний. А в этой разве что упоминается ссылка на Imagefly
А я не согласен с ваше гипотезой. Да, это замечание в данном случаи подходит, но когда я писал свой первый пост(Работаем в дороге), оказалось, что до меня была такая статья, но не хватала пару программ которые были представлены у меня…
TimThumb? Более универсальное решение.
А что будет, если сделать запрос к вашему сайту по адресу
/image/resize/2000x2000/path_to_file
и
/image/resize/2001x2001/path_to_file
и так далее?
/image/resize/2000x2000/path_to_file
и
/image/resize/2001x2001/path_to_file
и так далее?
Судя по исходникам, все закончится предсказуемо плохо.
Модуль написан весьма нехорошо — там нет даже перечня настраиваемых допустимых размеров превью.
Мы генерируем превью при заливке файла, ложим их на винчестер и отдаем потом статику «легким» вебсервером.
Есть мнение, что предложенная автором концепция на высоконагруженном ресурсе приведет к проблемам в производительности.
Модуль написан весьма нехорошо — там нет даже перечня настраиваемых допустимых размеров превью.
Мы генерируем превью при заливке файла, ложим их на винчестер и отдаем потом статику «легким» вебсервером.
Есть мнение, что предложенная автором концепция на высоконагруженном ресурсе приведет к проблемам в производительности.
Раз уже статья про этот замечательный фреймворк, то позволю себе спросить в треде: как происходит разработка фреймворка? Давно не отслеживал активности на форуме и что-то на гитхабе не видно новых коммитов.
Как быть? Можно считать Kohana канула в небытие? Мне искренне нравиться этот фреймворк из-за элегантности, но по долгу службы ушел в другие фреймворки, но к этому дальше дышу неровно.
Как быть? Можно считать Kohana канула в небытие? Мне искренне нравиться этот фреймворк из-за элегантности, но по долгу службы ушел в другие фреймворки, но к этому дальше дышу неровно.
dev.kohanaframework.org/projects/kohana3/activity
Имхо, наоборот, разработка идет слишком быстрыми темпами, так как идет явно не туда, в 3.х ветке постоянно ломают работавшие ранее вещи ради непонятных преимуществ. Я бы на месте авторов забил бы на время на ядро и занялся окружением — сделал бы централизованный репозиторий модулей, cli-установщик оных, переработал бы и расширил бы документацию.
Имхо, наоборот, разработка идет слишком быстрыми темпами, так как идет явно не туда, в 3.х ветке постоянно ломают работавшие ранее вещи ради непонятных преимуществ. Я бы на месте авторов забил бы на время на ядро и занялся окружением — сделал бы централизованный репозиторий модулей, cli-установщик оных, переработал бы и расширил бы документацию.
Был ощутимый простой в разработке, но сейчас в ближайшее время стоит ожидать последовательно релизы веток 3.1 (там вообще один тикет остался незакрытым), 3.2 и 3.3.
А почему не генерировать превью при загрузки файла? Или если элементов много делать это демоном.
На одном из сайтов на CMF ModX REVO делал также как и вы, при открытии галереи с более чем 100 фотографиями в изначальном разрешении под 1600px возникали немаленькие нагрузки на сервер, и генерация всех превью занимала секунд 30 минимум, что было выглядело не очень приятно.
На одном из сайтов на CMF ModX REVO делал также как и вы, при открытии галереи с более чем 100 фотографиями в изначальном разрешении под 1600px возникали немаленькие нагрузки на сервер, и генерация всех превью занимала секунд 30 минимум, что было выглядело не очень приятно.
Извините, но отдавать картинки через контроллер это просто ужасно. Для отдачи картинки, каждый раз будет создаваться экземпляр приложения. Я понимаю что можно заставлять браузер кешировать, но при большой посещаемости это не поможет. Как написал Grox, вас просто заспамят разными размерами. Если вы сделаете проверку на размеры, то придется постоянно дописывать их в конфиги при изменении шаблонов и тд.
Если не хотите генерировать превьюшки при загрузке, генерите их при отдаче файла один раз. Что-то типа
Скрипт проверит существование превьюшки соответствующей параметрам, и при наличии сразу вернет ссылку на нее. При отсутствии также вернет ссылку, предварительно, создав саму картинку. Но ссылка будет на сам файл, который можно раздавать как статику.
Если не хотите генерировать превьюшки при загрузке, генерите их при отдаче файла один раз. Что-то типа
<img src="<?php echo Image::show('path_to_original', array('width', 'height', 'crop', ...etc)) ?>">Скрипт проверит существование превьюшки соответствующей параметрам, и при наличии сразу вернет ссылку на нее. При отсутствии также вернет ссылку, предварительно, создав саму картинку. Но ссылка будет на сам файл, который можно раздавать как статику.
> «автогенерация» админ панели для работы с типовыми объектами данных, использование smarty
Вот эти темы было бы интересно осветить
Вот эти темы было бы интересно осветить
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Kohana, Image Preview – это просто