This article is the first of a four part series. It was born out of the DrupalCon San Francisco session by the same name and has been fleshed out through internal interviews with Ryan at Commerce Guys. We use the material to help the whole team understand how Drupal Commerce will improve the way we build sites on Drupal 7, and we hope it whets your appetite, too!
When we first developed Ubercart, we had an idea of what we wanted it to be based on our past experience (mostly with osCommerce) and our perceived future needs (specifically modularity). We had freedom to craft a system that met our business needs within the Drupal framework, but we had a noticeably limited pool of experience and a "best guess" vision of the future. It wasn't until developers and companies like Commerce Guys started to deploy Ubercart to meet a wide variety of business needs that we learned where our vision fell short, especially as Ubercart was pushed to perform for larger and larger sites requiring greater interoperability with external services.
Some specific experience with Ubercart that is shaping Drupal Commerce development includes:
1. Enforcing from the beginning a strict set of development standards based on Drupal's own coding / documentation standards with some extra specifications to standardize our API function naming, form definitions and handlers, module directory and file structures, and test coverage.
While this won't seem like a big deal to your average user or non-developer decision maker, it actually represents one of the most significant changes from my development on Ubercart. We weren't entirely ignorant of the standards and best practices with Ubercart, but we didn't enforce the standards strictly and definitely failed to comment a lot of the code. This makes it harder for third party developers to support the software and write modules to interact with the core APIs. It also makes it harder to maintain the code moving forward. The lack of test coverage in Ubercart made it difficult to introduce API patches of any size, as we never knew what might be inadvertently broken.
I predict the strict standards of Drupal Commerce will result in cleaner code that has less bugs. The bugs that do appear will be easier to fix, and when they're fixed it will be easier to avoid introducing new bugs as a result. This all bodes well for users who have strict standards for the reliability of the software they deploy. I also predict that more developers will find it easier to work with Drupal Commerce than Ubercart, as they'll find the files easier to navigate and the code easier to read. The abundance of comments in the code (currently nearing 30%) will make it easier for developers to write third party modules that interact with the Commerce APIs and should foster a greater pool of contributors to the core modules themselves.
2. Strict separation of the core APIs from the default user interface.
Ubercart's default administrative interfaces were designed with small businesses in mind, and trying to deploy it for larger clients resulted in Commerce Guys having to build our own administrative interfaces from scratch. Unfortunately, because the Ubercart APIs are inseparable from the UI, there was no way to turn off or build on top of the existing interfaces.
There's no way to predict who will be using the software, so we are taking the following approach to UI design for Drupal Commerce: separate API from UI and provide default user interfaces using simple forms, core interfaces, and Views that may be easily altered and extended. Users that don't need the UI at all can simply not enable the pertinent modules. We're setting the tone from the beginning that our interfaces are meant to serve as customizable starting points.
Furthermore, we're using the Views module to provide almost every list in the default UI, including product and order lists, customer order histories, shopping cart contents, and more. Because most Drupal developers will be familiar with Views, they won't have to learn anything special to alter the default user interfaces in Drupal Commerce.
Part two covers keeping the core slim and the project's vision for taking advantage of installation profiles and Features. To follow along with development, start by visiting the project page at http://drupal.org/project/commerce.
To experience our internal training firsthand, join us in our Drupal Powered E-commerce training at DrupalCon Copenhagen.
Add new comment