Inside Mod Manager v14 Concepts

From TNG_Wiki
Jump to navigation Jump to search

Back to main page

Overview

For this discussion, we will refer to MM PHP file names using a descriptive shorthand. For example, classes/modlister.class.php is referred to simply as Modlister; admin_modhandler.php is shortened to Modhandler.

Mod Manager v14 is partly standard PHP, and partly PHP Object Oriented Programming (OOP). It consists of a standard PHP control file like Modhandler that creates objects from a library of class definitions and uses them to accomplish a specific purpose such as listing the site's mods and their installation status.

It is important to understand that a class definition file like classes/modlister.class.php is a blueprint for creating an object. It is not the object itself. You can think of an object as a completely closed black box that lives entirely in memory and has exterior controls to access its public data and functions.

Because a class object cannot "see" the TNG environment, the data must be "injected" into the object as it is being instantiated (created in memory). Each class with a top level mission has a standard PHP function at the end of its class definition file to initialize and return an MM object of that class to a variable that the user assigns.

In Mod Manager, instead of directly initializing an MM object, the control script calls the class initializer function. for example, to get a Modvalidator object and use it to validate a mod:

include "classes/modvalidator.class.php";
$oVal = new_modvalidator();
$parse_table = $oVal->validate( $path_to_mod );

Examine a couple of the initializing functions to see exactly how they work.

A new MM object stores the injected data as object globals. Thus, $admtext can be globally accessed inside the class as $this->admtext; $subroot becomes $this->subroot inside the class.

Extending A Class

To extend a class, the extending class definition will contain something like the following opening:

class modlister extends modvalidator { ...

If you are new to OOP, you may think of an extended class the same way you think of an "include" file in function-oriented PHP. The difference is that an OOP extending class will not necessarily have access to all of the extended object's functions and data. This feature is very useful for MM.

Inside an object, each variable and function is declared with a scope operator -- public, protected or private. If a class declares something private, the extending classes will not "see" it and cannot access it. We will use this to our advantage throughout Mod Manager. Many classes will define functions with the same name, but with different purposes. Making them private ensures that extending class functions of the same name will not incur a "function redefinition" error.

Unlike other programming languages, a PHP class can only extend one class at a time, so we have to chain them to get the same result. We can diagram an extension chain like this:

Modbase -> Modparser-> Modvalidator -> Modlister 

Modbase contains common data and functions used by other classes; it is extended to here to create a Modparser object, which adds new functions to parse and syntax-check mod configuration files.

Modparser creates a parse table in the object's global memory with a result for each directive in the mod file.

Modparser is extended by Modvalidator, which adds functions to confirm that all elements are in place and ready to be installed or uninstalled. Modvalidator updates the parse table with the installation status of each directive.

Finally Modvalidator is extended by Modlister which contains everything necessary to display the Mod Manager main page based on the information in the parse table.

Here is a complete diagram of all mod classes as they are used.

Modbase -> Modparser -> Modvalidator
Modbase -> Modparser -> Modvalidator -> Modlister
Modbase -> Modparser -> Modvalidator -> Modanalyzer
Modbase -> Modparser -> Modvalidator -> Modtables 
Modbase -> Modparser -> Modinstaller
Modbase -> Modparser -> Modremover
Modbase -> Modparser -> Modeditor
Modbase -> Moddeleter 

Mod Manager class definition files are all found in the "classes" folder in the TNG root directory. They are used by first including a class definition file into a normal PHP script, then creating the object with the class instantiation function, for example,

include 'classes/modinstaller.class.php';
$oInstaller = new_modinstaller();

As you will have noticed by now, Mod Manager class names suggest their functions.

References

If you need an OOP refresher, here is a Youtube link that may help:
Object Oriented Programming (OOP) for Beginners in PHP (Youtube)

Inside Mod Manager v14 Directory

TOC

Inside Mod Manager v14 (Home)

  1. Mod Manager and OOP
  2. Mod Manager v14 Concepts
  3. Page Layout
  4. Modules
  5. Directives
  6. Error Handling
  7. Best Practices