SpinOneSolutions » PHP

Magento Controller Override

Will Wright — Fri, 19 Mar 2010 16:00:11 +0000

The Problem:

You want to override a Controller’s action with a custom action.

Magento Enterprise v1.6.0.0

The Solution:

I ran into some issues trying to override a controller’s action yesterday. I think it mainly stems from a version change, but at any rate here’s the “new” way to do it. This comes from a helpful post on the Magento forums.

In this example my custom modules’s namespace is “Spinonesolutions” and I’m going to override the createPostAction in Mage_Customer_AccountController.

Start by creating a bare bones custom module; if you don’t know how to do this check out Magento – Part I : Custom Module.

I’ve only got two files in my custom module; controllers/AccountController.php and etc/config.xml.

config.xml:




  
    0.0.1
  


  
    
    
      
        
          
          Spinonesolutions_Customer

AccountController.php:

That’s it! You should now have a working override.

Magento Partial Refund Amount Correction for Authorize.net

Will Wright — Wed, 20 Jan 2010 22:04:48 +0000

The Problem:

You’ve enabled partial refunds in the Authorizenet Model, but it’s not refunding the proper amounts. This is due to, in my view, a bug in the core which I’ll show you how to patch!

The Solution:

What you need to do is overload the refund method in the Authorizenet model.

Create a new model that extends the original Authorizenet model. You’ll need to follow the general instructions for how to create a custom module if you don’t already know how to do so.

class Spinonesolutions_General_Model_Paygate_Authorizenet extends Mage_Paygate_Model_Authorizenet {
//Override Mage_Paygate_Model_Authorizenet

protected $_canRefund = true;

public function refund(Varien_Object $payment, $amount) {
  $error = false;
  if ($payment->getRefundTransactionId() && $amount>0) {
    $payment->setAnetTransType(self::REQUEST_TYPE_CREDIT);
    $request = $this->_buildRequest($payment, $amount);
    $request->setXTransId($payment->getRefundTransactionId());
    $result = $this->_postRequest($request);
    if ($result->getResponseCode()==self::RESPONSE_CODE_APPROVED) {
      $payment->setStatus(self::STATUS_SUCCESS);
    } else {
      $error = $result->getResponseReasonText();
    }
  } else {
    $error = Mage::helper('paygate')->__('Error in refunding the payment');
  }

  if ($error !== false) {
    Mage::throwException($error);
  }

  return $this;
}
}

Now all we need to do is let Magento know that we’ve got a custom model. In config.xml add



  
    
      0.0.1
    
  
  
    
      ...
      
        
          Imagistic_General_Model_Paygate_Authorizenet
        
      
      ...

That should do it! Questions and comments welcome.

Custom Magento Grid with Ambiguous Column on Filter

Will Wright — Tue, 05 Jan 2010 17:14:58 +0000

The Problem

You’ve built a custom grid and the source collection has an ambiguous column in the where clause when applying a filter.

The Solution

I recently ran into this problem while I was building a custom grid. The situation should be familiar to many of you. I have a custom table storing addresses; for the region and country I store a region_id and country_id, respectively. For display of the grid however I want to do a lookup to show the user the friendly names for both region and country. To accomplish that I do an inner join on the original collection which yields the full dataset.

However, this also introduces a douplicate column into the collection which was causeing an ambigous column error in my SQL statement whenever I applied a filter (a WHERE clause). Lets take a look at an example.

My tables:

retailer

id
street
city
postcode
country_id
region_id

directory_country_region

region_id
country_id
code
default_name

Now lets take a look at my _prepareCollection method.

protected function _prepareCollection() {
  $collection = Mage::getResourceModel('spinonesolutions_storelocator/retailer_collection');
  $collection->getSelect()
    ->join(array('dcr' => 'directory_country_region'),'dcr.region_id = main_table.region_id')
    ->reset(Zend_Db_Select::COLUMNS)
    ->columns(array('id','name','street','city','country_id'))
    ->columns(array('default_name'),'dcr');
  $this->setCollection($collection);
  return parent::_prepareCollection();
}

This will result in a collection containing all the data that I need for a friendly presentation. However, if I want to filter by country_id (which I do!) then I’m going to get an ambiguous column error in my SQL if I simply add “WHERE country_id = ?”. That’s because country_id is in both tables.

The solution is the “filter_index” property. Here’s a snippet from _prepareColumns which generates the country column and uses filter_index.

$this->addColumn('country_id', array(
  'header' => Mage::helper('spinonesolutions_storelocator')->__('Country'),
  'width' => '100px',
  'index' => 'country_id',
  'filter_index' => 'main_table.country_id',
  'type' => 'country', ));

Now when the SQL statement is generated the ambiguous column error will be fixed since I’ve provided enough specificity. Simple!

Questions and comments welcome!

Magento – Enable Paygate Refunds

Will Wright — Wed, 28 Oct 2009 21:43:26 +0000

The Problem:

You want to issue a refund, electronically, through your payment gateway from Magento.

The Solution:

By default, the community edition of Magento has refunds disabled in the Paygate Models. In order to enable them you need to create a custom Model and overwrite a protected variable. Refer to Part IV: Extending Models for more details on extending a Model.

First, lets take a look at the native Model so that you can understand what’s standing in the way. I’m going to use the Authorize.net gateway as my example.

The top portion of Mage_Paygate_Model_Authorizenet (/Mage/Paygate/Model/Authorizenet.php)

class Mage_Paygate_Model_Authorizenet extends Mage_Payment_Model_Method_Cc
{
    const CGI_URL = 'https://secure.authorize.net/gateway/transact.dll';

    const REQUEST_METHOD_CC     = 'CC';
    const REQUEST_METHOD_ECHECK = 'ECHECK';

    const REQUEST_TYPE_AUTH_CAPTURE = 'AUTH_CAPTURE';
    const REQUEST_TYPE_AUTH_ONLY    = 'AUTH_ONLY';
    const REQUEST_TYPE_CAPTURE_ONLY = 'CAPTURE_ONLY';
    const REQUEST_TYPE_CREDIT       = 'CREDIT';
    const REQUEST_TYPE_VOID         = 'VOID';
    const REQUEST_TYPE_PRIOR_AUTH_CAPTURE = 'PRIOR_AUTH_CAPTURE';

    const ECHECK_ACCT_TYPE_CHECKING = 'CHECKING';
    const ECHECK_ACCT_TYPE_BUSINESS = 'BUSINESSCHECKING';
    const ECHECK_ACCT_TYPE_SAVINGS  = 'SAVINGS';

    const ECHECK_TRANS_TYPE_CCD = 'CCD';
    const ECHECK_TRANS_TYPE_PPD = 'PPD';
    const ECHECK_TRANS_TYPE_TEL = 'TEL';
    const ECHECK_TRANS_TYPE_WEB = 'WEB';

    const RESPONSE_DELIM_CHAR = ',';

    const RESPONSE_CODE_APPROVED = 1;
    const RESPONSE_CODE_DECLINED = 2;
    const RESPONSE_CODE_ERROR    = 3;
    const RESPONSE_CODE_HELD     = 4;

    protected $_code  = 'authorizenet';

    /**
     * Availability options
     */
    protected $_isGateway               = true;
    protected $_canAuthorize            = true;
    protected $_canCapture              = true;
    protected $_canCapturePartial       = false;
    protected $_canRefund               = false;
    protected $_canVoid                 = true;
    protected $_canUseInternal          = true;
    protected $_canUseCheckout          = true;
    protected $_canUseForMultishipping  = true;
    protected $_canSaveCc = false;

    protected $_allowCurrencyCode = array('USD');

The variable that we’re interested in is _canRefund. The game plan is to create a custom Model that overrides Mage_Paygate_Model_Authorizenet and in that Model, override _canRefund. If you’re thinking, why not just change false to true right here, right now! Well my friend, you certainly could, but you’d certainly break your upgrade path too, check out Part IV: Extending Models and Part I: Custom Module.

I’m going to create the class: Spinonesolutions_Paygate_Model_Authorizenet (/local/Spineonesolutions/Paygate/Model/Authorizenet.php) and extend Mage_Paygate_Model_Authorizenet. Now I just override _canRefund and we’re halfway there.

If you read Part IV: Extending Models you’ll know that there’s one last step, and that is to modify config.xml so that our custom Model overrides the native Model.

/Spinonesolutions/Paygate/etc/config.xml


  
  ...
    
      
        Spinonesolutions_Paygate_Model_Authorizenet
      
    
  ...

That should do it! If you’ve got everything else setup correctly this should enable the Model to post refunds electronically to your gateway. Of course, if you want to enable more than one gateway, or perhaps a gateway that’s not Authorize.net you can do that by just following the same steps above with the Model for the gateway of your choice.

As always, questions and comments are welcome!

Update: From Commenter Cindy

Afer doing the above (and not forgetting to fill in app/etc/modules/MyNameSpace_All.xml to activate the new module), I still wasn’t getting authorize.net to really refund the cc.

I found that I needed to add the CC to the request, and then add the actual amount to be refunded. Now issuing a credit memo on the invoice will cause authorize.net to issue a refund to the CC.

Also, it appears that the ‘refund’ button only shows up if you click credit memo from an invoice – it doesn’t show up if you click credit memo on an order (only ‘refund offline’ shows up then).

Anyway, this is the code to make this work for me:

//
// Override Mage_Paygate_Model_Authorizenet
//    enable online refunds via credit memos
//    enable partial refunds
//
class Sbr_Paygate_Model_Authorizenet extends Mage_Paygate_Model_Authorizenet {
  protected $_canCapturePartial = true;
  protected $_canRefund = true;

  //
  // override _buildRequest to fill in the CC number as it is required yet not set peviously
  //
  protected function _buildRequest (Varien_Object $payment) {
    if (($payment->getAnetTransMethod() == self::REQUEST_METHOD_CC) &&($payment->getCcLast4()))
      $payment->setCcNumber($payment->getCcLast4());
   
      return parent::_buildRequest($payment);
  }

  // Override refund in order to fill out the amount
  //
  public function refund(Varien_Object $payment, $amount) {
    $error = false;
    if ($payment->getRefundTransactionId() && $amount>0) {
      $payment->setAnetTransType(self::REQUEST_TYPE_CREDIT);
      $request = $this->_buildRequest($payment);

      // set the amount (beginning of changes)
      $order = $payment->getOrder();
      $request->setXAmount($amount,2);
      $request->setXCurrencyCode($order->getBaseCurrencyCode());
      // (end of changes)

      $request->setXTransId($payment->getRefundTransactionId());
      $result = $this->_postRequest($request);

      if ($result->getResponseCode() == self::RESPONSE_CODE_APPROVED) {
        $payment->setStatus(self::STATUS_SUCCESS);
      } else {
        $error = $result->getResponseReasonText();
      }
    } else {
      $error = Mage::helper(’paygate’)->__(’Error in refunding the payment’);
    }

    if ($error !== false) {
      Mage::throwException($error);
    }

    return $this;
}

Magento – Part IV : Extending Models

Will Wright — Thu, 22 Oct 2009 15:09:55 +0000

The Problem:

You want to expand upon or change some functionality within Magento.

The Solution:

Extend a Model! I’m going to use a real world example here because I believe that examples are the best tools for teaching.

I was faced with a request for additional functionality in regards to the Authorize.net payment method. Basically, the customer wanted an email to be sent to an administrator if the gateway experienced an error while trying to processes a payment; a very reasonable request.

To accomplish this I extended Mage_Paygate_Model_Authorizenet, the model responsible for Authorize.net. There are two very important reasons why I went about it the way I did.

First, as I mentioned earlier, all custom code should go in the /local/ directory. If I had made my changes directly to Mage_Paygate_Model_Authorizenet (/core/Mage/Paygate/Model/Authorizenet) then the modifications would be in serious danger if the core were ever updated, essentially breaking the upgrade path.

Secondly, by extending the core class I can make reference to anything contained in the parent class. This is good OOP architecture; I’m just adorning the parent class with additional functionality, leveraging all the work that has come before and maintaining good compartmentalization.

There are two basic steps to extending a core class. Firstly, you need to create your new (custom) class in a custom Module living in /local/. I’ll continue expanding upon my previous examples and make a new Model within Spinonesolutions/Helloworld. I’m going to put the new Model in its own folder, mirroring the structure of the core.

Parent Class Path:
/Mage/Paygate/Model/Authorizenet.php

Custom Class Path:
/Spinonesolutions/Helloworld/Model/Paygate/Authorizenet.php

Naming conventions dictate that my custom Class’s name be:
Spinonesolutions_Helloworld_Model_Paygate_Authorizenet

Let’s jump right into the source and dissect what’s going on.

_order = $payment->getOrder();
    try {
      parent::capture($payment,$amount);
    } catch (Exception $error) {
      $this->_sendEmail($error);
      throw $error;
    }           
    return $this;
  }
}

The declaration is import to note because this is where we do the actual extending. Although it’s not necessary for this example I’ve included a call to the constructor, and placed a call to the parent constructor within it. This way, both the custom and parent model are instantiated correctly.

OK, onto the meat, the capture() function. To fully understand this we need to understand what we’re trying to extend. Looking at Mage_Paygate_Model_Authorizenet (/Mage/Paygate/Model/Authorizenet.php) will yield the answer.

As you can see Mage_Paygate_Model_Authorizenet contains a capture method with the exact same signature: public function capture(Varien_Object $payment, $amount). What I’m doing is overriding this method with my method. I add my additional functionality and then call the parent method at the appropriate time to drop the system back into its default workflow.

Notice that all I’m doing is wrapping the parent method call in a try catch block so that if an Exception is thrown I can catch it and send an email. I’ve successfully extended the core functionality without touching a line of the core code!

I’ve left out one small, but hugely important bit of information. In order to get this to work we have to let Magento know that there’s a custom Model which overrides this particular Model. To accomplish this we turn to the config.xml.

"1.0" encoding="UTF-8" ?>

      
            
                  0.1.0
            
      
    
        
                  
                standard 
                
                    Spinonesolutions_Helloworld  
                    spinonesolutions 
                
            
        
    
      
            
                   
                        Spinonesolutions_Helloworld_Model      
                  
              
                  
                        Spinonesolutions_Helloworld_Model_Paygate_Authorizenet

Notice line:24 and the paygate element. This is the element that is telling Magento to now look in our custom class for the Model, and not the core.

That’s all there is to it! You can now extend Magento’s core functionality to your heart’s content.

I bet you astute readers out there noticed that ALL of the models thus far have extended a core class. My first Model Spinonesolutions_Helloworld_Model_Helloworld extends Varien_Object. Even the controllers extend Mage_Core_Controller_Front_Action.

Oh Snap!

Download the source – Helloworld_v3

Magento – Part III : Controllers

Will Wright — Wed, 07 Oct 2009 16:38:05 +0000

The Problem:

I need to write Part III of the Magento series.

The Solutions:

This article… TADA!

First, let’s talk about the controller. The default controller for a module is always named IndexController.php. If you haven’t requested a specific controller (in the URL), than the system is going to look for IndexController.php and load it. Similarly, the default Magento action is indexAction().

Applying this logic to my custom Module; if I simply type {base}/spinonesolutions/ into the address bar, Magento is going to load up Spinonesolutions_Helloworld_IndexController and invoke indexAction(). Remember that “spinonesolutions” is the frontname that I defined for this module in the config.xml (See Part II : Models for source).

helloworld("helloworld");
      }
}

"1.0" encoding="UTF-8" ?>

      
            
                  0.1.0
            
      
    
        
                  
                standard 
                
                    Spinonesolutions_Helloworld  
                    spinonesolutions 
                
            
        
    
      
            
                   
                        Spinonesolutions_Helloworld_Model

Let’s start adding pieces onto our URL and explore what happens in Magento. Adding one piece yields {base}/spinonesolutions/foo/. This is asking Magento to invoke the indexAction() of the FooController, more specifically Spinonesolutions_Helloworld_FooController.

That Class doesn’t exist in our current code base so we need to create it. Following Magento’s naming conventions and our choices in config.xml the filename and path for Spinonesolutions_Helloworld_FooController must be: /Spinonesolutions/Helloworld/controllers/FooController.php.

Now we’ll take it to the next level and add another piece to the URL yielding {base}/spinonesolutions/foo/bar/. This is asking Magento to invoke the barAction() of the FooController (Spinonesolutions_Helloworld_FooController). Let’s add that action to our growing controller.

That covers the basics for controllers. Setup your route in the config.xml then follow the proper naming conventions when creating your classes and you should be all set.

Download the source – Helloworld_v2

Magento – Part II : Models

Will Wright — Fri, 02 Oct 2009 16:18:49 +0000

The Problem:

You need to work with Magento Models, how chic!

The Solution:

Well, let’s be honest… I don’t have THE solution, but I do have some useful snippets of information to pass along.

Models are the meat of an MVC application. They contain the definitions for your application’s components. Stop for a moment and think conceptually about your application. Anything that is represented by a database table is most likely going to be a Model. Anything that can be mentally packaged up and labeled could be a Model. How are Models built, used, and made use of in Magento? Let’s find out.

In the Previous post I showed you how to create a custom Module and one of the main pieces of that Module was the Model Helloworld.

Hello World! My argument is : " . $arg;
  }
}

I’m going to examine it now, in more detail, to flush out some of the intricacies of Magento.

Notice the class definition:

Spinonesolutions_Helloworld_Model_Helloworld

It’s important to maintain this naming convention since Magento uses an autoloader to load class files when they’re called for. If they’re not named correctly it will look at the wrong place in the file system for the file which SHOULD contain the class it’s looking for, but alas it will not be there, and thus; it will not find it and you will receive an error.

Deconstructing the above:

Spinonsolutions_Helloworld_Model_Helloworld
{Namespace}_{Module}_Model_{Model}.php

Let’s look at some permutations to get a deeper understanding:

Spinonesolutions_Helloworld_Model_Worldhello
\Spinonesolutions\Helloworld\Model\Worldhello.php

Spinonesolutions_Helloworld_Model_Foo_Bar
\Spinonesolutions\Helloworld\Model\Foo\Bar.php

Spinonesolutions_Helloworld_Model_Foo_Helloworld
\Spinonesolutions\Helloworld\Model\Foo\Helloworld.php

Picking up the pattern? Good!

The __consruct method is called when Magento builds an instance of this Model. My constructors always contain, at least, a call to the parent constructor and sometimes more depending on the Model.

To instantiate an instance of a Model use Mage::getModel($modelClass,$arguments) or Mage::getSingleton($modelClass,$arguments). The parameter $modelClass is a string, the construction of which is partially determined by the config.xml and partly by the Model’s class definition. Let’s look at IndexController from Part I, line 23.

helloworld("helloworld");
  }
}

The piece of $modelClass that comes before the backslash (spinonesolutions_helloworld) is defined in the config.xml file included in the etc directory of your Module.





0.1.0




 
standard 

Spinonesolutions_Helloworld 
spinonesolutions 






 
Spinonesolutions_Helloworld_Model

Notice the models element. It’s defining a label for the class (and folder) Spinonesolutions_Helloworld_Model. Said in another way; given spinonesolutions_helloworld, the models element tells Magento what class and, by naming convention, what folder to look in for the second piece; that which comes after the backslash.

The piece that comes after the backslash (helloworld) tells Magento what particular Model you’re looking for. In my example, it’s simply helloworld, so the autoloader is going to be looking for a file named Helloworld.php that contains a class definition Spinonesolutions_Helloworld_Model_Helloworld. Lets extend the permutations that we used earlier adding how to instantiate each.

Spinonesolutions_Helloworld_Model_Worldhello
\Spinonesolutions\Helloworld\Model\Worldhello.php
$objModel = Mage::getModel(‘spinonesolutions_helloworld/worldhello’);

Spinonesolutions_Helloworld_Model_Foo_Bar
\Spinonesolutions\Helloworld\Model\Foo\Bar.php
$objModel = Mage::getModel(‘spinonesolutions_helloworld/foo_bar’);

Spinonesolutions_Helloworld_Model_Foo_Helloworld
\Spinonesolutions\Helloworld\Model\Foo\Helloworld.php
$objModel = Mage::getModel(‘spinonesolutions_helloworld/foo_helloworld’);

A great way to get a handle on how the naming conventions work is to meander through the core and note of name of the file and the folder structure it’s been placed in; then compare that to the class definition contained within.

One more time; since it took me a while to figure this out!

\Spinonesolutions\Helloworld\Model\Helloworld.php

Spinonesolutions_Helloworld_Model_Helloworld

Spinonesolutions_Helloworld_Model

$objModel = Mage::getModel(‘spinonesolutions_helloworld/helloworld);

Do you see it! Do you!?

One awesome, and very useful, property of Models is that they can extend any other Model you want. This is, in general, how you extend core Models with your own functionality.

This is absolutely essential when you want to add on to the Magento code base. If you just fire up your text editor and make your changes to the core, the next time you upgrade Magento, there’s a relatively good chance you’ll lose all your work.

That’s all for Models! Not really though, I’ve just covered the basics here, read on for more as I cover extending!

Download the source – Helloworld

Magento – Part I : Custom Module

Will Wright — Wed, 02 Sep 2009 04:00:01 +0000

This article was written while using Magento v1.3.2.3.

Greetings! This is installment number one of the the exiting Magento Custom Module series. There’s basically two paths to the end of the fairytale:

Path 1: You follow this series and get down and dirty with Magento, learning a lot along the way.

Path 2: You go out and download the Module Creator (http://www.magentocommerce.com/wiki/custom_module_with_custom_database_table) and head straight to GO!

Your choice!

Note: Magento is an MVC application so I’m going to assume you have a basic understanding of MVC. Also, Magento is built (I believe) on the Zend framework, so there’s some Zend specific syntax that I’m also not going to dive into. Huzzzah!

The Problem:

You need to create a custom Module in Magento! Why…? Hell, I don’t know; you just do. That’s enough of that, let’s get down to it.

The Solution:

All of your customizations need to go into the [root]\app\code\local folder. This is where Magento expects to find them and it’s also a factor in maintaining your upgrade path. When the next version of Magento is released you’ll be able to backup your “local” folder and blow away everything else.

Before we get too far into this let’s setup our development environment, go to:
Admin -> System -> Cache Management: Cache Control – All Cache = Disable

This will save you many hours of self-torture while you’re developing.

A couple of other developer settings that I’ve found helpful:
Admin -> System -> Configuration -> Developer: Debug – Profiler = yes
Log Settings – Enabled = yes

Now open up [root]\index.php and at the very end you’ll see three lines that are commented out; un-comment them and save.

Finally, turn SEO friendly URLs on:
Admin -> System -> Configuration -> Web: Search Engine Optimization – Use Web Server Rewrites = Yes

All of the URLs that I’ll be presenting as examples below assume that SEO friendly URLs are enabled.

Magento is now correctly configured for development so let’s dive into building a custom module.

Sample file structure:
[root]\app\code\local\{Namespace}\{Modulename}
[root]\app\code\local\{Namespace}\{Modulename}\controllers
[root]\app\code\local\{Namespace}\{Modulename}\etc
[root]\app\code\local\{Namespace}\{Modulename}\etc\config.xml
[root]\app\code\local\{Namespace}\{Modulename}\Helper
[root]\app\code\local\{Namespace}\{Modulename}\Helper\Data.php
[root]\app\code\local\{Namespace}\{Modulename}\Model
[root]\app\code\local\{Namespace}\{Modulename}\{Modulename}.php

{Namespace} is a user defined variable. Basically it’s just a mechanism that allows the user to create disparate classes that would otherwise have the same names.
{Modulename} this is the name of your module.

For my examples I’m going to use “Spinonesolutions” as my namespace and “Helloworld” as my Module. I’m not entirely sure if it matters or not, but as a general rule I always capitalize the first letter and leave the rest lower case. Don’t use underscores in your names either, we’ll see why later.

controllers is where all the controllers go, crazy right? I’ll get into the controller structure in another part of this series. For now a sample will suffice.

helloworld("helloworld");
  }
}

Data.php is just a helper file for the Magento internals, I’m not exactly sure what it does but it appears to be exactly the same in every module except for its class definition.

Model holds all of the models for your module. It’s customary to name your main model after your {Modulename}. You’ll most likely have at least one model and if you browse through the Magento core you’ll notice that most modules contain many models.

Hello World! My argument is : " . $arg;
  }
}

config.xml is where you connect all your code up to Magento. There’s a lot of voodoo going on in here and I’m not entirely sure how it all works. I might even write a full post on the config.xml as a forthcoming part of this series.



 
   
   0.1.0
   
 
 
   
         
       standard    
       
         Spinonesolutions_Helloworld    
         spinonesolutions    
       
     
   
 
 
   
         
       Spinonesolutions_Helloworld_Model

That takes care of all the code needed in the module directory. There’s one more configuration file we need to create and it’s an exception to the local folder rule:
[root]\app\etc\modules\{Namespace}_{Modulename}.xml



 
   
     true
     local

This file tells Magento that there’s a new module out there that it needs to load. Alternatively, you can name your file [root]\app\etc\modules\{Namespace}_All.xml to tell Magento to load up all the modules in that namespace.

Once you have this file in place you can navigate to Admin->System -> Configuration -> Advanced and you should see your module enabled here.

You now have a functioning custom module, hurray!

Download the source – Helloworld