Skip to content

tool php classmap generator packagist

After a month, i've finished a tool to create a classmap from a php project. The current stable version is v1.4 and can be found on as well as on Why? Well, obviously because i can (and wanted to learn a few things like tokens, or symfony console) ;-). But for real, when you have to deal with legacy projects or code but want to remove the strange and slow existing autoloader (with all its exception), the easiest way to do this is by using a classmap. I also tried to find a classmap generator that can deal with psr-0 and not psr-0 files, all i could find are generators that support psr-0 files. A classmap itself is just a php array. The key is the full qualified classname and the value is the relative path to the file. Creating a classmap on your own is suitable when you have to manage a number of files below 20. But when it comes to more you can not effort the time to maintain that file. So for a lot of files that are not covert by composer, the classmap generator should be well suitable. It is planned to implement a "phar" classmap generation for the upcoming version. When you want to create phar files, this could be a timesaver as well. The classmap generator is build by using symfony\console and yes, it is a joy to work with that component! Shame on me, the current version is not covered by unittests. After i implemented the current features from the todo list, this will be my major task.

The classmap generator can handle all kind of php files like: - Interface - Abstract Class - Class The generator can handle files with or without namespace. Even files with multiple definitions (interface, abstract class and class in one file) is no problem. Furthermore, you can create multiple configuration files and update this classmaps when needed. Like well known from the composer, the classmap generator is able to create a autoloader file for you. The created autoloader will use the created classmap file and supports psr-0 autoloading. source/link to the wiki

What is left to write? Of course i'm proud about this. What you see right now is the work of one month and after i finished the core design, i rebuild a lot by replacing my cli application class with the symfony\console component. I hope you can use the tool. If you need help or found a bug, contact me on - the long road to a php data mapper - part 1

I am working on the private project "" to get away from social services and have a tool that fits perfectly to my own requirement. Private projects always (should ;-)) have the benefit of "no time preasure" that leads to "implement some cool features". The first thing on this feature list is a data mapper.

Why a datamapper? Well, won't you like to work with domain models and don't give a s*** about how and where the data is stored? There is a wonderfull and short article created by Martin Fowler and i just have to recomend this one. I found two datamapper projects for php on the web, pdodatamapper and phpdatamapper. To keep things short, a data mapper removes the logic of "how and where" to store the model data. Both projects are still under heavy development and are not in a final state right now. I will not use them (but always take a look on how they have things done).

So what should my data mapper do? All in all, it should hide all the database tables from the developer - even the orm if used. I just want to create a domain model and use it to store and get data from a persistent storage. My data mapper must be smart enough to figure out which rowset on which storage/database table he has to update (or create). The data mapper should have a lazy loading/storing mechanism, this should be done by a propertieset that knows which propertie is stored on which storage/database table. My data mapper should support a very simple/limited filter mechanism that prevents me to blow up my data mapper class with to many "loadModelWhenItFitsToTheFollowingCircumstances"-methods. This data mapper should also support to create a domain model by the upper called filter mechanism.

I decided that the general data mapper methods "insert()", "update" and "delete" are not perfect in the matter of sense to fit on my requirements. Thats why this data mapper will have the methods "load($model, $filters)", "save($model)" and "delete($model)". You can adapt each data mapper by adding own load methods with pre defined filters.

Filter what? All this filtering leads to a filter class. This is a simple and straight forward one with the properties "criteria", "name" and "value". The filter class has to be independent from the real storage implementation, thats why i will use an aditional filterMapper class. This filterMapper is used from the data mapper and prevents to write doublicated storage dependent code. He is responsible to transform the general filterset to the a storage dependant model - means you throw the filter and the storage model inside and get the storage model with added storageFilter back. That filter and filterMapper can communicate with each other by using a criteria class. The criteria class will define what "like" or "greater then" is so that the filterMapper can map this to the storage model.

After the trip to the filtering adventure, we are back to the data mapper itself. The real domainModelDataMapper will use a general propertieSet class. This propertieSet class is the only real connection between the domainModelProperties and the (maybe more the one) storage models - so the theorie currently ;-). I must admit, i have made no decision if the real domainModelDataMapper is a decorator of the dataMapper, or if the dataMapper class is implemented as abstract class. Since the whole project is a "learning by doing", i will figure out what will work - final in the phase of implementation (have i remarked that i never ever have worked with a data mapper for real? ;-) ). Lets see what is next.