41
Herko
Re: XOOPS Dev Team: Would it be hard to propagate module name in all reference to the module?
  • 2004/3/23 16:17

  • Herko

  • XOOPS is my life!

  • Posts: 4238

  • Since: 2002/2/4 1


We'll make 'clonable modules' possible for XOOPS3, but for XOOPS2, it's a bit much work at the moment. And cloning modules is good, but isn't it the same as having multiple organisable instances of modules running? And that requires only adding an extra field to the modules, a new unique ID by which you can groups your content items from that particular module, right? Sort of like categories, but a little different.

Herko

42
Daigoro
Re: XOOPS Dev Team: Would it be hard to propagate module name in all reference to the module?
  • 2004/3/24 21:56

  • Daigoro

  • Quite a regular

  • Posts: 223

  • Since: 2003/7/3 2


Herko,
It's nice it's scheduled for Xoops3, but for Xoops2 it should be possible to create something relative simple.
I've found a way to change filenames during install (small hack, but it might be permanent later). I've not yet propperly implemented it. This leaves the problem with potential functions and classes disturbing each other. I have an idear about how to fix it, but I've not yet looked into that code wise, but I'm sure a clever solusion can be found.
I'll be back with more sometime later...

Regards,
Daigoro

43
phatjew
Re: XOOPS Dev Team: Would it be hard to propagate module name in all reference to the module?
  • 2004/3/25 17:32

  • phatjew

  • Just popping in

  • Posts: 56

  • Since: 2003/10/8


Quote:

Herko Coomans wrote:
And cloning modules is good, but isn't it the same as having multiple organisable instances of modules running? And that requires only adding an extra field to the modules, a new unique ID by which you can groups your content items from that particular module, right? Sort of like categories, but a little different.


That's true, if you want the modules to be pretty much identical. My idea with creating a clone is that the module I am writing has a BUNCH of configuration options, including what fields to display, what fields to make searchable, what the module-specific categories of content are, etc. Not to mention templates, if you wanted them to be different for each instance of the module.

I have this grand vision of being able to use this module for all kinds of different content on the same site. I'll hopefully be releasing it soon (within a month?), and you'll be able to see what I mean.

44
mvandam
Re: XOOPS Dev Team: Would it be hard to propagate module name in all reference to the module?
  • 2004/3/25 21:03

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


Quote:

That's true, if you want the modules to be pretty much identical. My idea with creating a clone is that the module I am writing has a BUNCH of configuration options, including what fields to display, what fields to make searchable, what the module-specific categories of content are, etc. Not to mention templates, if you wanted them to be different for each instance of the module.

This is a very good point. Whatever clonability system is used later in XOOPS 2 (or in XOOPS 3), it should basically allow the flexibility as if it was a completely separate module (and maybe it will be), rather than just be an enhanced category system. This means independent config options, independent templates, independent search?, etc.

One common use may be to display different content to different groups of users and each group of users should not be aware at all of the existence of the other clone of the module. What are other uses envisioned for cloned modules? (a) Different 'look' for different categories of news etc; (b) Maybe supporting different languages... one news clone in english; one in another language; (c) Giving modules different names... i.e. have a 'News' section using the news module and have an 'Announcements' section using a clone of the news module. I'm sure there are many other reasons? Maybe identifying some of the common reasons for wanting cloneable modules will help to design such a system?

45
krayc
Re: XOOPS Dev Team: Would it be hard to propagate module name in all reference to the module?
  • 2004/3/26 13:18

  • krayc

  • Not too shy to talk

  • Posts: 107

  • Since: 2004/2/17


Quote:
phatjew wrote: I have this grand vision of being able to use this module for all kinds of different content on the same site. I'll hopefully be releasing it soon (within a month?), and you'll be able to see what I mean.


You go! Phatjew, obviously you have some XOOPs skills, that I have yet to acquire, but when I started this thread, that is what I had in mind.

I'd happy to test anything you have, and/or start documenting what you and others are learning from this thread.

krayc

46
MadFish
Re: XOOPS Dev Team: Would it be hard to propagate module name in all reference to the module?
  • 2004/3/26 14:34

  • MadFish

  • Friend of XOOPS

  • Posts: 1056

  • Since: 2003/9/27


Quote:
One common use may be to display different content to different groups of users and each group of users should not be aware at all of the existence of the other clone of the module. What are other uses envisioned for cloned modules? (a) Different 'look' for different categories of news etc; (b) Maybe supporting different languages... one news clone in english; one in another language; (c) Giving modules different names... i.e. have a 'News' section using the news module and have an 'Announcements' section using a clone of the news module. I'm sure there are many other reasons? Maybe identifying some of the common reasons for wanting cloneable modules will help to design such a syste


For me, one of the major attractions is the possibility of hosting a number of related sub-communities within the one site & database - whether it be on the basis of interest, language or whatever. I would love that !

47
phatjew
Re: XOOPS Dev Team: Would it be hard to propagate module name in all reference to the module?
  • 2004/3/26 15:37

  • phatjew

  • Just popping in

  • Posts: 56

  • Since: 2003/10/8


Quote:

krayc wrote:

I'd happy to test anything you have, and/or start documenting what you and others are learning from this thread.


Hey, I might just take you up on that offer. One of the reasons I haven't released the module yet is that I don't want to give something to the community that is incomplete and buggy. If there were people interested in beta testing a VERY HIGHLY CONFIGURABLE module that could be used for pretty much any kind of content, I could probably have something ready in a week or so (depending on how busy I am at "real" work).

48
Daigoro
Re: XOOPS Dev Team: Would it be hard to propagate module name in all reference to the module?
  • 2004/4/4 17:26

  • Daigoro

  • Quite a regular

  • Posts: 223

  • Since: 2003/7/3 2


Hi again everybody,

I've been pretty busy lately, so I haven't had much time to work on xoops-related things.
However, I had started to walk a path, and wanted to continue following it to the end ofthe road. With this update to my previous description (erlier in this thread), I think we are slowly reaching a point where Xoops2 will be able to have easy cloneable modules.

Previously I've introdused $ModuleDirName (shortly known as $ModuleName) and $VarPrefix and shown how to use those to make dynamically changeable language-constants, and to easier access files and URL's I've introdused $ModuleUrlPath and $ModuleRootPath.

Mvandam showed how to use the above to access the module's database tables.
I belive searching, notification and comments can be done the same way, but I've not looked into that yet. (Please let me know!)

Then phatjew mentioned the problem with blocks, function and class-names, which has to be different for each clone of the module, which made it even harder to make a fully cloneable module. I'm still not sure why function and class-names needs to be unique within the module except when they are dealing with blocks, but I'm sure you will be able to explain why to me, and to provide me with an example so I can see it fail with my own eyes.


Well, back to why I'm writing this.
I saw there were a problem with the functions related to blocks, and after many hours of thinking and a few hours of coding (actualy mostly looking the php manual) I've found this solusion:

From xoops_version.php, a block will have to be called like this:
// At the top of the file:
$pathparts explode("/"realpath(__FILE__));  // Get path to this file.
$ModuleDirName $pathparts[array_search('modules'$pathparts)+1]; // Extract module name from path.
$VarPrefix '_MI_'.strtoupper($ModuleDirName); // Prepare a prefix for the language constants.
// ***********
// More code goes here, detailed further down this text.
// ***********
//


// For each block:
$modversion['blocks'][1]['file'] = $ModuleDirName.'_block.php';
$modversion['blocks'][1]['name'] = constant($VarPrefix.'_BLOCK');
$modversion['blocks'][1]['description'] = 'Shows a block';
$modversion['blocks'][1]['show_func'] = 'b_'.$ModuleDirName.'_block1';      // Same as in the block
$modversion['blocks'][1]['edit_func']  = 'b_'.$ModuleDirName.'_block1_edit'// Same as in the block
$modversion['blocks'][1]['options'] = 'sofar|so|good';
$modversion['blocks'][1]['template'] = $ModuleDirName.'_test_block.html';


The way to actualy create dynamical function names are unfortuately rather ugly, but this is the only way I've found to make it work:

This goes into a file in your blocks dir, in this case: '/blocks/'.$ModuleDirName.'_test_block.html':
// At the top of the file:
$pathparts explode("/"realpath(__FILE__)); 
$ModuleDirName $pathparts[array_search('modules'$pathparts)+1];
include_once 
XOOPS_ROOT_PATH '/modules/'.$ModuleDirName.'/include/groupaccess.php';


// Code for show_func:
$bname1 'b_'.$ModuleDirName.'_block1';    // The name of the function. - Same as in the xoops_version.php
$bfunc1 sprintf(
   function %s($options) { 

      // Here goes your blocks code.

   } 
   '
$bname1
); 
eval(
$bfunc1); 

// Code for edit_func:
$bname2 'b_'.$ModuleDirName.'_block1_edit';    // The name of the function. - Same as in the xoops_version.php
$bfunc2 sprintf(
   function %s($options) { 

      // Here goes your blocks edit code.

   } 
   '
$bname2
); 
eval(
$bfunc2);


I'm fairly sure the above would work with classes, too, but I still haven't been looking into actualy creating classes, so those of you who has classes in your modules, please try it out, and post the results. Thanks.

Well.. Sofar, so good. This actualy works, but it does not actualy make the module cloneable, as there also are some problems with names of templates and block files, as they are expected to be unique to each module, so I had to make a fix for that, too.

My solusion, is to simply rename the files that needs to be renamed. So every time the xoops_version.php file is used, a check will be made to see if the directry name has changed since last time it was checked. To remember the name, I've created a file called the name of the directory the module is resident in, and ending with the extension .cfg (I know, not a good name, but it had to have a name).
Thus every time xoops_version.php is inwoked, it will check if the file with the current $ModuleDirName exixts. If not, it will delete all the .cfg files in the current dir name, then rename all files in a list of dirs after a special pattern, and finaly create a .cfg file with the current $ModuleDirName.

The script expects the files to be renamed to use underscores to separate the name parts, and that the first part of the name is the name of the moduledir. eg. mymodule_sub_display_vars.php or mymodule_display.html. The first part will be automatically changed to the name of the current moduledir.

Notice the line below, starting with $updatedirs. This line contains relative paths to dirs which should have it's files scanned and renamed - if they contain an underscore.

There might be a more clever solusion, but this is working

The following code should be inserted at the point indicated in the first code-block above.

$ModuleRootPath XOOPS_ROOT_PATH.'/modules/'.$ModuleDirName;

if (! 
file_exists($ModuleRootPath.'/'.$ModuleDirName.'.cfg')) { // Only execute if module has been moved.

   
$dir opendir($ModuleRootPath);             // Delete old .cfg file - if any exists.
   
while (false !== ($name readdir($dir))) { 
      if (
is_file($ModuleRootPath."/".$name)) { // Looking for files...
         
if (eregi('.cfg$'$name)) {          // ending with .cfg
            
unlink($ModuleRootPath."/".$name);  // ..to be deleted!
         
}
      }
   }
   
closedir($dir);

   
$updatedirs = array("blocks""templates""templates/admin""templates/blocks");
   
reset ($updatedirs);
   foreach (
$updatedirs as $subdir) {
      
$currentdir $ModuleRootPath.'/'.$subdir;
      
$dir opendir($currentdir);
      while (
false !== ($name readdir($dir))) { 
         if (
is_file($currentdir."/".$name)) {   // Looking for files...
            
$nameparts explode("_"$name);
            if (
count($nameparts)>1) {           // Filename must contain an underscore
               
$nameparts[0] = $ModuleDirName;
               
$newname implode("_"$nameparts);
               
rename ($currentdir.'/'.$name$currentdir.'/'.$newname);
            }
         }
      }
      
closedir($dir);
   }

   
$fd =fopen($ModuleRootPath.'/'.$ModuleDirName.'.cfg'"w");    // Make new .cfg file.
   
fwrite($fd$ModuleDirName);
   
fclose($fd);
}


The template descriptor in the xoops_version.php file, then becomes something like this:

$modversion['templates'][1]['file'] = $ModuleDirName.'_main.html';
$modversion['templates'][1]['description'] = 'The main module form';
$modversion['templates'][6]['file'] = 'admin/'.$ModuleDirName.'_admin_testmenu.html';
$modversion['templates'][6]['description'] = 'Test of smarty in admin..';


Easy, isn't it?

Now I'm just looking forward to hear your suggestions on how to improve the above.

Best regards,
Daigoro

49
GIJOE
Re: XOOPS Dev Team: Would it be hard to propagate module name in all reference to the module?
  • 2004/5/5 9:17

  • GIJOE

  • Quite a regular

  • Posts: 265

  • Since: 2003/8/13


I've found this thread now.

Since I have little skill of English, I'm sorry that I didnot read this thread.

In Japan, the coding technique to create "Duplicatable module" has already been well-known.

And two duplicatable modules has been released by now.
One is TinyContent-Duplicatable.
Another is myAlbum-P 2.70.

Quote:

Daigoro wrote:
// At the top of the file:
$pathparts explode("/"realpath(__FILE__));  // Get path to this file.


The code is not usable for Windows, because __FILE__ returns \ separated path.
Use dirname() instead.

Quote:
The way to actualy create dynamical function names are unfortuately rather ugly, but this is the only way I've found to make it work:

You have a good brain!
I did not hit the idea using eval() in that time.
minahito who also has a good brain teach me that.

eval() is also needed in search and notification.
But block is not necessary to use eval().
You can distinguish them by block's option ($options).

The skelton of language file is like this:
if( defined'FOR_XOOPS_LANG_CHECKER' ) || ! defined'(YOUR MODULE)_MB_LOADED') ) {
    
define'(YOUR MODULE)_MB_LOADED' ) ;
    
define"MB_..." "..." ) ;
    
define"MB_..." "..." ) ;
    
define"MB_..." "..." ) ;
}


The number of sql files and temlate files are needed same as the number of duplicatable.

50
Mithrandir
Re: XOOPS Dev Team: Would it be hard to propagate module name in all reference to the module?

Wouldn't it be possible to do things like this:

a) Have a single php file with just one item in it: $moduleDirName = "moduleDirName";
This file could then be included (include_once) in all the files needing the module's directory name (Classes and blocks)

b) Prepend $moduleDirName to all the necessary items in xoops_version.php (block and search functions, templates, notification/comment categories)

c) Prepend $moduleDirName to SQL queries and URL's etc.

d) Manually change the names of template files and block functions to reflect the new name (not all that many)

e) Manually change the .sql file to name the tables differently

AFAIK eval() is a very resource-intensive function and should be avoided wherever possible.

Login

Who's Online

445 user(s) are online (344 user(s) are browsing Support Forums)


Members: 0


Guests: 445


more...

Donat-O-Meter

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

Latest GitHub Commits