[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Пути для хранения фото.С каким слешом?
Страницы: 1, 2
sharki
Joker
ну тогда почему бы не следовать всем принципам ООП, и не замутить декоратор?)
killer8080
я так понял, изначально вопрос был:
Цитата (Гость_игорь @ 14.01.2013 - 16:18)
В каком виде лучше хранить путь к картинке в базе данных, с / или \ слешом.

Ответ - всегда используй /, а на DIRECTORY_SEPARATOR уже давно пора забить.
Joker
sharki
ну потому что в пхп нельзя использовать ООП в полном его объеме) к сожелению)

Цитата (killer8080 @ 15.01.2013 - 16:34)
Ответ - всегда используй /, а на DIRECTORY_SEPARATOR уже давно пора забить.


хоть я с этим и согласен) все равно всегда использую DS)
sharki
Цитата
ну потому что в пхп нельзя использовать ООП в полном его объеме) к сожелению)

О_О??
ты про какой пхп говоришь, про 5.2? с 5.3 ты сможешь почти любой паттерн натянуть, уж декоратор точно
Joker
Цитата (sharki @ 15.01.2013 - 16:45)
О_О??
ты про какой пхп говоришь, про 5.2? с 5.3 ты сможешь почти любой паттерн натянуть, уж декоратор точно

нет технически да можно, нельзя из за того что это будет ООООООчень медленно тогда) как получилось в ZF


сделали бы еще множественное наследие вот былоб круто)
dron4ik
Цитата (Joker @ 15.01.2013 - 11:30)
удачи вам с таким запросом, т.к. когда требуется разнести на сервера то тгда нагрузка выше некуда, то такие запросы у вас просто не выполнятся тупо всё зависнет и вам вставят в одно место таких люлей....

смешно... честно)))

Что мне стоит перекинуть сайт с одной базы на другую? или создать временное поле? если уж станет вопрос сделать фейсбук, то проблем таких там тупо не возникнет... а воротить библиотеку для роспарсить строку и сформировать урл просто не рассудительно...

как тот чувак с книги писал... что то типа, "это пхп детка... все делаем как проще..."(я снова утрирую!)

_____________
Ex3m.com.ua — Активный образ жизни
Joker
dron4ik вопрос простой, сколько лет проф стажа как пхп разработчика и уровень зп относительно среднего по городу
sharki
Цитата
нельзя из за того что это будет ООООООчень медленно тогда) как получилось в ZF

Ты гонишь что-то...
Пожалуй на этом я свои мысли прекращаю вещать)
dron4ik
Joker какую это имеет связь с вопросом?

несколько раз набирал текст и стирал, потому что понимаю какой холивар последует...

Наверное с меня хватит...

_____________
Ex3m.com.ua — Активный образ жизни
Joker
dron4ik
ок, напиши ток одно, я даже коментить это не буду т.к. не будет надобности

таблица news

id|title|img
1|title1|/image/original/img_name1.jpg
2|title2|/image/original/img_name2.jpg
3|title3|/image/original/img_name3.jpg

на сайте надо вывесте 2 картинки:
1 - в списке новостей маленькую 50x50
2 - большую в самой новости 300x300

покажи как ты это будешь делать)))) и сразу всё станет очевидно
dron4ik
Joker
в таком варианте я их за кеширую... т.к. будет проще изменять в случае переливки...

если же это аватарки или прочая требуха которую нужно один раз отресайзить и хранить, то сложу /image/original/th/img_name1-50x50.jpg и /image/original/th/img_name1-300x300.jpg

или же /image/pre50/img_name1-50x50.jpg или /image/pre50/img_name1.jpg

как больше нравится... вариантов не счесть!

_____________
Ex3m.com.ua — Активный образ жизни
Joker
То что один раз отресазить и сложить в нужные папки эт понятно.

Если я правильно понял ты создаш в бд 2 поля?) для 2 вариантов?)
dron4ik
Joker
в случае с блогами или журналами нет...
потому что так картинки могут часто изменять, и их проще кешировать... тобишь хранить адрес оригинала, а по запросу выдавать обработанные превьюшьки с какой-то папки кеш или ресайзить на ходу... в зависимости от требований, если на страницах по 100 картинок, то это провальная затея...

а если для быстроты выдачи, при загрузке можно отресайзить, и сложить их где-то рядом но если размер прописан в контролере а не шаблоне...

_____________
Ex3m.com.ua — Активный образ жизни
Nikitian
Цитата (Joker @ 15.01.2013 - 15:13)

....
<body>
<img
src="<?php image_url($ava,'50x50'); ?>" />

и если даже что то поменяется в хранении картинок верстальщики не когда об этом даже не узнают) и делать им не чего не придется)

Делаю проще. Есть прописанный набор допустимых размеров. Это чтобы отсечь неадекватные запросы.
При запросе картинки если ответ 404, то обработка передаётся бэкенду. Запрос идёт вида http://site.ru/uploads/images/a03/cc5/a03c...5_thumbnail.jpg Из запроса видно, что требуется от оригинала a03cc5015cc7393a3417aef487a5cfb2.jpg сгенерировать тумбу (изоюражение, вписанное по меньшей стороне в размеры с обрезкой большей стороны) с размерами 204х145 и имеется имя оригинала. Тумба генерируется и сохраняется по указанному адресу. В следующий раз запрос до апача даже не доходит и файл успешно отдаётся nginx или лайти каким-нибудь. Таким бразом, если требуется изменить размер или способ формирования картинки, достаточно внести допустимые параметры в общий вайт-лист и поменять шаблон - картинки буду генериться по мере необходимости автоматически. Такой подход использую довольно давно и в целом он выполняет свою задачу оцень хорошо.
В базе есть табличка с именами оригиналов (найи и удалить оригинал и все его копии можно по маске), типом сущности и идентификатором. Обычно типом сущности является табилца, а идентификатором - идентификатор элемента в этой таблице. Т.е. есть товар в табице goods с id 100500 и у него есть несколько изображений, находящиеся в общей таблице изображений с типом сущности goods и идентификатором сущности 100500. Все выборки удобны, работа в целом понятна и удобна. Важно понимать, что имя изображения в таблице изображений не может быть уникальным т..к одна картинкаа может соотетствовать разным товарам и даже разным типам сущностей. Теоретически это может привести к проблемам при удалении - надо проверять, нет ли ещё завязок на картинку, но на практике просто отказался от физического удаления файла. Мето при нынешних ценах на железо реально резиновое :)
dron4ik
Ну вот...
когда то юзал что-то типа готового timthumb.php только слегка переделал дабы он отдавал не себя с хедером картинки, а путь самой картинки... кстати нужно прикрутить куда то снова)))

_____________
Ex3m.com.ua — Активный образ жизни
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2025 Invision Power Services, Inc.