61
Ok. Today i finally finish the xoops_version.php tutorial.
I add the following to the first post:
Quote:
Also I remove the magic function __call
And I add a brief statement to guide using another table/handler in one handler by using the module helper class. (eg: join purposes)
Quote:
@bumciach:
AFAIK developers should avoid JOIN as much as possible.
But anyway i add the above tutorial.
I am sure 2 simple queries is better than one JOIN.
but I am not sure about that when tables are more than 2 like 3, 4, 5 or more.
somebody with more information could tell us.
Quote:
Then it will not help you to reduce queries.*/
I add the following to the first post:
Quote:
3-1-6- search functionality:// Search
$modversion['hasSearch'] = 1;
$modversion['search']['file'] = "include/search.inc.php";
$modversion['search']['func'] = "publisher_search";
- The above is for search functionality:
It is better to write the 'func' name without $dirname to avoid hard-code:$modversion['search']['func'] = $modversion["dirname"] . "_search";
You can find more information about xoops search system in this post:
https://xoops.org/modules/newbb/viewtopic.php?post_id=349697#forumpost349697
3-1-7- module links in mainmenu block:// Menu
$modversion['hasMain'] = 1;
- shows your module has functionality in user side (in modules/MODULE/*.*)
It will show a link of your module in xoops 'mainmenu' block which show modules/MODULE/index.php page.global $xoopsModule;
if (is_object($xoopsModule) && $xoopsModule->getVar('dirname') == $modversion['dirname']) {
global $xoopsModuleConfig, $xoopsUser;
$isAdmin = false;
if (is_object($xoopsUser)) {
$isAdmin = $xoopsUser->isAdmin($xoopsModule->getVar('mid'));
}
// Add the Submit new item button
$allowsubmit = (isset($xoopsModuleConfig['perm_submit']) && $xoopsModuleConfig['perm_submit'] == 1) ? true : false;
$anonpost = (isset($xoopsModuleConfig['permissions_anon_post']) && $xoopsModuleConfig['permissions_anon_post'] == 1) ? true : false;
if ($isAdmin || ($allowsubmit && (is_object($xoopsUser) || $anonpost))) {
$modversion['sub'][1]['name'] = _MI_PUBLISHER_SUB_SMNAME1;
$modversion['sub'][1]['url'] = "submit.php?op=add";
}
// Add the Search button
$allowsearch = (isset($xoopsModuleConfig['perm_search']) && $xoopsModuleConfig['perm_search'] == 1) ? true : false;
if ($allowsearch) {
$modversion['sub'][2]['name'] = _MI_PUBLISHER_SUB_SMNAME3;
$modversion['sub'][2]['url'] = "search.php";
}
}
// Add the Archive button
$modversion['sub'][3]['name'] = _MI_PUBLISHER_SUB_ARCHIVE;
$modversion['sub'][3]['url'] = "archive.php";
- show sub links in the 'mainmenu' block.
As you can see you can prevent some users to some sub links like submit.php
3-1-8- module blocks:
If your module has a block you should define them here.$modversion['blocks'][$i]['file'] = "views.php";
$modversion['blocks'][$i]['name'] = _MI_USERLOG_BLOCK_VIEWS;
$modversion['blocks'][$i]['description'] = _MI_USERLOG_BLOCK_VIEWS_DSC;
$modversion['blocks'][$i]['show_func'] = $modversion['dirname'] . "_views_show";
$modversion['blocks'][$i]['edit_func'] = $modversion['dirname'] . "_views_edit";
$modversion['blocks'][$i]['options'] = "10|0|1|-1|0|count|DESC";
$modversion['blocks'][$i]['template'] = $modversion['dirname'] . "_block_views.html";
- show that this module has block. you can see we can avoid hard-coded $dirname.
- The file for block functions (show_func and edit_func) will be located in modules/MODULE/blocks
eg: modules/MODULE/blocks/views.php
- show_func: is the function that will be parsed when the block is visible.
- edit_func: is the function that just add a form in Blocks Administration (modules/system/admin.php?fct=blocksadmin&op=edit&bid=BLOCK_ID) for 'options' field.
a module block may not have edit_func if it dont need any extra options.
- options: are default options only will be stored in module install. (Note: So in upgrade they will not be changed in database if you change them here!!!)
- template: the template for this block located in modules/MODULE/templates/blocks
eg: modules/MODULE/templates/blocks/userlog_block_views.html
3-1-9- module templates:
Your module should use templates for user and admin side.// Templates - if you dont define 'type' it will be 'module' | '' -> templates
$i = 0;
$modversion['templates'][$i]['file'] = $modversion['dirname'] . '_admin_sets.html';
$modversion['templates'][$i]['type'] = 'admin'; // $type = 'blocks' -> templates/blocks , 'admin' -> templates/admin , 'module' | '' -> templates
$modversion['templates'][$i]['description'] = 'list of userlog setting';
- Templates of your module will show a nice and formatted data in user side.
- Try always use one template for one page/section of your module. More templates means less hard-code.
- Note that you should avoid any direct php output like echo, print_r and ...
- Template types are: 'module' (default), 'admin', 'blocks' (if you dont define it will be 'module')
- In the current xoops 2.5.6 'description' is not used anywhere so you dont need to add a language definition.
3-1-10- module configurations:
Xoops core use 3 tables to save core and module configs:
_config
_configcategory
_configoption
So you dont need to have extra tables for your module configurations.
These tables used for storing module and core configs in database.
configs can be changed in admin > Preferences > MODULE:
xoops256/modules/system/admin.php?fct=preferences&op=showmod&mod=MID
and configs are in modules/MODULE/xoops_version.php
example:$i=0;
$modversion['config'][$i]['name'] = 'status';
$modversion['config'][$i]['title'] = '_MI_USERLOG_STATUS';
$modversion['config'][$i]['description'] = '_MI_USERLOG_STATUS_DSC';
$modversion['config'][$i]['formtype'] = 'select';
$modversion['config'][$i]['valuetype'] = 'int';
$modversion['config'][$i]['default'] = 1;
$modversion['config'][$i]['options'] = array(_MI_USERLOG_ACTIVE => 1, _MI_USERLOG_IDLE => 0);
$i++;
$modversion['config'][$i]['name'] = 'postlog';
$modversion['config'][$i]['title'] = '_MI_USERLOG_POSTLOG';
$modversion['config'][$i]['description'] = '_MI_USERLOG_POSTLOG_DSC';
$modversion['config'][$i]['formtype'] = 'yesno';
$modversion['config'][$i]['valuetype'] = 'int';
$modversion['config'][$i]['default'] = 1;
$modversion['config'][$i]['options'] = array();
_config table:
the below information will be stored in config table:
conf_id: auto generate id
conf_modid: module id
conf_catid: 0 not used in 2.5x series but reserve for 2.6
conf_name: $modversion['config'][$i]['name']
conf_title: $modversion['config'][$i]['title']
conf_value: The value selected by user from $modversion['config'][$i]['options']. The default is: $modversion['config'][$i]['default'] which will be stored once the module is installed.
conf_desc: $modversion['config'][$i]['description']
conf_formtype: $modversion['config'][$i]['formtype']
conf_valuetype: $modversion['config'][$i]['valuetype']
conf_order: $i : number of config in the $modversion['config'] array
A side note about changing conf_value:
the conf_value will be changed only by:
a - install a fresh module which $modversion['config'][$i]['default'] will be stored(as i described above).
b - select by user (as i described above)
c - In update when formtype or valuetype was changed in xoops_version.php $modversion['config'][$i]['default'] will be stored.
A developer may decide to change the value by this trick!!!
_configcategory table:
In 2.5.x only used by core and not used for modules. reserve for xoops 2.6
_configoption table:
information comes from $modversion['config'][$i]['options'] will be stored in this table.
if empty($modversion['config'][$i]['options']) => nothing will be stored in this table.
As an example for this option:$modversion['config'][$i]['options'] = array(_MI_USERLOG_ACTIVE => 1, _MI_USERLOG_IDLE => 0);
Below information will be stored:
confop_id : auto generate option id
confop_name: _MI_USERLOG_ACTIVE (will be parsed to user own language)
confop_value: 1
conf_id: the linked id in config table.
Note: options only will be stored in install and update process.
== END OF xoops_version.php ==
Also I remove the magic function __call
And I add a brief statement to guide using another table/handler in one handler by using the module helper class. (eg: join purposes)
Quote:
As you can see we have an instance of publisher helper object to use it anywhere we need that helper.
for example to access another table in this handler. (eg: in joining purposes)$this->publisher->getHandler('item')->table
means publisher_items table.
@bumciach:
AFAIK developers should avoid JOIN as much as possible.
But anyway i add the above tutorial.
I am sure 2 simple queries is better than one JOIN.
but I am not sure about that when tables are more than 2 like 3, 4, 5 or more.
somebody with more information could tell us.
Quote:
I mean add variable initialized for the object (mymoduleArticles) not to add field into table (articles) in database.
Then it will not help you to reduce queries.*/
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
