ooCommerce – A Deeper Look, More Decisions

We’ve broken down our system down into some general parts already. Now it’s time to make some decisions on more specific pieces of ooCommerce and break the system down into some main objects.

What’s in our Model

Well, first off, we know we need a database to store all of our store’s data. We’ll put off the database schema for now. But what we do need to decide is what database to use. And if we want to support several databases (which we do), what should we do to abstract the databases so that we use the same API no matter which database we use.

There are a few object-oriented options out there. My favorite is Creole, a PHP 5 database abstraction layer which has a nice interface. There is also PEAR’s DB which I’ve actually never used and have heard good things about. The good things about these are that they’re already built and they are actively developed which means others are fixing the bugs and adding features so we don’t have to. However, they are large, and the API of Creole is more of what Java programmers are use to and not what PHP developers are use to. We could also create our own object oriented abstraction layer. It would be smaller and use the API we want. Much more simple code. What do you think we should do?

The rest of the model would include the following list of objects, plus maybe a few we havn’t thought of yet:

  • Customer
  • Address Book
  • Address
  • Payment (stored)
  • CustomerGroup
  • Order
  • OrderItem
  • PaymentMethod
  • DeliveryMethod
  • Product
  • ProductReview
  • ProductSpecial
  • Catalog
  • Category
  • ShoppingCart
  • Translator
  • Pages
  • Content
  • Administrator
  • Report

There of course will need to be an object type for each method of payment and other additions like that. But I think we’ve got a pretty good layout here. We may think of other things later, especially when we want to add features.

How Will We Control Our Model

The controller part of our system could be pretty simple, or pretty elaborate. It all depends on what we value the most. If we like simple the best, we can just have a bunch of PHP pages that our use will go to, they will run the code they need to run, using the model objects, and then they will pull in a template and output the results. The URLs for these will be the name of the files, plus any parameters passed in the URL. These will be pretty procedural, although we could make them into classes to keep it object oriented. Another option is to push for search engine optimization by building our system with URLs that represent the page being displayed. If we go simple, we will have a “product.php?id=10” or “product.php?name=james_bond_movie” displaying our products. If we choose the more complex controller we would have “products/james_bond_movie” be our URL, which ranks it higher on the search engines. To do this we would need to use mod_rewrite with Apache and set up our scripts to handle these URLs. But it is very do-able. Do we want full-featured, or do we want simplicity? The value of ooCommerce will be higher with better features to it’s users.

Gotta See The View

There are a million and one template systems out there (I wrote the 1,000,001 template system) and most very similar. Smarty is the most popular it seems. And most are similar to Smarty except less features or slower. I happen to be partial to my templating system, Arras, which is different from most. It is also fast, and small, and fun to use, and easy for designers to do design on. So, I would like to use Arras.

So, what are your thoughts? Please give feedback on the following design decisions. We would love to get input.

  • What database abstraction layer should we use?
  • Any additional classes I forgot in the model?
  • Go for a simpler controller, or nicer URLs?
  • Use Arras for the template system or something else?

One Response to “ooCommerce – A Deeper Look, More Decisions”

  1. Nathan Garza Says:

    I’m personally all about simplicity. The simpler we do things, the easier it will be to maintain. For that reason, my vote is for using an already existing db abstraction layer.
    Having said that, I do think that we should go ahead and use mod_rewrite to make fancier url’s for seo.
    As far as templating, keep it simple, I say. Arras is fine with me, but most of the others I think are a bit of overkill. Just my $.02