I would like to look into this more when I have the chance but when I was talking about splitting a module apart for MVC type development it would easily be developed into something to allow easy cloning.

I believe this is the same sort of thing you are talking about with the GIJOE cloaning system.

@zyspec:
As you can see i just show the eval function to manipulate the "xoops_module_pre_install_" but didnt talk about $dirname.
IMO What you described is not an eval issue.
Any Clone system (module) should evaluate and filter $dirname before cloning.
I dont see any evaluation in SmartClone. so issues with $dirname = 1000 or 2000 will be in SmartClone too. Therefor IMO it is not an eval issue.

I am wondering if this would work... It is so simple that I am assuming someone else would have thought of it before me if it will work.

You take a normal module and rewrite it so that the module name is a variable and is pulled from the $dirname value. All database access then is then done using this value. You of course would have to include the xoops_version.php file to gain this value or if you only need this value and nothing else from the xoops_version.php file you could have a specific file that contains only this value to be set. The code that includes the $dirname checks to make sure the $dirname is not already assigned before including this file.

We then build a separate directory that allows us to clone this module by simply renaming this simple directory to the name we want and we are done. Inside this would be the necessary xoops_version.php file along with the simple main php file that first loads the proper $dirname and then includes the file from the main module code. This would require that the main module reside in a specific place but should allow you to clone this module an unlimited number of times. You wouldn't even need to actually install the original module to make this work. You just copy both the module and the clone and install just the clone and you are all set.

To allow for different templates and different language files those may need to also be included in the clone directory and the code written with this in mind. I can't imagine anything else though that would need to be copied to the clone directory.

If this would work you could reuse the same code in multiple clones of the same module. It would just load the data from the database table that is related to the directory name for that copy of the module.

Quote:
That's pretty much how the D3 modules are built using the method by GIJoe.

You can try the Pico module developed by GIJoe. I think, this was the most recent D3 module developed by him.

I have just updated it to XOOPS 2.5.6 GUI, and while there is still work to do (like fixing the editor, and fixing the help file link), you can already test it, by copying the /modules/pico folder to something else, and installing it.

Ok thanks.. I will look at this this week after I get my finals done. I won't spend much time on it though at this point.

yes. IMO the D3 is the best way for cloning and it has many other benefits. if you look into D3 modules you just can see a mask in all front side files like this: XOOPS_TRUST_PATH is XOOPS_PATH = htdocs/xoops256/xoops_lib popularity of D3 modules and especially "protector" is the only reason that we still have this line in XOOPS mainfile.php Honestly D3 modules was not supported by previous XOOPS core developers and core team for ages and I dont see any support from current XOOPS core developers too. ( So if module developers know core team will support it they can write modules in D3 way) The only possible reason i can imagine for not using D3 is that the end user have to upload one module in 2 locations: 1- the main module (parent) in xoops_lib directory 2- the clone or colnes (child or childs) in ROOT/modules directory and maybe somebody think it is not user friendly. but I dont see anybody even very basic end users who have problems with this. D3 has many other benefits: - User just need to upload the main module for any update and all childs will be updated. - Main module is out of root so it would be more secure.

An important note:
You must install "SmartObject" before installing SmartClone.

SmartObject is not in the svn.

Quote:
After more thoughts it seems it is better to be filtered by the XOOPS core before pre install fucnction.
Because core should not allow a bad dirname like 1000 just like a bad user name and ...

Also I repeat, the bad dirname selection for cloned module is not an eval bug. with SmartClone you can create a module with dirname = 1000 and break your website.

I still cannot see any solution other than using eval. It seems namespace cannot help us.
You have to use eval at least one time to manipulate the pre install function or even pre install trigger.
OR
Xoops core should change this line:


with this:


because at one time there is just one function and i cannot see any reason to add $dirname to the name of the pre install function.
So these are working good:


And in D3 way you still have to use eval a few times. but in D3 the main module (contain eval) is out of the root.

Uninstall is not an issue because xoops will get the table names from xoops_version.php and you can define them like this.

Quote:
Ooops, sorry! I've added it to SVN.

You can also download the SmartObject 1.11 Beta 2

@irmtfan

The problem isn't function names, that's pretty easy to work around. The real problem is that you cannot dynamically create a class name without using 'eval'.

So eval has historically been used to do something like the following:



Using this method we can use the XOOPS API to instantiate the class, and methods.

This is required since the following isn't valid in PHP:

Interesting discussion about "using eval() without using eval()"