21
redheadedrod
Re: SmartClone 1.10 Beta 1 ready for testing

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.


22
irmtfan
Re: SmartClone 1.10 Beta 1 ready for testing
  • 2013/5/6 2:15

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


@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.

23
redheadedrod
Re: SmartClone 1.10 Beta 1 ready for testing

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.


24
Mamba
Re: SmartClone 1.10 Beta 1 ready for testing
  • 2013/5/6 8:37

  • Mamba

  • Moderator

  • Posts: 11366

  • Since: 2004/4/23


Quote:
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.

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.
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

25
redheadedrod
Re: SmartClone 1.10 Beta 1 ready for testing

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.

26
irmtfan
Re: SmartClone 1.10 Beta 1 ready for testing
  • 2013/5/6 10:30

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


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:
<?php

if( ! defined'XOOPS_TRUST_PATH' ) ) die( 'set XOOPS_TRUST_PATH into mainfile.php' ) ;

$mydirname basenamedirname__FILE__ ) ) ;
$mydirpath dirname__FILE__ ) ;
require 
$mydirpath.'/mytrustdirname.php' // set $mytrustdirname

require XOOPS_TRUST_PATH.'/modules/'.$mytrustdirname.'/xoops_version.php' ;

?>
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
// Alias of XOOPS_PATH, for compatibility, temporary solution
    
define("XOOPS_TRUST_PATH"XOOPS_PATH);
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.

27
irmtfan
Re: SmartClone 1.10 Beta 1 ready for testing
  • 2013/5/8 5:43

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


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

SmartObject is not in the svn.

Quote:

Any Clone system (module) should evaluate and filter $dirname before cloning.

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:
$func "xoops_module_pre_install_{$dirname}";


with this:
$func "xoops_module_pre_install_{$dirname}";
        
$func function_exists($func) ? $func "xoops_module_pre_install_module";


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:
function xoops_module_pre_install_module(&$module)
{
}
function 
xoops_module_install_module(&$module)
{
}


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.
// Tables created by sql file (without prefix!)
$i 0;
$modversion['tables'][$i] = $modversion['dirname'] . '_log';

$i++;
$modversion['tables'][$i] = $modversion['dirname'] . '_set';

$i++;
$modversion['tables'][$i] = $modversion['dirname'] . '_stats';

28
Mamba
Re: SmartClone 1.10 Beta 1 ready for testing
  • 2013/5/8 6:17

  • Mamba

  • Moderator

  • Posts: 11366

  • Since: 2004/4/23


Quote:
SmartObject is not in the svn.

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

You can also download the SmartObject 1.11 Beta 2
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

29
zyspec
Re: SmartClone 1.10 Beta 1 ready for testing
  • 2013/5/8 19:45

  • zyspec

  • Module Developer

  • Posts: 1095

  • Since: 2004/9/21


@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:

eval( 'class ' ucfirst($dirname) . 'Category extends MymoduleCategory_base
        {
//... code here
        }

        class ' 
ucfirst($dirname) . 'CategoryHandler extends MymoduleCategoryHandler_base
        {
//... code here
        }
    ' 
) ;


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:

class  ucfirst($dirname) . "Category"
        
{
        }

class 
ucfirst($dirname) . "CategoryHandler"
        
{
        }

30
Mamba
Re: SmartClone 1.10 Beta 1 ready for testing
  • 2013/5/8 21:42

  • Mamba

  • Moderator

  • Posts: 11366

  • Since: 2004/4/23


Interesting discussion about "using eval() without using eval()"
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

Login

Who's Online

218 user(s) are online (130 user(s) are browsing Support Forums)


Members: 0


Guests: 218


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Mar 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits