Comments 15
Хм, интересно, всю жизнь сознательно пользовался для этих нужд хендлером =)
А без хендлера эту задачу и не решить (не считая частных случаев). В данном случае он тоже используется, только скрывается от глаз разработчика за контролом-оберткой, который генерирует необходимый запрос.
От решения, которое предлагал XaocCPS или Дино Эспозито отличается, прежде всего, тем, что изображение отрисовывается не тем кодом, который инициализирует собственно контрол. Непосредственно свойств Image и ImageBytes у контрола нет, он просто принимает некие данные, которые потом передает коду, выполняющему отрисовку.
Кэшированием также заведует код для отрисовки (то есть, вы).
Вот я и думаю, насколько такое решение удобно… и полезно…
В CMS, которую мы писали около двух лет назад, одним из «крутых нововведений» стала поддержка динамического вывода изображений. Нужно вставить картинку с холодильником — контент-менеджер взял фотографию и, не думая о бренности сущего, загрузил. А наш движок уже разбирается, какого размера она должна быть, чтобы дизайн не портился и канал не перегружался. И Output-Cache сделали, и на сервере кэширование. Теоретически все просто здорово.
А сейчас стало ясно, что в контент-менеджмент народ разный идет. Некоторые особо продвинутые могут и фотку мегабайт на три-пять загрузить… И вот наша CMS отрисовывает страничку с каталогов холодильников… Загрузили пять мегов, обработали, обрезали, закэшировали минут на десять, переслали клиенту, сделали Dispose()… и так раз… дцать, по количеству этих холодильников на странице. Пользователь посмотрел, посмотрел, да и ушел. А следующий пришел через часок так. Кэш уже очистился давно, и мы снова начинаем нашу работу :)
От решения, которое предлагал XaocCPS или Дино Эспозито отличается, прежде всего, тем, что изображение отрисовывается не тем кодом, который инициализирует собственно контрол. Непосредственно свойств Image и ImageBytes у контрола нет, он просто принимает некие данные, которые потом передает коду, выполняющему отрисовку.
Кэшированием также заведует код для отрисовки (то есть, вы).
Вот я и думаю, насколько такое решение удобно… и полезно…
В CMS, которую мы писали около двух лет назад, одним из «крутых нововведений» стала поддержка динамического вывода изображений. Нужно вставить картинку с холодильником — контент-менеджер взял фотографию и, не думая о бренности сущего, загрузил. А наш движок уже разбирается, какого размера она должна быть, чтобы дизайн не портился и канал не перегружался. И Output-Cache сделали, и на сервере кэширование. Теоретически все просто здорово.
А сейчас стало ясно, что в контент-менеджмент народ разный идет. Некоторые особо продвинутые могут и фотку мегабайт на три-пять загрузить… И вот наша CMS отрисовывает страничку с каталогов холодильников… Загрузили пять мегов, обработали, обрезали, закэшировали минут на десять, переслали клиенту, сделали Dispose()… и так раз… дцать, по количеству этих холодильников на странице. Пользователь посмотрел, посмотрел, да и ушел. А следующий пришел через часок так. Кэш уже очистился давно, и мы снова начинаем нашу работу :)
ну, без сомнения, каждым механизмом нужно пользоваться с умом и прямыми руками
у меня тоже есть печальный опыт создания капчи, которая «временно» хранилась на сервере. Но, как известно, нет ничего постояннее временного и через неделю этих «временных» капчей лежало уже тысячи, пришлось удалять руками
так вот для такой капчи указанное выше решение очень подходит
у меня тоже есть печальный опыт создания капчи, которая «временно» хранилась на сервере. Но, как известно, нет ничего постояннее временного и через неделю этих «временных» капчей лежало уже тысячи, пришлось удалять руками
так вот для такой капчи указанное выше решение очень подходит
Но, как известно, нет ничего постояннее временного
Ну да, мы пока в качестве временного решения при загрузке уменьшаем сохраняемую картинку до 1000 px по ширине (больше обычно не используется), так хоть приемлемо выходит.
Кстати, у GeneratedImage есть еще одно преимущество по сравнению со «старыми» решениями — более «умный» кэш. У Эспозито под картинку генерировался GUID, который сохранялся во ViewState. Соответственно, там, где не происходило PostBack'ов (или юзеры очень часто нажимали F5) толку от такого кэша было немного. Здесь же механизм кэширования более гибкий. Эта же особенность позволяет использовать GeneratedImage (при наличии обертки, естественно) не только с WebForms, но и, например, с MVC.
Остается только один вопрос — а зачем он нужен? :)
один из вариантов — подгрузка картинок из бд
опять же, графики всякие рисовать тоже следует через такой контрол
опять же, графики всякие рисовать тоже следует через такой контрол
Ох уж картинки в БД… :)
С графиками — в принципе-то да, только в данном случае отрисовка отделенная.
То есть, нужно либо какие-то метаданные передавать, либо заново делать все выборки по переданным параметрам… на мой взгляд, это ничем принципиально не отличается от кучки хендлеров graph.axd, image.axd, avatar.axd etc… Разве что только некий общий интерфейс плюс встроенные возможности по масштабированию и обрезке.
Хотя, пожалуй, это не настолько спорный вопрос. Как говорится, был бы инструмент…
С графиками — в принципе-то да, только в данном случае отрисовка отделенная.
То есть, нужно либо какие-то метаданные передавать, либо заново делать все выборки по переданным параметрам… на мой взгляд, это ничем принципиально не отличается от кучки хендлеров graph.axd, image.axd, avatar.axd etc… Разве что только некий общий интерфейс плюс встроенные возможности по масштабированию и обрезке.
Хотя, пожалуй, это не настолько спорный вопрос. Как говорится, был бы инструмент…
ну, можно svg использовать, но это так, скорее экзотика
А почему не решить проблему с картинками таким образом, чтобы на сервере хранилась оригинальная картинка, которую загрузил человек, а вместе с ней все используемые размеры для эскизов в каталоге и т.д. Получаем небольшую избыточность в хранении на HDD (что не есть проблема, имхо), но процессор грузим только при добавлении самой картинки. Если же на сайте надумали сделать редизайн и увеличить/уменьшить изображения, то просто проходимся по всем оригиналам и заново генерируем нужные эскизы.
Или я недопонял проблему?
Или я недопонял проблему?
Наверное картинки лежат в БД, а так да.
имхо лучше хранить пару копий
1. оригинал — пригодится
2. средний размер, для детального просмотра товара
3. маленькая фотка — каталог
при ресайзинге, они много занимать не будут, это не в paint'е сохранять :)
имхо лучше хранить пару копий
1. оригинал — пригодится
2. средний размер, для детального просмотра товара
3. маленькая фотка — каталог
при ресайзинге, они много занимать не будут, это не в paint'е сохранять :)
Нет, Вы как раз поняли все абсолютно верно, и в следующем апдейте все примерно так и будет.
Это мы при изначальной разработке решили схалтурить немного, не создавать лишних метаданных. Исходили тогда из того, что размеры картинок на выходе задает верстальщик, в то время, как схему данных (и все подобного рода параметры) прописывает обычно программист, который вообще ничего может не знать про какие-то там размеры картинок (и дизайн может быть еще не готов). Ну а жизнь, как водится, внесла свои коррективы :)
Спасибо за совет, решение удобное и эффективное.
Это мы при изначальной разработке решили схалтурить немного, не создавать лишних метаданных. Исходили тогда из того, что размеры картинок на выходе задает верстальщик, в то время, как схему данных (и все подобного рода параметры) прописывает обычно программист, который вообще ничего может не знать про какие-то там размеры картинок (и дизайн может быть еще не готов). Ну а жизнь, как водится, внесла свои коррективы :)
Спасибо за совет, решение удобное и эффективное.
Собсна стандартный способ.
Есть альтернативы?
Есть альтернативы?
Sign up to leave a comment.
ASP.NET Generated Image