18 октября 2009 в 23:24
Итак, написал модуль пользовательской галереи, что в наличии:
- изображения не ноды
- изображения автоматом пережимаются в максимальные размеры 640*640
- автоматически определяется уникальность изображения (по md5 sum)
- при удалении изображения оно удаляется физически
- при удалении альбома все изображения альбома удаляются физически
- обложка альбома устанавливается из изображений альбома или автоматом - первое загруженное изображение
- проверка валидности изображения по mime
это пока из реализованного
из не реализованного:
- нет коментариев
- нет приватных и "18+" изображений
- загружаются только jpeg изображения
- нет функций поворотов и так далее
так как модуль используется на публичном сайте пока увы не смогу его выкладывать. Желающие могут посмотреть работу на http://ostudio.org/ugallery или обратится лично ко мне за кодом.
Комментарии
обслуждение версии 0.1.a http://ostudio.org/node/6795
обслуждение версии 0.1.e(нынешней) http://ostudio.org/node/6795
А зачем нужен такой модуль? Ведь связкой CCK + Filefield + Imagefield + ImageCache + Views можно собрать галерею любой сложности.
Почему? Отсюда и это следует:
и это:
Эта фишка обычным CCK-виджетом делается + небольшой темизацией
А если мне 800 на 600 надо? Или какое-нибудь другое экзотическое разрешение, под смартфон например? Imagecache тут нужен.
Imagecache_actions
Только не надо мне рассказывать о том, что связка модулей, которую я предложил слишком тяжелая, это не так.
П.С. А к комментам на вашем сайте доступа получить не удалось.
«Почему? Отсюда и это следует: нет коментариев»
ну это всё поправимо. Не сделал нодами потому что в моём данном случае это более удобно.
«нет приватных и "18+" изображений»
Это будем завтра
«А если мне 800 на 600 надо? Или какое-нибудь другое экзотическое разрешение, под смартфон например? Imagecache тут нужен.»
Всё сразу делаю через gd чем через Imagecache - а другие размеры можно будет через админку.
«Только не надо мне рассказывать о том, что связка модулей, которую я предложил слишком тяжелая, это не так.»
тут конкретная задача и всё что вы предложили избыточно
«П.С. А к комментам на вашем сайте доступа получить не удалось.»
Только для зарегеным
ну так уж и любой?
это всего лишь вопрос ресурсов. Верно? Если их достаточно то почему бы и нет?
полезности пока в модуле 0.0
потому как как сказали уже выше, не напрягаясь делается лучше связкой модулей. В мифические - "нам это не подходит" как то в рамках того что сделано - не верится.
Чем не подходит? примеры того что есть в твоем модуле и чего нет в связке модулей? Экономия ресурсов? При той посещаемости и качестве сервиса что там сейчас есть, "стандартные" решения справились бы не хуже.
работает такая связка нормально. не хуже любой другой "супермега_галерки".
"узкие" решения, заточенные под одну задачу сравнению не подлежат.
Одобряю полностью, укзанная Ромкой связка работает как часы при любой посещаемости, поскольку для оправдания этого процесса достаточно просто знать как работает imagecache он тоже один раз создает изображение и потом просто его показывает хоть 1-му пользователю, хоть 1000-му изображение уже на хосте, вьюсы кешируются. (если при посещаемости в 2-3.000 уников жаль денег на VPS то вперед на изобретение велика)
Галлерею можно собрать повторюсь за Ромкой ЛЮБОЙ сложности. Для примера или спора ради (только надо цену спора обсудить
) - вы выбираете любую галлерею на Jquery которую захотите, а я делаю ее демо на друпале с помощью CCK + Filefield + Imagefield + imagecache + views. Из самописа будет только перекрыт шаблон вьюхи чтоб задать нужную структуру HTML для обработки галлереи Java скриптом.
Да. Но только простите автор как раз предоставил "узкое решение".
так как? в счет или не в счет?
прочтите внимательно кому я писал сообщение, не автору поста.
Ты наверное имел ввиду не любой а только при той на которую хватит ресурсов сервера.
Очевидно, что написанное "узкое решение" на тех же ресурсах будет работать обрабатывая большее количество запросов. Будешь с этим спорить?
И тут ты тоже не вполне прав. Если бы было бы так, то сам views бы не развивался верно? Зачем развиваться если и так можно построить все что хочешь любой сложности.
Не ужели ты хочешь поспорить с тем, что правильно написанное специальное решение будет работать быстрее чем связка модулей?
Конечно часто, в том нет необходимости.
Тут очень хорошее сравнении с серийными автомобилями и формулой один. Связка модулей это серийный автомобиль. Не исключено что хороший. Но он никогда не поедет так же быстро как формула. Но и на формуле по улицам не ездят.
Если вернуться к топикообразующей теме, то тут бесспорно, смысл существования такого модуля как он есть сейчас неясен. Разве что джаст фор фан.
Буду
что делает узкое решение?
При заливке обрабатывает картинку и пишет ее на хост и в базу.
Поскольку никакого кеша нет при каждом обращении к странице у нас выполняется SQL который вытягивает данные, далее эти данные необходимо размотать, завернуть в HTML и отдать конечному пользователю - будете спорить что это быстрее чем взять данные из кеша вьюсов?
при отсутствии кеша получаем то-же самое, что и узкое решение, делаем запрос в БД получаем данные, разматываем, оборачиваем, выводим. Процесс фактически один и тот-же по ресурсоемкости.
В чем разница, так это только в изначальном размере самописа против вьюсов (по объему и по занимаемой памяти)+ то что это один модуль а к вьюсам еще надо CCK и т.д. но мы по сути создаем сайт в котором в будущем с минимальными затратами можно видоизменять все что угодно. А на самописах это согласитесь не очень просто (я про минимальные затраты).
один раз продал и потом всю жизнь с этого кормишься.
Самопис = продаже струйника в 1996 году
Вы просто посмотрите в какую сторону развивается вьюс
они оптимизировали запросы в БД, они улучшили пользовательский интерфейс, они улучшили работу с аргументами, добавили множество раздельных настроек для пейджа и блока + добавили огромную шаблонизацию начиная от общего вида вьюса и заканчивая темизацией отдельного поля. Поэтому и говорю что любой сложности, поскольку правила генерации HTML я могу задать такие какие хочу используя шаблоны.
Ещё раз повторяю что модуль был сделан как простое лёгкое решение. Пользователи сайта просили как на вконтакте и чтобы не ноды - неудобно говорят когда всё в кучу. Так же требывалось проверка на уникальность изображений и физическое удаление файлов при их удалении в альбоме. Делалось всё ради просто так и как можно проще так как в drupal api не очень сильно разбираюся
Я очччень сильно сомневаюсь, что автор "узкого решения" знает API Друпала лучше чем разработчики Вьюс и ССК и может написать модуль, работающий быстрее. Откуда вообще уверенность, что ССК и Вьюс работают медленнее самописного решения? Вы проводили сравнительные тесты? Вы хотя бы сравните запросы, генерируемые этим "узким" решением и запросы генерируемые Вьюсами, уверяю вас, последний генерирует максимально оптимизированные запросы.
Не в тему сравнение. Вообще не люблю все эти "а вот давайте сравним разработку сайтов со строительством [автомобилестроением, медициной, и т.д]". Если вы не хотите использовать модули типа ССК, Вьюс, Вотинг АПИ, и т.п., то может быть и использование его API вам кажется лишним? Зачем тогда вообще Друпал использовать? Если использовать вашу терминологию, то да, серийный автомобиль никогда не поедет также быстро как авто формулы один, но и авто формулы один не будет делаться на стандартной платформе типа Друпала. Еще раз подчеркну, я более чем уверен, что связка ССК + Вьюс будет работать быстрее самописного решения, если его не делает профессионал, детально знающий процессы происходящие внутри ядра Друпала и его API.
а давай )))
То что представил нам тут на суд? или вообще?
Ты пытаешься мне сказать что все узкие решения такие? Вот те на.
views это универсальный иснтрумент, созданный для того чтобы сэкономить время за счет ресурсов сервера. Даже просто взяв сам вьюс, и удалив от туда не нужный мне код, который лично я не использую, я уже могу получить инструмент быстрее самого vews и который уже можно назвать узким решением верно?
Никто мне как разработчику, не мешает построить свою систему кеширования, которая будет копией вьюса. Не говоря уже о том, что там где применяются узкие решения, работают люди которые понимают, что кешировать нужно не так. А использовать фронтенды и бекенды с проксированием. Которые будут значительно эффективнее кеша views. В результате чего сам код кеша views ложится мертвым никому ненужным грузом.
Не вполне.
Самописный код, отвечает четко поставленной задаче, и лишён необходимости делать код универсальным. От чего и выигрыш в производительности. если конечно программист не дурак.
Я не спорю, с идеей, что связки модулей это эффективный способ быстро (сейчас и в будущем) решать какой то круг задач.
Я всего лишь говорю о том, что существуют задачи, когда производительности этой связки недостаточно чтобы ее применять. И что в данном случае, предпочитают заплатить программисту, который будет поддерживать код, но получать высокопроизводительное решение.
Ну и еще есть третий паталогический случай, когда сам программист любит считать миллисекунды выигрыша. И там его затраченное время на код, совершенно не играет для него никакой роли.
Да. И зачем они это делали? Неужели от того что им делать больше нечего? Наверное потому, что производительность этого чуда часто оставляла желать лучшего. Верно?
Ну простите. Это уже из области эмипирических рассуждений.
Человек слабо владуеющий api полезет скорее копаться в views и CCK потому что так проще и бытсрее. Чем писать свой модуль.
Тот кто полезет писать для заказчика узко направленное решение понимает сколько на это уйдет времени и сколько это стоит денег.
От простого - сам код views и cck требует бОльшего количества памяти для своей работы чем узко заточеный код.
До более сложного, посмотрите как CCK формирует дополнительные поля. И посмотрите как это же делается при формировании своего собственного типа материала. Не кажется ли Вам что последний код, ЗАНЧИТЕЛНЬО быстрее выполнится?
Для любителей померится запросами, посмотрите просто на количество запросов к серверу. Которые генерирует CCK при формировании материала.
это не очень верно.
и вот почему. Простой пример, mysql сервер, это сервер который разрабатывется высоко проффесиональными разработчиками. Которые только и занимаются тем, что строят БД. В этом сервере есть такая штука как оптимизатор запросов. Который что делает? Верно пытается выполнить запрос таким образом чтобы затратить меньшее количество времени. И часто отлично справляется со своей задачей. Но далеко не всегда.
Разработчик узкого решения, всегда проверит эффективность работы своих запросов. И часто оптимизирует их лучше автомата.
еще раз повторю, чтобы снять некоторое непонимание.
Я не ратую за использование исключительно самописного кода. Я всего лишь говорю о том что есть случаи когда он лучше чем универсальный.
Так собственно и я не говорю о том, что любой самописный код лучше универсального.
И конечно же никогда не дам задание писать такой код программисту который не показал мне что он может.
Конечно сравнения с машинами это отчасти софистика. Но по моему очень наглядно дает понять разницу.
Серийное авто может обслуживать и один человек.
формулу никогда, там нужна целая группа высококлассных специалистов.
Ну в общем да. согласен. Тогда я просто уберу слово формула, и заменю его раллийным автомобилем. Который в любом случае едет лучше, и сделан на базе серийного ))