跳转到主要内容
dustise 提交于 11 June 2014

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用户进行开发升级和配置迁移的目的。

时间轴

Timeline

我们最初的目标是在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代码中直接进行价格运算。

标签
Drupal 版本