This is a rough draft of the developer documentation that will describe the way that factories are used in TT3 to load other modules.
There are a number of modules in TT3 whose sole responsibility is to locate and load modules and instantiate objects of the corresponding classes. They are all called factory modules.
Responsible for loading Template::TT2::Engine::* engine modules.
Responsible for loading Template::TT2::Dialect::* dialect modules.
Responsible for loading Template::TT2::Service::* services modules.
The factories listed above are in most cases very thin wrappers around a common factory base classes.
This is where it all begins. You should go and read the documentation for that. Be aware that B::F has grown organically over the last 2 years and it's ready for a good cleanup. In an earlier implementation of TT3 I had 3 factory base classes of progressive complexity: one that just loaded modules, one that loaded modules and created objects, and another that also cached the object. I thought I was being clever by merging them all into one in the form of Badger::Factory, but now I think it may have been a mistake. I've hit a few complexity barriers and "WTF?!?!" moments where I've got lost in what B::F is doing. That's a sure sign that it needs re-thinking. So expect some change here, but it'll be as backward-compatible as possible.
This is our thin subclass of Badger::Factory where we customise a few details that are specific to TT3.
This is a subclass of Badger::Class specialised for creating factory classes. You should go and skim the documentation for Badger::Class and then take a look over Badger::Factory::Class at this point.
This is a thin subclass of Badger::Factory::Class that uses our Template::TT3::Factory as the base class for our factories instead of the default Badger::Factory . This allows us to inject our custom TT3 behaviours into our factory classes.
Andy Wardley http://wardley.org/