Разделы

Прямой эфир

Весь эфир | RSS

Блоги

Все блоги

Управление изображениями для товара

Как это не парадоксально, но управление изображениями — наиболее частый вопрос, который у меня задавали по SBShop. Впрочем, как же без него?

Встречайте — функция управления изображения о которой можно только мечтать! :-)

Впрочем, многое сделано под впечатлением от EvoGallary (не удивляйтесь ощущению дежавю), так как это самый удобный формат на мой взгляд. Но есть и некоторые особенности.



Полный список возможностей:

— добавление / удаление изображений
— массовая загрузка изображений
— загрузка изображений методом Drag'n'Drop
— отображение процесса загрузки
— сортировка с помощью Drag'n'Drop
— подготовка готового набора изображений при загрузке

И еще немного скриншотов. Загрузка методом Drag'n'Drop:



Процесс загрузки нескольких изображений:



Из минусов можно отметить очень важный пункт. Изображений загружаются пока только для существующего товара. У нового товара нет идентификатора и это создает некоторые трудности. В будущем это будет исправлено.
  • +4
  • 17 января 2012, 02:20
  • Carw

Комментарии (42)

RSS свернуть / развернуть
0
Я как то писал CMS на ASP.Net MVC для магазина небольшого.
Сделал АБСОЛЮТНО такую же загрузку изображений, 1 в 1.
Могу сказать, что для администратора сайта это невероятно удобно!
Так что — плюс! (хоть вашим дополнением и не пользовался ни разу)))

Кстати, была та же проблема, что пока нет id -фотки не грузятся)
Могу сказать, как решить:
0. Шаг нулевой, товар еще не сохранен.
1. Загружаем фотки в папку tmp
2. Через ajax возвращаем имя загруженного файла, и складываем их в hidden input, через запятую например.
3. При сохранении товара что делать думаю понятно :)

Дважды так делал, оба раза все ок.
avatar

createit

  • 17 января 2012, 11:13
0
Да, задача вполне решаемая. Единственное, что я больше подумывал сделать временную папку, сразу готовить изображения в ней, как обычно, а затем папку просто переименовать. Но ваш способ имеет существенный плюс — отсутствие мусора, если новый товар так и не будет создан. Но небольшой минус в том, что нужно будет обработать сразу большое количество изображений. И я пока еще не решил как лучше сделать.
avatar

Carw

  • 17 января 2012, 12:06
  • ↑
0
Хм, ну почему же, и ваш способ вполне даже!
Создаете папку «tmp-fh8f3h78asfhj», сохраняете все в нее.
Ну и с периодичностью какой либо ищете папки вида «tmp-*», которые старше недели например, и удаляете их. И нет мусора.
avatar

createit

  • 17 января 2012, 12:09
  • ↑
0
Да, примерно в таком ключе я и думал. Правда сейчас меня потихоньку начинает еще заботить, что файловая структура не лучшим образом сделана. На 10 тыс. товаров будет создано 10 тыс. папок…
avatar

Carw

  • 17 января 2012, 13:36
  • ↑
0
не пинать, может не в тему, но как мысль, возможно такое и в Ево возможно.
Процес сохранения нового документа.
POST запрос с данными
1) идёт создание и сохранения самого документа
$dok = $modx->newObject('myTovar');
.........
$dok->save(); //сохранили
$dok_id = $modx->lastInsertId(); //id последнего созданного документа
// или можно так получить id
$dok_id = $doc->get('id');

ну и дальше сохраняем инфу и картинки уже привязанніе к id.
Всё одним махом, и без дополнительных телодвижений.

Надеюсь. что поняли, о чём я написал.
avatar

valikras

  • 17 января 2012, 15:06
  • ↑
0
т.е. изначально. не нужно хранит фотографии на диске — хранить нужно в памяти.
т.е. при передачи с формы изобрадения к примеру с name=file1, будет доступен по $_FILES['file1']['tmp_name']
avatar

valikras

  • 17 января 2012, 15:14
  • ↑
0
А вот храниться изображения на диске придется так или иначе. Они же через Ajax передаются. На каждую картинку отдельный процесс.
avatar

Carw

  • 17 января 2012, 15:22
  • ↑
0
Сохранить-то без проблем можно. Даже при открытии формы создания товара. Но может еще быть ситуация, когда менеджер просто открыл создание товара, но потом отвлекся, ушел, забыл, передумал и т.д. И у нас появляется товар-зомби. Придется бороться с ними. :)
avatar

Carw

  • 17 января 2012, 15:21
  • ↑
0
хотя, может и вы правы, не стоит усложнять себе жизнь.
Возьмём процес создания ресурса в Модекс,…
т.е. создаём документ,… пишим,… калякаем…
потом, хотим поменять шаблон, нажимаем быбираем — и… идёт перегрузка документа, т.е. сохранения…
И есть обязательные поля для заполнения,…
Одним словом — товар-зомби — отпадает…
Как идея, может в таком духе???
avatar

valikras

  • 17 января 2012, 15:31
  • ↑
0
Там нет сохранения при перезагрузке. Во всяком случае в Evo. Перезагрузка по сути нужна только для того, чтобы вывести список TV-параметров в соответствии с выбранным шаблоном.

А далее, когда мы нажимаем сохранение, то создается уже товар. Я придерживаюсь схожего принципа.

Кстати, а ведь это идея — можно посмотреть как в EvoGallary сделана работа с картинками в новом документе. Ведь там должна возникнуть схожая ситуация.
avatar

Carw

  • 17 января 2012, 15:40
  • ↑
0
я процесс рассказывал в Рево, документ не перегрузится, если не будет заполнено поле pagetitle, и после перегрузки. у нас появляется индефикатор id ресурса.

Уже думал не отвечать, так как вижу, что я немного не совсем в курсе создания документов в Ево и возможно что-то не ту мысль высказываю.

Просто хотел сказать, при добавлении фото, или других параметров связанных с id ресурса, сначало проверяется на заполнение обязательных полей, потом идёт создание документа с перегрузкой, ну и дальше просто set — добавляем уже…
Так сделанно в Рево…
avatar

valikras

  • 17 января 2012, 16:07
  • ↑
0
Вот оно что… Ну у меня есть тайная идея вообще не перезагружать товар, а все возложить на Ajax. Но вероятно я тоже приду к тому, что без идентификатора будет невозможно что-то сделать.

Спасибо за идею, в любом случае!
avatar

Carw

  • 17 января 2012, 16:19
  • ↑
0
на аяксе. точно в таком духе,… т.е. юзер хочет добавить фото, идёт проверка обязательных полей (согласитесь, ведь это еденицы, которые сначало фото добавляют а потом товар), если нет,… просим заполнить, если да,… создаём аяксом док и уже с id работаем дальше.
Не вижу проблем в аяксе.
avatar

valikras

  • 17 января 2012, 16:25
  • ↑
0
То есть когда пользователь хочется загрузить картинки, то мы сразу автоматом проверяем создан ли документ… Если не создан, то создаем. А ведь правда, если это все будет происходить неявно и не требовать от пользователя лишних действий, то будет удобно. Это отличный компромис!
avatar

Carw

  • 17 января 2012, 16:42
  • ↑
0
Сделайте примерно такую структуру папок =)
id=1
папка — /1/1/1
id=12
папка — /1/2/12
id=34
папка — /3/4/34
id=7845
папка — /7/8/7845
avatar

createit

  • 17 января 2012, 16:10
  • ↑
0
То есть 3 уровня вложенности. Как это работает на практике, не в курсе? Я сталкивался с гораздо более сильными уровнями вложенности, но перекос в глубину ничем не лучше, чем в ширину.
avatar

Carw

  • 17 января 2012, 16:47
  • ↑
0
Ну при таком подходе вложенность небольшая получится, что уже само по себе хорошо, а максимальное кол-во папок на одном уровне при 10000 товаров — 100. Что очень даже неплохо! Для магазина думаю нормальный вариант!
avatar

createit

  • 17 января 2012, 16:50
  • ↑
0
А если так:

id=1
папка — /1
id=12
папка — /1/2
id=34
папка — /3/4
id=7845
папка — /7/8/4/5

?
avatar

Carw

  • 17 января 2012, 16:48
  • ↑
0
По мне не очень… будут в папке 1 лежить и фотки первого товара и папки всех товаров 10-19, 100-199, 1000-1999
Плохо как то…
avatar

createit

  • 17 января 2012, 16:52
  • ↑
0
Нет, я предполагал, что уровень вложенности равен количеству чисел. Т.е.

id=100
папка — /1/0/0

id=1001
папка — /1/0/0/1

Правда не могу пока представить не возникнет ли перекоса в какую-то сторону.
avatar

Carw

  • 17 января 2012, 17:08
  • ↑
0
У вас в папке /1/0/0 будут лежать:
image1.jpg
image2.jpg
image3.jpg
/1/image1.jpg
/1/image2.jpg
/1/image3.jpg
Я бы так не делал…
avatar

createit

  • 17 января 2012, 17:11
  • ↑
0
Да, предположительно такая картина и будет. Пока не понятно на сколько это имеет смысл.
avatar

Carw

  • 17 января 2012, 23:09
  • ↑
0
А… еще явный косяк в том, что какие-то папки будут транзитными (в них вложены еще другие папки), а какие-то конечными. Конечные нужно удалять при удалении товара (по идее), а транзитные удалять нельзя.
avatar

Carw

  • 17 января 2012, 17:10
  • ↑
0
а вы транзитные и не удалите.
т.е если использовать конструкцию 
rmdir($dir);
, то если есть вложения, то папка $dir не удалиться.
Для того, чтобы удалить папку с вложениями, обычно делают обход папки, улаляют сами файлы unlink, и тогда только rmdir.
Я не знаю, на сколько это верно, но я удаляю папку с вложениями без обхода, просто командой
system("rm -rf $dir");
avatar

valikras

  • 17 января 2012, 17:43
  • ↑
0
А если в $dir придет "/"? ;)
avatar

alooze

  • 17 января 2012, 17:46
  • ↑
+1
глупый вопрос… :)…
хотел не отвечать,…
а если сделать проверку на "/"? я думаю, жто изначально должно проверяться…
avatar

valikras

  • 17 января 2012, 17:48
  • ↑
+1
А че сразу «глупый»? =) Нормальный вопрос. Вкупе с ответом — добрым молодцам-копипастерам урок.
avatar

alooze

  • 17 января 2012, 17:52
  • ↑
+2
сори,… я просто увлёкся…
Вы правы, мы же не одни…
avatar

valikras

  • 17 января 2012, 17:57
  • ↑
+1
Не думаю, что это «не верно», просто немного не православно как-то… :-)
avatar

Carw

  • 17 января 2012, 23:08
  • ↑
0
Поставил последнюю версию с гитхаба, не хватает файла 
jquery.dragsort-0.4.3.min.js
по адресу
/assets/libs/javascript/
взял отсюда
http://crazyhr.com/demo/dragsort/jquery.dragsort-0.4.3.min.js
Все заработало

avatar

vanchelo

  • 1 февраля 2012, 06:09
0
Видимо не выгрузил скрипт…
avatar

Carw

  • 1 февраля 2012, 11:54
  • ↑
0
Есть ли возможность чтобы при сохранении форма редактирования не закрывалась!
И есть ли возможность копирования товаров и категорий!
avatar

vanchelo

  • 1 февраля 2012, 06:11
0
Чтобы при сохранении не закрывалось — пока не сделано. Хотя и не особо сложно это добавить.

Копирование товаров есть давно и отлично работает. Очень часто используется.

Копирования разделов нет и сложно представить зачем оно нужно. Раздел же содержит уникальную информацию и товары в нем, по идее, должны отличаться. Для какой цели может понадобиться копирование раздела? Нужно ли при таком копировании и товары дублировать?
avatar

Carw

  • 1 февраля 2012, 10:57
  • ↑
0
В выпадающем списке нет пункта копирования товара! Подправил tree.inc.php добавил пункт «Копировать товар». Все хорошо, но если есть изображения то оно копируются пустыми квадратами, и удалить их не получается, пишет ошибка при удалении изображения! Что можно сделать
avatar

vanchelo

  • 1 февраля 2012, 14:30
  • ↑
0
Ага… спасибо за сообщение. Это однозначно глюк. Изображения нужно удалять, но я забыл об этом.

По поводу отсутствия пункта «копировать товар», странно. Проверю к следующему коммиту.
avatar

Carw

  • 1 февраля 2012, 22:34
  • ↑
0
А вообще есть ли возможность не с диска загружать картинки, а через файленеджер?
avatar

vanchelo

  • 1 февраля 2012, 23:17
  • ↑
0
В данный момент фактически нет. Здесь при загрузке идет сразу подготовка набора изображений. В общем-то можно сделать механизм, который будет работать в ином режиме, но с ним связано много проблем. В целом API для изображений есть и сделать любой вариант не сложно.
avatar

Carw

  • 1 февраля 2012, 23:36
  • ↑
0
А что подправить чтобы изображения при копировании товара удалялись?
avatar

vanchelo

  • 1 февраля 2012, 23:43
  • ↑
0
Нужно найти место где происходит копирование товара и исправление его параметров. И там изменить массив с изображениями.
avatar

Carw

  • 1 февраля 2012, 23:47
  • ↑
0
Здесь? 455 стр. prod.mode.php
public function copyProduct()
avatar

vanchelo

  • 1 февраля 2012, 23:54
  • ↑
0
Все верно. Единственная проблема в том, что метода очистки изображений вообще нет сейчас. Поэтому если все сделать по простому, то нужно открыть /core/product.php и там создать метод типа:

public function delImages() {
	$this->aImages = array();
}


А в copyProduct() соответственно вызвать этот метод.
avatar

Carw

  • 2 февраля 2012, 00:02
  • ↑
0
спасибо, то что надо! Добавил метод в product.php, а в prod.mode.php после 467 строки:
/**
* Чистим массив с изображениями
*/
$this->oProduct->delImages();
avatar

vanchelo

  • 2 февраля 2012, 00:38
  • ↑

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.
© Сделано на LiveStreet
Дизайн - ©2009 MODx RED Group