10 января 2015 в 14:47
Добрый день.
Где-то полгода назад решил разработать проект - сервис, посвященный покупке и продаже натуральных продуктов питания - http://edimnaturalnoe.ru.
В данный момент с помощью этого проекта пользователь может вносить продукты питания, которые он хочет продать, а также осуществлять поиск продуктов с помощью специальной формы (см. рис.).
Контакты продавца и продукты питания реализованы с помощью концепции Organic Groups, где "группой" является торговая точка (там контактная информация о продавце), а "элементом группы" могут являться товары, заметки и т.д.
Такая концепция позволит подключить при необходимости к редактированию точки и товаров новых пользователей.
Данная форма реализована через Form API + Ajax Framework. По мере выбора элементов в "селекте" или двигания слайдера с ценами выборка продуктов перезагружается с помощью Ajax.
Для облегчения ввода информации для новых пользователей ввод информации по первому товару и ввод контактной информации объединены в одну форму (см. рис.)
Для облегчения работы нескольких пользователей на одном компьютере вместо "Моя учетная запись" отображается "%Имя пользователя% - учетная запись".
Для того, чтобы значения, отображаемые в таблице, можно было фильтровать по первым буквам, написал расширение (Extender). Как он работает - можно посмотреть здесь
http://edimnaturalnoe.ru/product-types/myaso-svezhee
А недавно обнаружилась следующая проблема. После того, как был размещен продукт "Черная икра" со стоимостью 10500 рублей, слайдером стало очень проблематично пользоваться. Потому что основная масса продуктов находятся в ценовом диапазоне от нескольких десятков до нескольких сотен рублей, и рабочая область для фильтрации представляла собой небольшой кусочек в левой части слайдера. Пришлось немного допилить свою форму и чуть-чуть код модуля Slider Field, чтобы шаг слайдера был переменным.
В принципе, получилось (см. рис).
Если кому интересно, потестировать работу слайдера можно на форме поиска натуральных продуктов.
Эксклюзивным дизайном для проекта пока я не занимался, сейчас тема проекта сделана на основе AdaptiveTheme + немного мной доработана (вот, цвета, отступы и т.д.).
Размещаю проект сейчас на облачном хостинге dualspace.ru, возможно, в будущем перейду на какой-нибудь VDS/VPS.
Сейчас делаю первоначальное наполнение данных, вылавливаю различные мелкие ошибки и недоработки.
В общем, вот такой проект.
Комментарии
Проще назвать продуктовая доска объявлений. И зачем на форуме темы связанные с производством сайта?
Ну, может быть, кому-то из начинающих разработчиков пригодится или будет интересно.
Кому интересно тот не ходит на продуктовые сайты. А ходит например на д.ру
По мне OG тут ни к чему. Надо было реализовывать через Reference. Нагрузка на сайт была бы меньше
ИМХО
То есть, Вы имеете в виду, что пользователь, к примеру, регистрируется на сайте, далее вводит себе ноду типа "магазин", а далее про вводе нод типа "товар" у него для связи с его магазином будет поле типа "Entity reference", в котором можно будет задать один или несколько магазинов, которые он ввёл ранее ?
Ну, во первых, связь через членство OG и связь через entity_reference - что там, что здесь для связи используется одна таблица в БД. Так что, не думаю, что OG в этом отношении более затратная.
А, во вторых, использование OG позволяет решать некоторые организационные вопросы по взаимодействию с клиентами.
Например, некто регистрируется на сайте под своим логином и e-mail, вводит торговую точку и несколько товаров. Через некоторое время этот человек увольняется с той организации, а доступ к аккаунту остается у него.
Если есть OG, то решается просто - владельцы регистрируются под новым логином и уже своим e-mail, мы их к этой точке привязываем и они продолжают работать - корректируют список товаров, ставят новые цены и т.д.
А без OG как такие вопросы решать, чтобы было и проще и правильнее, чем с OG ?
Я при работе со своим проектом http://palomniki.su (написанным на MODx) уже неоднократно сталкивался и сталкиваюсь с такой проблемой, когда сотрудник регистрируется под своими данными, вводит маршруты, контакты и т.д. Затем, через несколько месяцев мне уже с другого e-mail приходит письмо - "Мы служба такая-то, сотрудник, который работал с маршрутами, уволился, что нам делать ?". Если сотрудник регистрировался под своим личным аккаунтом со своим личным e-mail, то остается только попросить их зарегистироваться уже под своими аккаунтами и открыть им доступ к работе. Считай, та же концепция OG, только реализовано руками.
Ну и кроме всего прочего, у OG есть другие возможности, которые, возможно, будут полезны по мере развития проекта. Например, типы членства. Или еще что-нибудь.
Отличная идея, земляк. Сам думаю о сайте совместных покупок натурпродуктов, но не тяну пока.
Ну, сайт совместных покупок - это все-таки более сложный по структуре сайт, чем доска объявлений.
Там нужно и правила покупок продумать, и доли пользователей в покупке задавать и хранить.
Нормальный сайт такой, молодец.
Спасибо за отзыв.
А ссылка на запятой забавно смотрится.
Чего только люди не придумают, лишь бы фасетами не пользоваться.
Ну, решил вот так сделать, классическим способом
Скажу, что формирование SQL-запросов через db_select реализовал без особых проблем. Структура БД в Drupal довольно грамотная и прозрачная.
Несколько пришлось поотлаживать работу вот этих селектов и слайдера - там одни селекты зависят от других селектов, слайдер при выборе селекта должен пересчитываться, селекты сохраняются в куках и т.д.