Multi-Instanced blocks.

[Albus]

First, I apologize should this have been discussed before. However, I feel the system needs to be altered so that a module may be used more than once, with different settings.

[mholtum]

Why not just create a second module with a custom template?

[Albus]

*We* can do that. Non-programmers would have no clue what you are talking about. And what if the template should stay the same? For example, let's say I create 10 pages (page=p1 page=p2 etc...) and I want to put the same "menu" block on each, multiple times, where the menu automatically generates a forum jump tree from a given point on down through all it's children. Ok, copying the php file is ok and eso is editing the sql, but shouldn't there be an easier way? Like giving each an "instance" name as well and some way of passing variables to it without having to duplicate the php file or template? Perhaps a simple textarea that is run through eval just before the php code for that module is run? Or perhaps a module system that uses two php files per module instead of one? One is the "runtime file" the other is read by the vbadmin thing when installing a new module instance, using the instance name you assign, and creates a datastore item for it's settings? Like say it has the following in the module init function:

$modVars = array(

array(
'name' => 'test',
'limit' => '10'
),

[more]

);

The vba admon thing could initialize any number of instances of a module and display the settings for each to be customized. Each module could have it's own settings independant of vba's.

[mholtum]

I know what you are saying. I have copied and renamed some of the php files in the modules dir and it worked that way.. but yes they add up.

Other than that I never gave it much thought.

[Albus]

I thought about this further and here is a very rudimentary look at it. Assuming I am writing a module named "custom"...

[modules/custom/install.xml]

Contains the modules xml stuff

[modules/custom/install.php]

<?php

function custom_version() {
// return this versions info ("1.0.0" or something...)
}

function custom_install() {
// perform the installation of templates, phrases, an options
}

function custom_uninstall(){
// perform the uninstallation of templates, phrases, an options
}

function custom_upgrade($current){
// test current version array values and upgrade/downgrade as required
}

?>

[modules/custom/module.php]

<?php

// $vba_module_options are defined and populated just before this instance is run
// and may these options may have different values than other instances...

if ($vba_module_options['show_detailed']) {
// do one thing
} else {
// do another
}

?>

The trick here is to not list module settings in the either the "page" editor or "default" settings screens. Keep page level settings separate from module settings. Then rewrite the module mantainance section so that it reads the module dirs, determines which have been installed, which haven't, which need upgrading, then compiles the list into a table and gives you the available actions as links. Now, once a module is installed, you should now be able to click on it, in order to set default settings 'for that module'. In the page editor you should then be able to 'add' modules (in other words, new pages are blank) and override the default settings there and assign the newly added module an instance name. In this way, the whole thing is automated, and allows for a single module/template to be used over and over, in multiples, with each instance having it's own option values.

Of course, a lot of vba code would need to be rewritten to make this work, but if it was done right, it would make like a lot easier on all of us.

Table structure (in part) would look like this:

page ---[pageid]--> page_module <--[moduleid]--- module

Because each row in page_module has a unique id, we can now assign specific values to it's options.

[Brian]

v2.0 makes this very easy. Select 'Copy' from a drop down list, change any options you wish, and hit save. :)

[Albus]

Fill me in then, does 2.0 allow modules to have module defines options? I.E. Not all modules have the SAME options?

[Brian]

Yes. If you copy (for example) your news module then all of the options will be copied and you will be able to specify a different setting for each option with each module.

[Albus]

wOOt :)