Some questions about extensions

[ploughguy]

Howdy,

I am updating to CubeCart 6 from 4.3.4.  It is complicated because my 4.3.4 installation is somewhat modified which is why I am still on 4.3.4.  However, I'm all grown up now and I don't want to make the same mistakes again.  I am developing my custom code as extensions.  This has several benefits, even if I don't share them.  Mainly, coding an extension means it will plug itself tidily into any new sandpit environments I create with no effort on my part.

However...

I am having trouble working out what is going on behind the curtains for the admin pages.  

By inspection, I have determined that the coding pattern is:

1. Add any new tables that do not already exist.
2. Add any new fields that do not already exist.
3. Instantiate a module with $module = new Module(__FILE__, $_GET['module'], 'admin/index.tpl', true);
4. Display the template with $page_content = $module->display();

Clearly there is a lot going on under the hood because the location of the template is not explicitly declared, and the global config is provided and saved automatically.  All the template has to do is flash up the configuration page, drawing values from a magically created $MODULE array then assign the results to an output array called "module" and the results are somehow magically saved.

This is fine provided (a) you don't want to initialise the config scalars and (b) you don't want to do anything dramatic such as initialise a table of config values.  Which, of course, I do.

The institutional IT guy in me desperately does not want to have to reverse-engineer all this to figure out how it works.  I have looked at a mess of extensions and none of them seem to do anything dramatic except SFWS_Product_Dimensions which does some pre-initializations, but when I copy and hack it just the tiniest bit, it does not work - my values to not get added to the global config and the initialisations are not persisted.

Is there any documentation on this anywhere?  I have been thrashing around intermittently for a couple of days and it is starting to really annoy men.  It is just too ghastly to think that everyone wanting to use this magnificent facility has to reverse engineer the entire thing before they become productive.

Thanks for your help,

Russ

[bsmither]

When the Module class is instantiated, the location of the admin skin template is presumed to be located where Module calculates the destination to be based on the first three arguments.

The Module class does a lot of the common heavy lifting, including accepting a plugin's settings values from the control page in admin, databasing them, repopulating the control page with those values, and making those values available to the rest of the plugin.

Sadly, a SDK does not (yet) exist.

Please ask your questions. Anything too specific, we can take to email.