Начата разработка Commerce 2.x под Drupal 8

Пока, медленно но уверенно Drupal 8 близится к своей первой betta-версии, комманда drupalcommerce взялась за разработку Commerce 2.x под 8-ку.

Так в Париже, ребята, занимающиеся разработкой и продвижением Drupal Commerce начали разработку Drupal Commerce 2.x. Недельный спринт начался с дискуссий относительно архитектуры, с использованием опыта команд, занимающихся поддержкой продукта.

Bojan описывает архитектуру сущностей
Commerce 2 планируется довольно глубоко переработать, для его соответствия идеологии Drupal 8. В команду разработчиков новой ветки Commerce будет включен активный участник сообщества Drupal Commerce - Bojan Zivanovic.

В стартовом спринте Commerce 2.x помимо активных участников сообщества Drupal Commerce приняли участие и специальные гости, такие как Fabien Potencier (Symfony), Thomas Rabaix (Sonata), Franck Stauffer (RBS Change).

Первоочередными задачами в разработке Commerce 2.x стали шаги по созданию базовых PHP библиотек, которые могли бы использоваться в других eCommerce проектах или как самостоятельные приложения. Начать решили с написания pricing library (управление ценами, налогами, скидками и т.д.) и address library.

А теперь несколько подробно о некоторых нововведениях которые нас ожидают...

Магазины

Commerce 2.x будет включать новую сущность магазинов (store entity), которая уже была закоммичена в 8.x branch на drupal.org. Перспективы использования данной сущности весьма широкие, так с ее помощью можно будет организовывать multi-domain stores, multi-seller, fulfillment centers (центры реализации).

Обсуждение требований entity storage с Yves Chedemois

Архитектура товаров

В новой версии мы распрощаемся с дисплеем товара под средством нод. Товары теперь самостоятельно будут отвечать за отображение товарных страниц.

Хотелось бы заметить, что, довольно таки давно, когда в нашей комманде стоял вопрос выбора основной платформы под eCommerce проекты, именно такая модель (когда дисплеем товара управляет нода) была основной причиной отказа от  Commerce  и основанных на нем сборок, ибо на мой взгляд это идеологически не правильно.

Товары будут поддерживать иерархию - т.е. можно будет объединять несколько товаров в один с помощью иерархии. Это очень полезно в том случае когда у вас в магазине товары имеют различия например в цветах и размерах:

Пример иерархии товаров в Commerce 2.x

При этом администратор, при настройке архитектуры типа товара, будет сам определять какие "уровни" иерархии товаров могут отображаться независимо, т.е. иметь собственные уникальные адреса, а какие будут редиректить пользователя на страницу родительского товара. Также можно будет настроить какие из уровней будут классифицированы как реально продаваемые товары (actual purchasable SKUs).

Такая структура позволит получить:

  1. Простоту генерации формы добавления в корзину. Больше не потребуется загружать и обрабатывать все вариации товара при рендеринге формы. Вся необходимая для этого информация будет доступна в описании типа товара.
  2. Наследование полей. К примеру добавленное изображения к товару "Blue" будет автоматически использовано всеми его дочерними товарами. Настройка наследований предполагается для каждого поля отдельно.
  3. Относительно быстрая процедура создания товаров. Это позволит осуществить "пакетное" создание товаров, при котором будет считываться информация о иерархии товаров и создаваться полный набор вариаций товара, что уже реализовано частично в Commerce Bulk Product Creation module на сегодняшний день.

Вот именно этого (иерархии вложенных товаров и собственного дисплея для товарных страниц) и не хватало платформе два года назад (тогда я сней и столкнулся). И как я ранее уже писал, в свое время, перед нами стоял выбор платформы под eCommerce проекты, и в итоге было принято решение разрабатывать свою платформу. Потому как на тот момент ни один из движков не отвечал основному требованию: "товары - отдельные самостоятельные сущности обладающие собственными дисплеями и, не менее важно - базовым набором свойств и методов." А с необходимостью использования вложенных (доечерних) товаров-опций мы столкнулись уже наверное на 3-м по счету внедрении.

Не воспримите за саморекламу, но в итоге, опробовав несколько вариантов иерархии товаров, в результате мы пришли к аналогичной модели, включая наследование полей дочерними товарами-опциями. Результат работы можно увидеть на сайте www.gssport.ru. Вот только мы не стали заморачиваться с тем, чтобы кастомно указывать какой из уровней у нас реально продаваемый товар - была принята модель, по которой реально продаваемым считается последний товар в ветке. При этом адреса (URLs) имеют все товары, просто дочерние товары редиректят пользователя на адрес основного родительского товара.

Цены

Цена будет объектом и позволит применять к себе налоги, скидки, комиссии:

<?php
$price = $product->getPrice();
$price->addTaxRate($frStandard);
$price->addDiscount($fiftyPercentOff);
$price->addFee($amexFee);
?>

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

Все это будет частью pricing library (налоги (taxes), скидки (discounts), комиссии (fees)).

Fabien Potencier and Jonathon Sacksick обсуждают взаимодействие между Symfony и Drupal.

Налоги

Под руководством David Kitchen, планируется переписать управление налогами для улучшения поддержки VAT и изменить ставки VAT (с 19.6% до 2014 включительно, на 20% после 2014).

Я правда не уверен что до конца сего 2014-го года Commerce 2.x вообще кто либо будет использовать в production варианте.

Это означает что Европейским пользователям платформы более не понадобятся commerce_vat и commerce_eu_vat модули.

Платежи

В Commerce 1.x API платежей реализован достаточно просто, чтобы обеспечить максимальную гибкость в его использовании, но такая его реализация дает и довольно обширное поле для ошибок и повторных разработок (велосипедов) при подключении новых платежных сервисов. На данный момент идут консультации относительно более структурированного API, который позволит упростить процедуру подключения сервисов. И пока нет четкого понимания куда этот API будет включен и чем вообще будет являться (будет реализован в commerce_payment, будет библиотекой на основе omnipay, будет частью самой omnipay и т.д.).

На данный момент разработчиками рассматривается интеграция Omnipay, как простой PHP библиотеки платежей. Что даст возможность использовать довольно обширную базу готовых решений, и позволит более тесно сотрудничать с PHP сообществом.

Работа кипит. Fabien Potencier (Sensio Labs), Fabien Gasser (Smile), Thomas Rabiax (Ekino, Sonata lead), Jonathon Sacksick, Fred Marand (OSInet), Chris Merritt, Dan Polant, Bojan Zivanovic, Ryan Szrama, and Josh Miller (taking picture)

To be continued...

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

В самом начале разработки будут созданы десятки новых классов и пропатчено множество файлов. Наблюдать за процессом кодинга можно в GitHub.

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

comments powered by Disqus