Categories
Programming

The End is in Sight

I’ve been coding lots and lots for many hours, but I can finally see the end for Waggonersboots.com version 2.0. I may have to come up with a new front-end to signify a change, but right now, it’s pretty similar in style. The backend is WAY more extensible though. With logging for errors and data changes, and a pretty good seperation of logic and presentation, I think it’s going to be a lot better. I hope to get some page editing in place for the admin, and better integration with Paypal and Google Checkout.

I can’t quite what I should do with data consistency. If we want to remove a product from the website, I would normally just delete it out of the database, but that creates some inconsistency, such as, if we wanted to look at selling history. I’ll probably continue to delete them, to remove the extra load on the database for indexing, etc, but I’m not sure what the rules are.

At my current job, I do a lot of reading. It’s hard to get used to, because the only jobs I’ve had before, I was expected to be, or at least look, busy. In some ways it’s nice, but it gets to be a little dull. I’ve been reading over MySQL, and even though I haven’t done much with it at work yet, I’ve implemented a lot of it into the WB‘s code. Here’s one that I came up with today:

SELECT name, COUNT(DISTINCT value) FROM variation
GROUP BY name ORDER BY 2

It’s pretty simple to most with SQL experience, but came as a revelation when trying to do different hacks in PHP. This query gets the types of variations (e.g. Size, Color) in order by the fewest distinctions. It’s useful for making a list such as (Colors are always top-level in this case):

  • Brown
    • 32
    • 34
    • 36
  • Black
    • 34
    • 38
    • 40

I then take a PHP function and sort it like this, for use in usort():

public function item_cmp(&$a, &$b) {
  $astr = $bstr = '';
  $vartns = Variation::get_variations();
  foreach($vartns as $v) {
    if(isset($a->variations[$v])) { // zero-pad with zeros to three digits
      $astr .= sprintf('%03s',$a->variations[$v]->weight);
    } else $astr .= '999'; // Make null values float to bottom
      if(isset($b->variations[$v])) {
        $bstr .= sprintf('%03s',$b->variations[$v]->weight);
      } else
        $bstr .= '999';
      }
  }
  return strcmp($astr, $bstr); // Compare the two as strings
  // (digits would probably work too, but strcmp was easiest)
}

Rather than hardcoding it, I thought it best to make it smart. I’ve implemented the site in PHP5, and I’m crossing my fingers that the shift from MySQL 5 to MySQL 4.1 won’t cause too many problems.

Categories
Programming

All About Waggonersboots.com

The last month of my life has been coding a whole new site for waggonersboots.com. I’ve moved everything over to PHP5, using PHP Classes, MySQLi, normalized tables, and a rough version of the Model-View-Controller system.

When dealing with footwear, you have to have shoe sizes, and other products have colors. I could have codeed different variations for products to have sizes, and others to have colors, and any other variations that would have come along, but to avoid the extra coding, I implemented them as one idea:

  • The product table contains generic information about a product, such as a brand, stock number, title, prices, category, and so forth.
  • The item table contains one instance of a product. The item is what actually gets sold and is tied to the shopping cart. Items have unique variations, which allows for a product to have multiple items.
  • The variations table has variations with a name and value. To keep the tables normalized, there is a item_variations table which join the two together, allowing an item to have multiple variations, and an item to have multiple variations (forcing a unique variation name, such as “Size” on an item).

The products have a product type, and I’ve been toying with the idea of letting variations be type specific, so that products that are footwear, can have the Size 8.5 D, 9 D, 10 D, and products that are apparel can have the size 32×32, 32×34, Medium, Large; this is kind of contaminated too, as Jeans, Shirts, and Hats have their own systems of sizing.

This method causes a few problems when trying to turn the results from the database into a web interface, but I got it to work. I may post some code later.