1
redheadedrod
Making a module clonable?

What is the proper way to make a module clonable?

I am imagining if you make a static label that is the module name and directory and use that static label through out the code then it is as simple as making sure the static label is changed to reflect the correct directory and module name as desired.

But I would like to hear from someone that has done this.

Rodney

2
pulapol
Re: Making a module clonable?
  • 2010/9/1 12:36

  • pulapol

  • Just popping in

  • Posts: 55

  • Since: 2008/4/6 1


hhttp://xoops.peak.ne.jp/md/d3forum/index.php?post_id=1500

good read

may i know what module you are working on mate?

3
pulapol
Re: Making a module clonable?
  • 2010/9/1 12:37

  • pulapol

  • Just popping in

  • Posts: 55

  • Since: 2008/4/6 1


check also the xnews module by dnsprosi

4
ghia
Re: Making a module clonable?
  • 2010/9/1 12:56

  • ghia

  • Community Support Member

  • Posts: 4953

  • Since: 2008/7/3 1


As you see in the FAQ for how to clone a (regular) module, some things differ between the original and the clone, as eg the module name, module directory and database tables.
A clonable module can be placed as second copy in an arbitrary directory and then assume this name and uses it in all references to directories and database tables. (Note: For the install, the module must generate an sql file with the required modulename prefix in the table names).
If the language files are not to be shared (include once from the base module) then they must also be generated to have prefixes in their definition names.
Some modules have a cloning system by having the additional directories in the same name plus a number.
The base for this awareness is programmed in xoops_version.php
You can check out some examples of clonable modules (Publisher, Lawsuit).

5
trabis
Re: Making a module clonable?
  • 2010/9/1 13:43

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


There are 2 options:
- Use same prefix(module dirname) for classes, functions, sql tables, global variables, files (templates)
- Use dynamic prefix based on the module directory.

In the first case, you have to use a search and replace program to make a clone module. Publisher has its own search and replace and you can clone module using administration interface(module logo is also created on the fly which is very nice, thanks to ghost module)

The second case you need to use eval() to create classes and functions names on the fly. Good thing is that you just need to rename the module folder before install, bad thing is that your editor will not be able to use syntax highlight, cross referring, auto suggestion, etc. Since template files must be prefixed, some modules using this method provide a set of extra templates. The ones that don't, probably are not clonable, just renamable.

6
redheadedrod
Re: Making a module clonable?

I am not working on any current modules that this would come into play but I am asking so I better understand the concept so I am able to better program modules with this in mind.

I was actually looking more for "renamable" then a true clone. I miss said what I meant but you pretty much answered the question nonetheless... (if its clonable it is also renamable)

If I am understanding what you are saying is that you build the structure of the module in a manner that makes it easy to change the code so it will work no mater the name of the module or directory. Then you make install scripts that modify the code during the install to make it work correctly as intended. (Or you can manually change the code with a program such as notepad++ and just do a simple find replace.)

Guessing at this point you couldn't just make a file like the language constructs where it has constants that you then use in your code. Then if you want to clone the module you just have to change this "constants" file to make things work right.

I did not consider the classes and functions but I can see where they might clash if you have multiple functions/classes of the same name loaded up. And I am guessing if you use something like "#include once" that wouldn't fix it either since they physically would be separate files.

Sounds like for me to save in duplicate code it would be best to have a main module be "renamable" and have "daughter" modules that would work like the cloning. The "daughter" modules would be clonable but require the main module to be loaded to operate. Thus the "daughter" module would be quite lite and only require the things that make it work separately. Instead of having 2 or more copies of the same module and copies of the same code.

Although in this method if you remove the main module you would have to have a way to preserve the "daughter" module. Duplicating all the code of course would make any of the modules work regardless of which is removed or added.

Hope that all made sense.. Just want to understand the concepts before I go diving into anything.

Rodney

Login

Who's Online

288 user(s) are online (197 user(s) are browsing Support Forums)


Members: 0


Guests: 288


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