So far I was mainly occupied to implement some of my conceptions I used for the xtCommerce/Gambio GX shop-systems (e.g. my templating concept) [B]for [/B]OXID.
You might be interested to learn, that the xtCommerce/Gambio GX shop-systems now have inherited [B]from [/B]OXID…
I have successfully implemented the [B]class overloading[/B] concept of OXID (you know, this “[B]class my_class extends my_class_parent[/B]” and “[B]oxclass => [/B][B]my_class&my_other_class[/B]” thing…) for xtCommerce/Gambio GX.
As xtCommerce/Gambio GX are not fully class oriented, it is only a small (but nevertheless very helpful) relief, though.
But it helps me in some actual projects to avoid the otherwise necessary changes directly in the core classes.
And put the changes in overriding modules instead, utilising the very same concept (and -modified- code) that OXID uses.
[B]Every little helps![/B]
As xtCommerce/Gambio GX have not been designed with such a concept in mind, it is a bit tricky to achieve the desired effect.
The hook into xtCommerce/Gambio GX is a PHP “[B]autoload[/B]”-handler for classes, which makes all the necessary assignments.
As the “[B]autoload[/B]”-handler is [B]only [/B]activated for classes [B]not [/B]defined so far (and xtCommerce/Gambio GX properly “include” the class files before using the class), you need to [B]force [/B]an “[B]autoload[/B]” before xtCommerce/Gambio GX is actually defining and using the classes to override.
To use the override capability, I have therefore included in the xtCommerce/Gambio GX [B]config[/B]-file (to avoid changes in files which might get updated) the following code:
include(DIR_FS_INC.'pt_autoloader.php');
//Define classes to overload parameters
global $aModules;
$aModules=array(
'Smarty' => 'powertemplate/pt_smarty/pt_smarty',
'GMMeta' => 'powertemplate/pt_gmmeta/pt_gmmeta'
);
//Force class autoload for classes to override!!!!
foreach ($aModules as $class=>$module)
{
class_exists($class);
}
So for one you have to define the overriding assignments manually in “[B]$aModules[/B]” (and not via an admin GUI as in OXID…)
And, most important, you have to explicitely [B]force the autoloader into action[/B] by using a “[B]class_exists[/B]”-call for each class you intend override… (It was done that way in order to avoid the otherwise necessary removal class-“includes” in the shop-code.)
Here I am overloading “Smarty” and a class, which handles the shop’s “META”-Data construction.
The capability to overload Smarty that way is very important for me.
Because in order to subclass Smarty, so far I had to slightly modify Smarty (i.e., give the Smarty class another name, as I needed the original name for my overriding Smarty-class), so I was prone to Smarty updating problems.
Which are now gone, as I can use the standard Smarty distribution using this new capability!
And I can subclass any class used in xtCommerce/Gambio GX the “right” way!