91
@zyspec:
I dont need to use eval for class and function naming.
I just need to have one reliable and consistent "xoops_module_pre_install_module" function or class and in this function i will change all table names and all class/ function names just like SmartClone do it for any module. (I will use the smartclone class)
In other words "xoops_module_pre_install_module" will be my embedded SmartClone in the module.
Also I think I need to use one more eval for "xoops_module_update_$dirname" to check and do the cloning and let user update the module with ease.
as i said before i dont need to do anything for ""xoops_module_uninstall_$dirname" because Core will drop my tables.
but In my idea with the current clone system the only problem is every clone is one separate module and all class and functions will be cloned. (but in D3 way all clones will use class and functions from the parent)
I still cannot find any reason why Xoops Core developers defined install/update/uninstall functions with dirname?
dirname is not needed because as i said before at one time only one module is Oninstall,Onupdate or Onuninstall.
so one fix function like "xoops_module_pre_install_module" or "xoops_module_update_module" will do the job perfectly.
@Mamba:
I am not good at php but i think we cannot avoid eval with that trick.
Edit: I will update "how to write standard module" tutorial with my new findings:
1- standard module should not have any file name contain the dirname.
a common mistake in all modules is using dirname as a prefix for all templates. It is not needed
so instead of templates/newbb_thread.html we can use templates/module_thread.html or any desired name.
2- standard module should not have any hard-coded dirname in places we can use a variable for it eg:
- block functions:
- table names:
- handler table name:
and any other possible places.
I dont need to use eval for class and function naming.
I just need to have one reliable and consistent "xoops_module_pre_install_module" function or class and in this function i will change all table names and all class/ function names just like SmartClone do it for any module. (I will use the smartclone class)
In other words "xoops_module_pre_install_module" will be my embedded SmartClone in the module.
Also I think I need to use one more eval for "xoops_module_update_$dirname" to check and do the cloning and let user update the module with ease.
as i said before i dont need to do anything for ""xoops_module_uninstall_$dirname" because Core will drop my tables.
but In my idea with the current clone system the only problem is every clone is one separate module and all class and functions will be cloned. (but in D3 way all clones will use class and functions from the parent)
I still cannot find any reason why Xoops Core developers defined install/update/uninstall functions with dirname?
dirname is not needed because as i said before at one time only one module is Oninstall,Onupdate or Onuninstall.
so one fix function like "xoops_module_pre_install_module" or "xoops_module_update_module" will do the job perfectly.
@Mamba:
I am not good at php but i think we cannot avoid eval with that trick.
Edit: I will update "how to write standard module" tutorial with my new findings:
1- standard module should not have any file name contain the dirname.
a common mistake in all modules is using dirname as a prefix for all templates. It is not needed
so instead of templates/newbb_thread.html we can use templates/module_thread.html or any desired name.
2- standard module should not have any hard-coded dirname in places we can use a variable for it eg:
- block functions:
$modversion['blocks'][$i]['show_func'] = $modversion['dirname'] . "_views_show";
$modversion['blocks'][$i]['edit_func'] = $modversion['dirname'] . "_views_edit";
- table names:
$modversion['tables'][$i] = $modversion['dirname'] . '_log';
- handler table name:
public function __construct(&$db)
{
$this->userlog = Userlog::getInstance();
parent::__construct($db, USERLOG_DIRNAME . "_log", 'UserlogLog', "log_id", "log_time");
}
and any other possible places.
Ready for Romance
First Persian Harry Potter Site(English added) | Persian Support Site | Xoops Persian Project
First Persian Harry Potter Site(English added) | Persian Support Site | Xoops Persian Project
)
Of course it is not acceptable for me and i think it is not acceptable for anybody.
you can find yourself the "ASC LIMIT 0, 200" which is hard-coded in XOOPS256|Xoops26/class/xoopsform/formselectuser.php:
