Default The xtCommerce/Gambio GX shop-systems inherit from OXID...

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) for OXID.

You might be interested to learn, that the xtCommerce/Gambio GX shop-systems now have inherited from OXID...

I have successfully implemented the class overloading concept of OXID (you know, this "class my_class extends my_class_parent" and "oxclass => my_class&my_other_class" 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.

Every little helps!

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 "autoload"-handler for classes, which makes all the necessary assignments.

As the "autoload"-handler is only activated for classes not defined so far (and xtCommerce/Gambio GX properly "include" the class files before using the class), you need to force an "autoload" 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 config-file (to avoid changes in files which might get updated) the following code:


//Define classes to overload parameters
global $aModules;

  'Smarty' => 'powertemplate/pt_smarty/pt_smarty',
  'GMMeta' => 'powertemplate/pt_gmmeta/pt_gmmeta'

//Force class autoload for classes to override!!!!
foreach ($aModules as $class=>$module)
So for one you have to define the overriding assignments manually in "$aModules" (and not via an admin GUI as in OXID...)

And, most important, you have to explicitely force the autoloader into action by using a "class_exists"-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!

Individuelle und hochwertige OXID 4 Templates und Shop-Erweiterungen gibt es bei
  1. Dem Ingeniör ist nichts zu schwör (Daniel Düsentrieb, 1952)
  2. Geht nicht, gibt's nicht.
  3. Was nicht passt, wird passend gemacht
Weitere Informationen zum Angebotsspektrum unter
Reply With Quote