I was thinking and I totally have it. I also have some idea on how I will do it also. The idea is to create a factory class that allows access to filters for doing multiple stuff and editing content for security or reformatting or whatever.
The factory class called Filter will have no implementation on its own and will depend on other classes for functionality.
Add
The add method (or function) will take the add on class and put it in an array that will hold the class and the name of the class. Any number of classes could be added, but I will need to make sure that the names are unique so that two things don’t happen. For the basic implementation, I will only allow for the unique name value pair and later add in where two classes with the same name and functionality could run together on the same data with some type of priority in place to tell who goes first.
remove
A class should be able to be removed at any time depending on the needs of the user. It won’t be dereferenced, just put aside in a place where the class says, “Hey you, you go play, we’ll call you when you are needed again.” Then once that part is done, it can come back and play with the others.
parse
Will take the unique name return the class and take the parameter for the value.
$cleanFormData = $filter->parse(’security’)->cleanse($rawformdata);
Keep It Simple
By keeping the Filter class simple, I can add complexity to what could be done with the multiple filters for different tasks. Also allowing any number of developers to create their own filter classes to add on to the ones. It would be cool because it would done so that only the classes that are needed are used when they are needed and then taken care of afterwards. It shouldn’t add that much overhead and to the developer using the filter, it would seem that all of the functionality is taking place in that one class and would only need to download the other filters as they come.
By keeping all of the filter functions out of one class and keeping the one major filter class stable, I can keep it clean with a small footprint. As the game engine development continues more filters and better functionality can be added to the filter class, but by keeping to the simple functions I could perhaps keep some backwards compatiblity. Only the classes themselves would have to be upgraded and the filters to them changed, if at all. There shouldn’t be a need to worry about whether something would break because of a filter was changed or an upgrade version added something new or removed something. “It will just work ™,” and that is how it should be and how I hope I will be able to create it.
Actual Implementation
It won’t be as simple or easy as that as I still have to code the damn thing and test it. Then I have to create the actual filter classes to go with it. I hope to have a good library of filters for when the final version comes out but for now the 0.6 version will be pretty minimal with myself adding them as I need them or as I think of them. Here is for wishful thinking.
Possibly Related Posts:
- Mecha Asylum Design Document
- Data Store is Finished, but Still Imperfect
- If You Look at it This Way
- Configuration SPL Usage
- New Configuration Factory Possible Features