Initial example for configurable product

[joshporter]

This is the inital example of a configurable product fixture. The format I have gone with it is:

  configurable_attributes:
      <sku>:
        <attribute_code>: <label>

The default configurable product YAML file looks like this:

catalog/product/configurable:
  default_attributes:
    sku: test-conf
    attribute_set_id: 9
    name: product name
    weight: 2
    price: 100
    description: Product description
    short_description: Product short description
    tax_class_id: 4
    type_id: configurable
    visibility: 4
    status: 1
    stock_data: { use_config_manage_stock: 0, manage_stock: 1, is_in_stock: 1 }
    website_ids: [1]
  simple_product_attributes:
    website_ids: [1]
    attribute_set_id: 9
    name: product name
    tax_class_id: 4
    status: 1
    weight: 2
    price: 100
    description: Product description
    short_description: Product short description
    type_id: simple
    visibility: 1
    stock_data: { use_config_manage_stock: 0, manage_stock: 1, min_sale_qty: 1, max_sale_qty: 2, is_in_stock: 1, qty: 999 }
  configurable_attributes:
       test-conf-1:
        color: Green
      test-conf-2:
        color: Blue
      test-conf-3:
        color: Black

A main 'gotcha' I came across was making sure the configurable attribute you are defining in your fixture, is added to the attribute set you are using.

The example default YAML file uses 'color' which is defined in the 'default' attribute set. The attribute set id can be noted down from the URL in the admin, when visiting the attribute set.

Need to work on clearing up associated simple products

[dwickstrom]

Hello @joshporter!

I was thinking about this problem a little bit, and what do you think about this: wouldn't it be nice if the "regular" product builder could be responsible for detecting the type_id and then if the type is "complex" then report back to the FixtureManager that then knows that the model hasDependencies and then, first builds the required dependency (the simple product in this case), and then when that's done the builder knows how to associate this (simple) product with the (complex) product it's about to build? In bullet form:

1. A product fixture includes the attribute "type_id" and it's not "simple"
2. When the builder is called from the FixtureManager, then its routine involves checking for type_id
3. If the builder detects a "complex" product type, then it shares this knowledge with the FixtureManager
4. The FixtureManager now knows that there is dependency to be built (just not one that was specified in the fixture file)
5. The FixtureManager doesn't care what that dependency is, but calls the builder again to do its dependency work like normal

This way we could do other complex types, like grouped and bundled products too. Maybe...?

The FixtureManager::loadFixture() method could include a call something like this:

if ($this->mergeDependencies()->hasDependencies()) {
    foreach ($this->getDependencies() as $dependency) {
        $withDependency = 'with' . $this->getDependencyModel($dependency);
        $builder->$withDependency($this->loadFixture($dependency));        
    }
}

...and then the mergeDependencies() method could do something like this

public function mergeDependencies()
{
    $this->dependencies = array_merge($this->attributesProvider->getFixtureDependencies(), $this->getBuilder()->getDependencies());

    return $this;
}

...and so forth. In essence, the Builder has the knowledge about these types of dependencies, and shares this with the FixtureManager who then knows how to handle those.

I think it's not super clean, either, but maybe a little more dry. A complex product does have a dependency on another product, so in that sense it makes sense to use the current dependency builder mechanism. On the other hand, the way you implemented it, the complexity is encapsulated in the Configurable builder, which is nice too.

What do you think?

[dwickstrom]

Another way to attack this problem is to do something like this, which is also generic and could work for any dependency:

$simpleProduct = $this->fixtureManager->loadFixture('catalog/product')->get();
$configurableProduct = $this->fixtureManager->loadFixture('catalog/product', [
    'type_id' => Mage_Catalog_Model_Product_Type::TYPE_CONFIGURABLE
])->with($simpleProduct)->get();

...and with another type of model

$customer = $this->fixtureManager->loadFixture('customer/customer')->get();
$address = $this->fixtureManager->loadFixture('customer/address')->with($customer)->get();

I think I might like this idea better...