Made to Order Module

·       Example Scenario:


 In Magento, everything you wish to sell must be defined as a Simple Product having i

ts own SKU and price. But there are times when a merchant wishes to sell items that  

do not have a unique identifying code, like a SKU. The reason that some products  

might not have an identifying SKU depend largely on the type of item being sold and

the organization of themerchant’s business.  

These types of situations are especially common for manufacturers who take special 

orders for items that they may only make one time. An example that most anybody

can relate to would be purchasing produce or meat at a supermarket. Apples 

are sold by the pound, purchasing one pound of apples costsmore than purchasing a 

half pound of apples, or any fractional weight in between. But, each possible weight 

of apples does not have its own predetermined and unique SKU number. The type 

of apple probably has a unique PLU, or Price Look-Up code, but the final item of the 

transaction is an item and a specific quantity; weight in this example.  

This fabricated receipt shows an example of how individual line-items of a receipt 

can be composed of a dimension or quantity plus a unique identifying number, such 

as a SKU or PLU.

·       Plan of Attack:


In order to implement user input as part of our order, we need to understand how  

the order process works. When a user adds a product to their cart, a quote item is  

created from the product and that quote item is what is added to the user’s cart, not 

the product itself. When the user completes the order, the quote, and all of its items

are transformed into an order. Just like adding attributes to a product, we can add  

new attributes to quote items and order items. Although there is no user interface for 

this task, the concept is the same.

• Create a new attribute for length products

• Create a new attribute for quote items

• Create a new attribute for order items
• Create a new product template to get length input
• Add event listeners to the order process to alter the quote and order items
• Alter the checkout screen to show the length attribute

·       The Length Attribute:

Creating this new attribute does not affect the code of our new module. We will simply 

create a new product attribute using the admin interface. Create a new product 

attribute called mto_length. This attribute will not be visible on the front end, and  

it does not require any special validation. The input type should be Yes/No for the 

store owner. All we want to do with this attribute is to signal the various blocks and 

templates to show new inputs to the user 

When editing the product itself, we will only have a Yes/No choice for our gutter 

products

·       Overriding the Block:

We want to develop our new length input field in the most modular way possible.

To accomplish this we will override the default Product View block and conditionally 

add our new template piece, which we will create as a new core/template type block.

class Company_Mto_Block_Product_View 

extends Mage_Catalog_Block_Product_View

{

protected function _prepareLayout()

{

$lengthBlock = $this->getLayout()->addBlock(’core/template’, ’

length_product’)

->setTemplate(’mto/length_product.phtml’);

$this->setChild(’length_product’,$lengthBlock);

return parent::_prepareLayout();

}

}

This code creates a new template block of the type core/template. This type is the 

most basic type of block you can create. Its sole purpose is to include a template file. 

It provides no custom display logic like other, more specific, block classes.

To implement our new block we need to modify the layout/catalog.xml file. You 

can make this change by creating a new layout file and referencing the block in 

question, see the Custom Modules chapter for more information on safely overriding 

blocks. Change the type attribute of the block under content in the catalog_ 

product_view tag.

<catalog_product_view>
...
<reference name="content">
<!--
<block type="catalog/product_view" name="product.info"
template="catalog/product/view.phtml">
-->
<block type="mto/product_view" name="product.info"
template="catalog/product/view.phtml">
...
</reference>
...
</catalog_product_view>




Now, we have our new product view block, and it creates a new child block, 

but this new block still will not show up on our product view page. We 

must specifically instruct the original product view template to output this new

length_product block at a specific spot. We output child blocks within a template 

with the method getChildHtml. The original product view template is in 

template/catalog/product/view.phtml. The best place to add our new block output 

is directly under the product_type_data block. The product_type_data block shows 

specific information for each type of product: Simple, Configurable, and Bundle.

<?php echo $this->getChildHtml(’product_type_data’) ?>

//new block for products with length.

<?php echo $this->getChildHtml(’length_product’) ?>


The final piece of the template puzzle is the .phtml file itself. We have already referenced 

it in the code as mto/length_product.phtml. This file is very simple, it simply 

displays an input field to accept the user’s input. This file can be more advanced. By 

adding a specific block for length-type products we could inspect more properties

about the current product, show a range of acceptable sizes, or even dynamically 

update the price with AJAX-style coding. For now, our template file will remain barebones.

·       Modify the Cart Page:

The cart page utilizes a method from the checkout/cart block to show an extra description 

for certain products. Only configurable products use this extra description 

method. The block method in question is called  tItem Description and takes 

a quote item as a parameter. This method acts as a facade for a helper event with 

a longer name; it simply passes the quote item parameter to the checkout module’s 

data helper. We can take advantage of this fact by overriding the checkout data 

helper and inserting some logic to display our mto length attribute if necessary.  

Override the checkout module’s data helper by inserting the correct XML into  

our MTO module’s config.xml. Then create a Helper/Data.php file which extends 

the original class Mage_Checkout_Helper_Data. The method name in question is 

getQuoteItemProductDescription. Now you can see why the cart block provides a

façade for this method name. In the body of our overridden method we will defer to  

the parent method first, then add our custom logic afterwards.

class Company_Mto_Helper_Data
extends Mage_Checkout_Helper_Data
{
public function getQuoteItemProductDescription($item)
{
$desc = parent::getQuoteItemProductDescription($item);
if ($item->getMtoLength()) {
if ($desc !== ’’) {
$desc .= ’<br/>’;
}
$desc .= ’Length: ’.$item->getMtoLength().’\’’;
}
return $desc;
}
}