Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Неограниченное количество превью фотографий
|
|||
|---|---|---|---|
|
#18+
Кто как делает превьюшки фотографий, если их много вариантов? Именно сам механизм. Допустим есть фото товаров (оригиналы), их очень много. Теперь каждое фото нужно отобразить к примеру в поиске товаров, в списке товаров, на подробной странице товара, в отзывах, на телефонах (там свои размеры из-за плотности пикселей), в формате webp и т.д. Итого получается большое количество вариантов. Вторая проблема - смена дизайна, то есть если делать превью при загрузке фотографий, то при смене дизайна и размеров фото, все эти превью можно выкинуть в корзину и всё перегружать по новой. Поэтому остановился на варианте ресайза на лету с сохранением в кэш. Формат путей такого вида - http://site.ru/content/image1.png_60x60.png, http://site.ru/content/image1.jpg_120x120.jpg, http://site.ru/content/image1.png_800x800.webp и прочее в таком роде, где http://site.ru/content/image1.png - оригинал. Теперь механизм - идёт запрос на изображение http://site.ru/content/image1.png_60x60.png, его нет, вылетает 404 (где её перехватывать - есть отдельная тема рядом ), разбираем путь, если в нём содержится /content/ и есть расширение, которое соответствует типу "изображение", значит запрос был на рисунок, далее вытаскиваем 60x60 (если оно есть), ресайзим и отдаём сгенерированный рисунок. При повторном запросе существующее изображение будет существовать и его отдаст уже сам IIS. Возможные размеры превью будут заданы вручную, иначе диск забьют. Помимо размеров, в пути можно задавать тип ресайза crop/fit и качество, но это пока не нужно. Проблемы - всю эту фигню в урлах надо парсить, вытаскивая из пути размеры. Вторая проблема - целостность данных. Пользователь закачал новую фотку, а превьюшки старые, нужно с ними что-то делать, иначе они будут отдаваться клиенту. Как вариант - при закачке фото сносить все возможные превью (сначала физически удаляется файл-оригинал, да и превью прицепом, а затем запись в бд), пробегаясь по списку возможных вариантов превью и if (file exists()). Или прицеплять файлвотчер какой-нить, реагируя на изменения в папке и удаляя файлы превью. Также можно пути до превью пихать в базу в момент их создания и при апдейте/удалении записи вычищать превью из бд. Короче здесь много чего придумать можно. Идеи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 13:48 |
|
||
|
|

start [/forum/topic.php?fid=18&msg=38773113&tid=1356945]: |
0ms |
get settings: |
10ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
57ms |
get topic data: |
14ms |
get forum data: |
4ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
| others: | 259ms |
| total: | 426ms |

| 0 / 0 |
