Quote:
Originally Posted by erayd
It's not - it's the start of a skeleton; I've been waiting for feedback on the design before I sink some serious time into it - I'd rather get it right the first time than have to go back and redo it because people don't like the structure.
|
For myself, I think that the current design, as I understand it, is on the right track:
A main Flag object, which houses:
- A global configuration object, accessible from anywhere,
- An array of sources, loaded on-demand,
- each source could have its own customized configuration object, maybe derived from the global. The global would just pass the raw source options to the derived for final parsing, along with pre-computed parameters (if the global found some URLs matching that source, for exemple).
- An array of codecs, also loaded on-demand
- as for the sources, a codec could have its own configuration object.
- An access to an object which'll handle the updating introduced in AtomicDryad's mods
The only point I'm dubious about is the one we've already touched on github, that is, making everything a factory singleton. I have nearly the same approach in my coding, and with the advent of PHP5.3 it also looks a lot like yours: a main SingletonFactory class, which stores factories derived from itself (before 5.3, each factory stored its instance within its own static member). But I tend to limit the factories to the fewest possible, and my SingletonFactory base class only stores and retrieves instances, no init() method. Validation of classes is managed by __autoload() as needed, and the rest would be done by the main class (since it's only ever called by the main class anyway).
So I have mainly three types of classes:
- Factories derived from SingletonFactory (flagFactory here), which have a simple get() static method to retrieve the instance (or create it): $people=People::get().
Those do the heavy lifting: database access, loadings, savings, etc. They are the only classes allowed to instantiate anything (except for the bootstrap, obviously), and they do it through methods like (Person)$person = $people->GetPerson($id) or $list_people = People::get()->GetEveryone(), or any other Get method I need (GetDeparmtent($id_department), GetBySecurityLevel($level), etc.). It never does any manipulation of data, except those necessary for storing or retrieving it.
For exemple, I'd have a Codecs class, which could allow me to get an existing codec instance, a list of all instances, the names of all codecs, etc.
- Data manipulation classes, which describe a data model and manipulates them.
Those are not factories, they don't instantiate anything. However, they are instantiated with everything they need to know about themselves, or can compute what they don't know. From there, they can return info about themselves, or computed info based on parameters: a Person class, instantiated by $person=People::get()->GetPerson(12) could have a $person->GetFullName($title=false, $initials=false) method which would return Mr John Doe, or J. Doe. Also methods like $person->SetSecurityLevel($level), which would check the validity of the parameter before calling People::SetSecurityLevel($id, $level) for the database update.
For our project, I'd have a Source class, like we have, but we wouldn't have to make it a factory, because any instantiation management we'd need would be taken care of by a Sources class (and ultimately by flagFactory, its parent class). Same for a Codecs (extends FlagFactory) class and a Codec class.
- And finally Controllers, which parse page and session parameters, call the necessary factory methods according to those parameters, and pass all that to a template engine (PHPTAL for my projects) for presentation.
Here we'd have two controllers: CLI and web, but all the parameter parsing part is so complex that it's offloaded to the Config object(s). The controllers will merely have to call the Sources methods to retrieve the data, then the Codecs methods to save that data as files, all the while outputting a summary of the process.
The template engine would also be way overkill, so the web controller would also need to take care of all the HTML generation.
Now that I think of it, it also means that flagFactory::$sourceList and flagFactory::$codecList would actually belong to Sources and Codecs respectively, and the main Flag and Config class would have two more members: $sources which would store the Sources instance, and $codecs for the Codecs instance. I can't think of anyone else that would need to keep both of them as members.
For the class autoloading, I myself like to use a separate autoloader.inc.php file, with only an __autoload() function, and called either in the php.ini (not really doable here), or in the 'flag' bootstrap.
I'm sorry that I hadn't had much time 'till now to work on this (work and all), but now that I have a week off I'll be able to have some fun with this!
N.