Support Forums - XOOPS Web Application System

Subject:* <
Name/Email:* <
Message Icon:* <
Select* <
Message:* <	xx-Small x-Small Small Medium Large x-Large xx-Large Arial Courier Georgia Helvetica Impact Verdana Haettenschweiler Black Blue Brown Green Grey Orange Paper Purple Red White Yellow Click the Preview to see the content in action.
Options:* <	Enable Smiley Enable Xoops Code
Confirmation Code* <	7 - 3 = ? Input the result from the expression Maximum attempts you can try: 10
* <

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"; [/code] - 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. [code] $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"; [/code] - 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. [code] // 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'; [/code] - 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: [code] $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(); [/code] _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: [code] $modversion['config'][$i]['options'] = array(_MI_USERLOG_ACTIVE => 1, _MI_USERLOG_IDLE => 0); [/code] 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 == [/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] 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) [code] $this->publisher->getHandler('item')->table [/code] means publisher_items table. [/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] I mean add variable initialized for the object (mymoduleArticles) not to add field into table (articles) in database. [/quote] Then it will not help you to reduce queries.*/[/quote]" />