Drupal Commerce 2.0路线图

简介

因为Drupal核心的更新换代以及新的核心模块的引入，Drupal Commerce 2.x开始进行开发，得益于Drupal核心的Entity API以及Entity Reference模块，让复杂的Product Reference、Line Item以及Customer模块被成功精简，使得新版本的Drupal Commerce的代码规模将大大减小。

这一路线图列出了我们为了对应Drupal 8的升级，而预备在架构层面对Commerce核心模块的改造。同时我们也以创建了大量任务，以达成让Drupal Commerce 1.x用户进行开发升级和配置迁移的目的。

时间轴

我们最初的目标是在Drupal 8发布的同时发布一个Beta版。然而，我们不想重复一遍在Drupal 7/ Entity API/Views不稳定的那段时间里，我们所经历的动荡生活，所以我们推迟了Commerce 2.x的开发，直到Drupal核心稳定为止。

Commerce 2.x的开发的会在Drupal 8的 alpha或beta版本发布之时真正启动。在这期间，我们的主要注意力会集中在确认建立在新的API之上的Drupal 8是否足够优秀，承诺过的新特性是否完成并通过测试。

如果Drupal 8会在布拉格DrupalCon发布，Drupal Commerce 2.x还是有一定机会发布一个Beta版本的。随着时间的迁移，我们会不断修正我们的预测。

开发重点

在路线图任务列表中的很多条目都以相关的子系统为标准进行分组，还有另外一些影响范围比较抽象的任务，这些主要是针对一些针对于普遍原则或开发重点的任务，将会对整个产品产生较大影响。这些重点列表如下，接下来会提供这些条目相关信息，帮助读者来了解为什么会有这些全局任务。

• 通道还是容器？
• 为多数场景服务
• 清晰的设置和行为
• 健壮的内部API

当然，任务列表不会覆盖Commerce的所有方面。参与者可以自由的提出不在本列表的但是符合这些重点的提议，我们会就这些提议在社区中进行讨论，以此决定是否在路线图中采纳这些建议。未来所有的功能请求的相关讨论都会保存在这一问题队列之中。

通道还是容器？

在向Drupal 8迈进之前，我们需要进行一下回顾，并且发现了一个核心原则的问题：一个电商网站应该是一个通道，而并非容器。他应该能够轻易的在Drupal Commerce站点和各种Web Service之间进行数据交流。相对一个单独的网站来说，这一形式能让电商能力得到更大扩展。

• Drupal Commerce 1.0是Drupal 7的一个初始的电商实现，建立在Entity API，Field API，Views以及Rules之上，完成了一个真正有弹性的电商框架。
• Commerce Kickstart 2.0致力于用Commerce来建设易于启动和管理，并具有丰富功能的电商网站。
• Drupal Commerce 2.0引入了新的组成部分——同第三方Web Service集成的能力，这将有力的支撑电商网站的建设和盈利。

为了满足Commerce Guyes以及客户的移动应用需要，开发了Commerce Services，而Drupal 8核心围绕着超媒体原则的REST功能大大增强，在此情况下我们进行了重构。

为多数场景服务

有不少的仓促产生的“强力功能”，还有一些明显弱于第三方的解决方案。在Drupal Commerce 2.0中将会定位这些问题，更好的为大多数的用例服务。

• 刷新购物车：每次订单载入的时候，我们都会刷新购物车，以确保价格的准确，但是这在大多数站点来说都是不必要的，我们准备提供一个配置选项来决定这个行为，可能会使用一个“on load”规则来代替现有方案。

• 产品定价rules：我们强迫所有的价格运算都使用Rules，以此来解决一个罕见的大功能，价格的预先计算。如果这一需求关闭的话，模块可以直接使用钩子进入产品定价系统，我们将会提供一个更强壮的不依赖于Rules的API来保证价格组件的正确性。

• 购物车版本：却生情况下，我们为购物车的每次操作创建一个版本，以此来跟踪购物历史和放弃购物的行为，但是第三方的一些服务比这一方式更好的完成了分析工作。例如我们的合作伙伴Jirafe。

• Checkout form的验证和提交：尽管在页面出错的情况下，为了获得更多数据，我们会验证和提交每一个checkout pane。这使得Checkout pane之间在没有插入代码的情况下无法进行依赖。我们会把这部分转换为一个Checkout页面的设置。

需要注意的是，这些重点不意味着我们会删掉任何对普通用户来说不太了解/习惯的特性。例如，很多人会对客户资料的重复感觉吃惊，但是这对电商来说是个有用的特性，可以以此来保留完整的订单历史。

清晰的设置和行为

我们努力杜绝Drupal Commerce 1.x中出现的“魔术”设置：一个或多个设置产生了一个隐性的二级功能。例如Commerce 1.x原本需要对Fields进行一系列组合设置来实现产品的属性Field，我们准备创建一个明确的设置Form放在Field编辑Form中来完成这一功能。

健壮的内部API

Commerce 1.x基于Drupal 7核心以及API，尤其是Entity和Field。然而，我们自己内部的工作例如创建订单，计算价格以及处理支付并没有形成很好的体系。这一工作重点让我们回到最初，我们应该以REST的思路来开发我们的系统。

在Commerce 2.x中，我们会为Form、Rules Action等创建健壮的内部API，并且避免将这些功能嵌入到系统相关的回调之中。例如在关闭价格提前计算，不使用Rules的情况下，我们将把价格运算和价格组件管理进行简化，将在Module代码中直接进行价格运算。