Structural changes for Maps and SM 0.3

Just like version 0.2 of both Maps and Semantic Maps, version 0.3 will feature a variety of large structural changes, aimed at increasing the performance of the extensions, making it possible to add new features, but most of all, make it more modular, to allow people to easily extend them. Here you have a list of the mayor changes that have been completed so far, with some explanation of the advantages they bring.

• Base class that bundles common functionality between MapsBaseMap, SMMapPrinter and SMFormInput, and gets inherited by those classes. This class has been named MapsMapFeature. This is a great step towards the complete centralization of all common code, but sadly enough was not implementable the whole way: MapsMapFeature cannot be inherited by SMMapPrinter, since this class already inherits the SMW QP. Yaron suggested to use a ‘has-a’ implementation, witch means creating an instance of one of the classes you want to inherit as a class field, instead of the ‘is-a’ which is the regular inheritance. Although this is doable in theory, it will bring with it some other problems, so will have to wait till another version.

• Separation between the common and specific parameters, and their default values. Each mapping service now holds an array containing the extra parameters they add (so the allowed ones), and another array containing their default values. Note that both arrays are merged with the common arrays at runtime, and will override similarity named items. This allows to change the default value of a common property, or change the aliases.

• Yes, indeed, that’s right, aliases! Property names now have aliases. This means you can add several alternative ways to name the same parameter, for instance, you can make so that ‘auto zoom’ and ‘auto-zoom’ will do excellently the same as the main parameter ‘autozoom’. This is particularly handy for parameters such as ‘centre’ (British spelling) and ‘center’ (American spelling).

• Hook like system for mapping services. This is without a doubt the most important change since 0.1. All hard-coded references to mapping services in the core code have been removed. A service is now added by one multi dimensional array in Maps.php (note that this can also be done in the initialization file of another extension!), which holds the name of the parser functions class and it’s location, the aliases for the service name (feature added in 0.2), and their allowed specific parameters and their aliases. This architecture will allow other people to create their own mapping extension using the Maps (and Semantic Maps) ‘API’, which enables them to focus on the mapping service specific code rather then extension related code, or common mapping code. There are numerous more advantages, like the fact that their ‘extension’ will follow some general norms, which will make it easier for uses to use (and install!) and for developers to work on, and the fact that their code will also benefit from improvements made to the core code of Maps and Semantic Maps. Once 0.3 is release, I’m going to create a new section in both the Maps and Semantic Maps documentation, which will hold a list of why people should consider choosing that approach, as opposed to creating their own little mapping extension, a list of the advantages, and documentation on how to effectively do it.

The above improvements have been made in Maps, but still have to be implemented in Semantic Maps, which is now on the top of my to-do list. I’m also busy with the adding of new functionality, and got some great results so far, but I’ll post about those when more of the work for 0.3 is done.