Jacob Santos

Well, it is done, but it will still take a little while to get everything perfected. I still have to connect the DataStore to the rest of the Configuration Factory, so I still have one more day to work before I’m finished and I have another day of testing before the refactoring is finished. It will probabably take another day for the XML, but I think if I use SimpleXML, it will make it easier to finish. It will have to take XMLWriter or XML DOM to do the document writing and updating. The nice thing about DOM and SimpleXML is that I can link both, but it would be nice to see what XMLWriter and XMLReader can do.

Possibly Related Posts:

• Mecha Asylum Design Document
• If You Look at it This Way
• Configuration SPL Usage
• New Configuration Factory Possible Features
• Configuration Data Store Class

The Configuration Factory coding is by far the hardest task I have had so far while working with the new game engine, but I’m certain that the work put into it will pay off. I’ll probably won’t use it past 0.6 and will rewrite most of the code for 0.7 (maybe, not certain), but the experience will stay with me long after it is dumped.

I’ve figured if I look at it like the Data Store is a Factory by itself, then it becomes easier to comprehend. Actually, the model loosely follows the MVC, but I don’t know enough of MVC to know for sure. I’ll say it is a factory factory model. The Data Store could be the Presentation layer, but that is the only thing that I know.

Possibly Related Posts:

• Mecha Asylum Design Document
• Data Store is Finished, but Still Imperfect
• Configuration SPL Usage
• New Configuration Factory Possible Features
• Configuration Data Store Class

I’ve found a few SPL classes that would work great with the new Configuration Factory.

One is ArrayObject which Classes can be stored and used in the way I want it to be used.

The other is IniGroups, which does the job for me when reading INI files.

Dain Bramage

I’m nearing the point where I can’t grok the whole thing and I will need to do some unit testing to finish the Factory.

Possibly Related Posts:

• Mecha Asylum Design Document
• Data Store is Finished, but Still Imperfect
• If You Look at it This Way
• New Configuration Factory Possible Features
• Configuration Data Store Class

Once the new Configuration is finish, it would be completely possible to have a SQLite or XML or CONF configuration referencing the MySQL access data and then using MySQL for the rest of the information. The main factory class will check every configuration for the value (this part hasn’t been finished yet), so it is totally possible for multiple names and sections to come up, but that will be worked out by giving a name to each of the configuration when loaded.

$config->load(‘/path/to/sqlite/database.sqlite’, ’site’);
$config->load(‘/path/to/xml/mysql.xml’, ‘database’);

So there are two configuration files loaded with the name ‘database’, and ’site’. These must be unique and since there shouldn’t be a great deal of the configuration files and usage, that requirement shouldn’t be unreasonable.

So you could access them by

$config['mysql']['username']; // From mysql.xml
$config['mysql']['host']; // From mysql.xml

$config['template']['default']; // From database.sqlite

or you could do

$config['database']['mysql']['username'];
$config['site']['template']['default'];

In which case that there is the same name as the configuration name, then the configuration name will be used first to see if the section exists, if not, then it will use the first usage without.

For $config['mysql'] see if name is a placeholder for the configuration file? No, then it must be a section, return that the section that it exists in.

For $config['database']['database'], does the name exist for the configuration file? Yes, does the section exist? Yes, then return the section.

What if it doesn’t exist? Does the next section exist (['mysql']), yes then ignore the last section. If not then create the section.

Other Methods

I’ll probably have a lot more functions in place so that the programmer can do accurate checking and command the classes in the exact action to take and not guess.

if($config['database']['section']->exists() === false) $config['database']['section']->create();

if($config['database']['section']->isUnique() === false) $config['database']['section']['name'] = value;

It would take a lot more coding, but I believe the configuration class will offer a great deal of features and options over the other configuration available.

Caching

There is still no internal caching, but I’m currently working on that issue. If the configuration class is fast enough, then I don’t think I’ll include it, but it will most likely be a 0.7 issue anyway even if it isn’t needed. If it is needed, then I’ll have to add it to the class and it will most likely be an array in the main factory class.

By using the Data Store, I hope to have the ability to add it in. Currently, My mind is spent on just trying to create an intelligent Configuration Factory that allows for multiple configuration files. The idea of keeping the instance of the Data Store in memory is a foreign concept to me, but I may an idea on how to do it Using the Data Store.

Possibly Related Posts:

• Mecha Asylum Design Document
• Data Store is Finished, but Still Imperfect
• If You Look at it This Way
• Configuration SPL Usage
• Configuration Data Store Class

In an inspiration on how I’m going to create the generic Configuration Factory, I decided that I should create a Data Store for the configuration with a reference back to the creation class. In this way, I can reference all of the features, restrictions, nonunique names and sections, and provide a way for creating more than the three possible configurations later.

This would require I refactor the configuration class yet again, but seeing as I didn’t quite finish the SQLite part, it wouldn’t be a huge loss. It would however get into another complex class model, but it would keep from rewriting a lot of the same code over and over again.

Three base Configuration classes:

1. ConfigurationSQLite
2. ConfigurationXML
3. ConfigurationConf : Which will also load INI and TXT files.

There will also be a few other classes for the DataStore:

• ConfigurationDataStore
• ConfigurationName
• ConfigurationSection
• ConfigurationVisibility
• ConfigurationRestrictions

Example

The DataStore class will hold the Name, Section, Visibility, and Restrictions classes and provide access to them. If there are nonunique names and sections, then an array will be returned that will reference the name and section.

$config['database'] //is not unique, there is also a section with the same name.

$config['database']['name'] //name is not the variable and will not change. Will return the database name value.

$config['database']['section'] // Will return the section.

So, if Database has a subsection, then this would have to be done.

$config['database']['section']['connections']['section']

It will also be possible to do:

$config['database']->getName(); // Will return the name value for Database instead of returning the Section.
$config['database']['connections']

If you want to use that name get method instead. However the name will be the only method that will do this. if they want to do with sections they would have to use the sections method from the beginning.

Reasoning

I want to have a lot of different configurations for the Configuration Factory in case the person wants or needs to return the name on default.

The best case is when the programmer is creating the configuration from the base using the Configuration Class to do so. In which way, they would be able to create it to where there are no unique values. However in an environment where the configuration is external that is not always possible and such a restriction can not be put in place.

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

The issue is the new Configuration Factory, which is that there can be a section and name with the same, well same name. I can check for the name of either for section or name but if both show up then I have an issue, when I need to figure out if they want the name or section. It is easy to figure it out if they are trying to set a name with a value, because they can’t set a section with a value.

I have figured that I could return both the name and the section, but that wouldn’t quite allow the user to access the other subsections. The optimal solution would be to force that either the name or section be unique and offer two functions for checking either one. I should have a third function for checking if there are subsections, which would return just a bool, mostly for the importing and exporting. Each of the subsections would have the same functions allowing for checking in the case the person does not know what values exist or doesn’t remember.

Another part of the classes will be the functions section and name, which could be used in accurately get the sections and names.

$config->section(’section’)->section(’subsection’)->name(‘name’) = value;

which would be the same as

$config['section']['subsection']['name'] = value;

Since the second is less typing then it is all good, except is section is a name, then it will return $config['section'] and nothing else.

XML configuration will be the hardest part about this since there is no restricting this activity or any reason to restrict the activity. How do you tell someone creating a XML document that they can’t have a section and name as the same value? If they have a short file then it would be simple but still pretty damn idiotic (pretty sure they would just laugh). It would be impossible if the file has over 1000 elements.

INI can’t have subsections

…but it can have both sections and names of the same value. Also, names don’t have to be unique either. Which creates an array and returns it. So the scripting would be like

$config->name(‘name’) = value

$config->section(’section’)->name(‘name’) = value

or

$config['name'] = value

$config['section']['name'] = value

Given that most INI or CONF files will have sections that are unique from the names, then the array usage can be acceptable.

Caching

I want to store configuration in arrays when they are used as a sort of caching for values that are going to be used a lot. The only issue is that configuration are mostly used a few times, or at least in my case.

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

In my attempts to speed through the new Configuration Factory, I had forgotten that I wanted to allow support for multiple configuration values from multiple sources. This comes from the fact that a project may have multiple different points of configuration.

You may have the main project use a xml file for configuration while the other components, such as plugins and themes use another form, such as a xml or conf file.

As it stands now, that is only possible by creating more than one instance of the configuration factory and that isn’t what the initial intention was when I had planned the refactoring. It will allow for testing and once that is done, then I’ll have to go back and allow for the new configurations, It shouldn’t be all that difficult to add once everything else is complete.

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

Refactoring Back Story

After trying to rewrite Template Lite and messing around with the configuration class, I kept asking myself why couldn’t I use XML instead and use the PHP 5 XML classes. The reason is that I have to maintain some compatiablity between Template Lite, Smarty, and my changes. I came to the conclusion that if I’m going to need to use XML and the configuration of Template Lite and Smarty, then I should instead update my configuration class and use it instead.

Configuration Support

1. SQLite

MySQL won’t ever be supported because it would be impossible to store mysql database connection information in the mysql database.

SQLite was the first configuration type and I love working with it. I started with the code base from the www.php.net comments for the type and I have been extending it ever since. It has since grown to be more than a single class and allow for a lot more than regular name, value pair.

I’m going to be adding:

• Restrictions
• Unlimited Subsections
• Support for nonunique names to be collected in an array, removing the restriction that names be unique in the given section and subsections (currently uses unique name, value pair).

Which may not seem like much but it will require a great deal of rewriting of the code to support those two features. Even adding Sections was a lot of work and the ability of subsections will allow restrictions to be created.

I already have the syntax and how it will work figured out. I just have to finish coding it. I’ll probably code it first since I can test it out using my same code and I don’t think it will all that difficult to do.

2. XML

It will work a lot like the SQLite database configuration, including the following features.

• Section and Unlimited Subsection Support
• Restrictions
• Single and support for multiple names (just like in SQLite configuration support)

It will closely resemble the SQLite configuration feature set and should be simple to implement compared to SQLite. Access will be the same as for SQLite also, so the difference will be only in the file type and conversion between the two will be easy.

I’ll probably work on this next as I want to test the creation and the ability to get XML DOM classes to work the way I want it to add and get the name value pairs. Testing will have to be in depth to get this fully working without any major bugs. It would be really neat feature to have, extra bonus if it functions like SQLite.

3. Plain Text

Also known as INI settings, but it will work with the configuration of Smarty and Template Lite, so it would be possible to replace the Template configuration class with my own. The only issue is that I’m going to have to parse it using my own method instead of ripping off either Template Lite or Smarty. I’m certain I can get the parsing done correctly.

Support is only for sections and name, value pairs. Restrictions and subsections won’t be supported. I’m sure I could find some way to implement them, but I don’t see the point of trying as they still would not work with the configuration of Smarty or Template Lite.

Conversions between SQLite and XML would most likely drop the restrictions and flatten the sections and subsections, so that all of the subsections would become plain sections.

Other Configuration Features

There will be an file creation methods for creating the ini and xml files. It will also test for proper file permissions and change them if they aren’t given. It would also correct file permissions to keep the files from viewed in the browser but still be viewed by the configuration factory. This security measure would keep prying eyes out of the sensitive Database settings, at least for *nix systems. Windows users would have to locate the file outside of the web directory.

Template Factory

I’m going to be building a Template Factory that implements three template features.

1. Quick Template for using php tags as well as php variables and assigning them values.
2. XML/XSL Template for transforming XML tags and assigning them values. Would use more of XML techniques than XSL.
3. Back Support for Smarty and Template Lite. The Template Lite classes would be updated to work with PHP 5 native class features and other PHP 5 features.

Overall giving the developer the ability to choose would increase the options and difficultly, but offer the choice of the best template to the developer to work with. At the very least, the Quick Template should be used since it ties in to what most people do now anyway.

How Much Time?

The template work is taking a great deal of time and I’m working and testing it between working on the Security features, database features, and Configuration features. I’m tweaking here and there finding a feel for how it works completely, so that I can better update it for PHP 5.

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

Version 0.6 is going to have a great deal more security features than the previous version and with good reason. A few game projects that I have worked with were hacked and I had to spend a lot of time going through and trying to fix the hacking problems. I am going to provide a wide array of security tools in the updated version and a few I’m still working on, I suspect that a complete feature set won’t be available until at least version 1.0, but I suspect new exploits are going to pop up after the fact as new techniques are used (re: phpBB).

Speaking of which, I haven’t yet reached the point where I can use or find a reason to use some of the techniques in phpBB, notablely the one where they serialize the classes for storage. While it would be a good idea for caching, I haven’t added support for it and probably won’t until a later version when I fully tested caching techniques.

Back to the Point

It seems I went off on a tangent, the point is that I’m spending more time on security features and backend as well as research than I did on Mecha Asylum or 0.5 version of the game engine. Whether it will be better for it, of course, but I’ve looked at another game engine framework that is in the works and it appears they may have a better idea on how to do the security and filtering. For now, I think it should be up to the programmer to implement it themselves. The only way I could think of implementing something like that is if they extended the security filter class and it wasn’t meant to be used like that. As an aside, I should make it use final so that they don’t try to extend it.

Other Parts: Plugin

The plugin interface will be simple and shouldn’t take very long, the reason why I haven’t started it yet is because it would require testing and I’m not ready to work on the classes for testing. The Plugin feature set will most likely be extended and changed throughout the 0.6 development cycle as I think of new ways to reinvent the wheel. It would be a good start in the right direction given that I should have already had version 0.6 out the door by now.

Installer

It is part of the Core components, or at least that is where I’m placing it, it will most likely be in a place outside of the game as I extend it and add in Modding features. I probably won’t have this completely finished until after version 1.0, unless I decide that I have nothing better to fix or do than to crank this out of my ass. Even so, I don’t suspect that I’ll code more than the basic functionality until after the game engine is finalized.

I’ll most likely package it as a separate package for future updates, but for now, having it part of the core allows me to use and test it for when I do separate it in a later version and add the modding feature. I also won’t be working on it until after the game engine is almost complete in case I want to move it to the next version. It just depends on how bored I am and how good of a basic feature set I want to give it.

Most likely move the installer feature set to the Database Factory in some form or another and focus on improving it in a later version. I do want to have it automated in some form or another.

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