Quote:

Yes, absolutely.

I notice you are almost at post #100. Congratulations! Soon, you won't just be "popping in"!

This approach with __FILE__ seems good. The trouble with SCRIPT_FILENAME and a zillion other variations is that they are not very consistent between different platforms nor versions of PHP.

To other who may use this, note the use of '$pathparts[1]' and '$pathparts[3]'.

In module/abc/xoops_version.php, realpath(__FILE__) gives the full path to the file, explode splits into an array where each subdirectory is an array element, 'reverse' reverse it, so you have array('xoops_version.php', 'abc', 'module', etc...). Then $pathparts[1] takes 'abc', which is the desired module dirname.

In modules/abc/language/english/main.php, $pathparts is array('main.php', 'english', 'language', 'abc', 'modules', etc...), so $pathparts[3] now gives you the dirname.

So you just need to keep track of where the current file is within the module directory structure and adjust the $pathparts index accordingly.

An alternative approach, maybe more intuitive? maybe not?

modules/abc/xoops_version.php:

$pathparts = array_reverse(explode('/',dirname(__FILE__));
// use $pathparts[0];

moduels/abc/language/english/main.php:

$pathparts = array_reverse(explode('/',realpath(dirname(__FILE__) . '/../..')));
// still use $pathparts[0];

Or maybe use array_shift or array_pop etc... to just take the first/last element and maybe eliminate the need for array_reverse...

Phatjew, thanks for your note. (I didn't even keep track on the posting-count..)

Mvandam, your alternative approach were definately more intuitive. Perhaps thats the way to go? Can you benchmark your approach to mine?

However, as I promised in an erlier post, I've made a more consistant approach, which voids all of the problems described in erlier posts:

Use the following code in top of all the files where it's needed:


Note: _MI_ should be replaced by the appropriate string.
_MI_ = ModuleInfo. Used in xoops_version.php
_AM_ = AdMin. Used in all admin files.
_MD_ = Modules. Used in... eahh.. Modules.
etc...

The use it like this in xoops_version.php:


And like this in the language files:



And like this in the blocks and admin (and smarty, to keep consistancy!):



And finally to sum it all up, these variables are very handy in blocks, admin etc. too:



I've not been able to spot any problems, yet... But thats what you are here for!

Best regards,
Daigoro

Looking good Daigoro! You can use similar techniques also for accessing the module's database tables.

e.g. $sql = "SELECT title,body FROM " . $xoopsDB->prefix($ModuleDirname . "_articles");

where I've used '$ModuleDirname' instead of '$ModuleName' as I think it is more accurate.

However, several problems still remain... creating function and class names. Also, template files are currently named with the module-name in the filename. e.g. modules/news/templates/news_item.html. This is something you definitely could *not* generate dynamically, so cloning a module would require at minimum renaming the template files. (Possibly it will also require a search/replace in function names and class names.)

The more you can write a module dirname-independent, the easier to clone a module. We just have to watch that this doesn't have too much performance overhead. Very interesting work so far!

Quote:

Really? Several things occur to me:

1. For code inside a module (ie. NOT blocks, which are a special case), each file will have #include statements to get access to all of the module's functions and classes. Because these include statements use relative paths (or, at least, they should for what we are trying to do), each clone of the module will look only at its own implementation. If all of the SQL statements are written in the dynamic fashion described above, then there is no problem, and you don't have to do any search and replace or dynamic function names or anything like that. Please correct me if I am wrong here.

(Even if classes are defined globally, a page within one module should not be loading class definitions for another module, right? (blocks aside, of course, which screws eveything up.))

Obviously, blocks are a more difficult problem, as was described above, but every block's code is still within THAT module's directory, so using the file path everywhere in the code should still work, right? I'm not sure what I am missing here.

2. Templates. I agree that because of the way they are stored in the database, they probably need unique names for each clone. Somewhere in the documentation for installing the templates, there needs to be instructions that each of the template files need to be renamed appropriately. Then, using $VarPrefix or $ModuleName or something like that when referencing the templates should be enough. I like this solution because the less a user has to tweak a module to make it work as a clone, the better -- this involves no code change, just a file name change, which is something a non-coder can handle.

Quote:
And this is exactly the problem. Classes and functions *are* defined globally (this is how PHP works). The problem is multiple modules get (partially) loaded to display blocks, menus, search results, etc... You really have to have unique function and class names to avoid conflicts. The alternative is writing so all clones read the *exact* same files (not just the same contents in the same relative location, but the SAME file; otherwise 'include_once' won't work), all from a SINGLE shared directory. Not sure how you would do this in a cloneable way though.

Quote:
I agree, and this is probably how I would code a new module. However, keep in mind that the code is a little more complex (e.g. $varName, $moduleDirname all over the place) and a little slower by doing things this way.

Quote:

If all of the functions were encapsulated in classes, with $VarPrefix and/or $dirname as function paramterers wherever needed, then the classes themselves could be put in the main XOOPS classes directory, and not within individual modules.

Would this work?

It would work, but how would you add classes for your own modules? If they're already in a file, you can't append them to the file. If your module depends on some non-core classes, how can you insure they're atually available? This requires a central class library that will grow and grow, not making the system any faster.

Herko

Quote:

I guess that's the problem exactly. You'd have to manually copy your module's classes into the central class library (which already exists, right?). This, of course, means that if every module worked this way, that central class library would become unmanageably large.

One solution that I might go with right now is not to use classes at this point. I understand all the benefits of classes and object orientation (I'm a C++ programmer in real life), but it seems to me that it makes cloning a module just about impossible without a whole lot of search and replace in the code, which is always very dangerous if you are worried about stability. If all of the language variables and SQL calls in my module use the realpath(_FILE_) convention or something like it (as described above), there won't be any problems with having blocks from multiple clones on the same page.


But please tell me if anyone thinks this is a Really Bad Idea, and if it is, what direction we might take in the future to allow the development of modules that are fully clonable.

Mvandam,

You are right, $ModuleDirname is more correct.
I'll change to use it whereever possible.

Perhaps it would be possible to change the way templates are accessed?
Lets say the templates didn't contain the module name, but when the module was installed, the templates dir was automatically scanned for html files and had the modulename prefixed before they were installed in the database?
It'll require a change in the core, but it would help alot.

Another solusion could be to add a pre-installation script, which would rename the files in the template directory. Lets say the files are named modulename.templatename.html, then it would be easy to exchange the modulename before the first dot.
However, this would also require a core-change, as there are only a post-install hook available.

Needs more thinking. (I prefer the first, but the last is probably easier to implement)

Regards,
Daigoro