31
redheadedrod
Re: Making Libraries of functions to be used in many modules? Action Ques? X2 and X3 related..

I am reviving this thread of a while ago to reengage in some communications with this idea. I have just completed my semester and other than some sports I will be getting involved with I plan to spend most of my summer on xoops and other computer projects. We have been kicking around different ideas for a while and I wanted to present an idea for this. I am hoping this is a little more developed and actually possible now than the ideas presented earlier.

I believe if we start moving our modules to an MVC style system and promote separation of methods and such as a way to reuse code I think this will work out well.

I will use a simple module such as xoops poll as an example for this. I will be making assumptions and not using any code review for this example since the idea is all I am trying to get across and won't realistically reflect on the actual module at all.

Currently you have this module and all of the code is written through out the module. The only consideration for separation are the display template since they are smarty templates. We can take this module and remove all functions that do any adjusting of data or any sort of database access and put these into a class. This class has any of the "global" variables in it that are needed by the module as well as all other functions. This class becomes the Model of the MVC structure.

All of the display stuff is done via smarty templates so those can easily reside in their own directory and nothing should be hard coded here. This becomes the View of the MVC structure.

Now the module its self should be simple to write since all of the work is done in the class that was written. We initiate an object of the class and use this to interact with the database and all of our other work. The module code now becomes the Controller section of the MVC structure.

This design then allows us to EASILY make use of the xoops poll module because all we need to do is call an instance of the class and we have access to any and all functions. So we can reuse this code in other modules that have a reason to access the poll code.

if a module needs to use more then one class because it is complicated then it could have a number of classes.

A real life example of this as likely mentioned earlier in this thread is a forum module. I believe CBB includes code for the xoops poll module so you can perform polls in a forum. Currently if you look at the cbb code it has a duplicate section for the xoops poll code. If you ever decide to update your xoops poll to something that isn't 100% compatible then the CBB forum MAY see the poll module is installed and try to use it but it will break. However if we used a class it would be as simple as making an instance of the class and using it directly. So then if the xoops poll module is updated the forum module can still use it without issues. In this example the forum module might make use of a forum class as well as the xoops poll class. Then if something else wanted to access the forum code it could easily as well.


32
redheadedrod
Re: Making Libraries of functions to be used in many modules? Action Ques? X2 and X3 related..

I didn't want to have a message that went on forever so here is another part to it...

I believe because these classes are intended to be shared among modules that they should exist in their own directory and each class needs to have a bare minimum structure to it. There was discussion previously about needing someone to keep track of versioning and such with this idea but I think I have come up with a solution that doesn't require anything like that.

Since these classes are intended to be for module use only I believe we could have a "class" directory inside the modules directory for these. This way they don't get confused with the framework stuff and they don't get confused with the core classes. And each class is in its own directory.

I have considered two different methods for keeping track of information for these. One consists of a class_version.php file that would be similar to the xoops_version.php files but I am not sure this is the best method.

The other method I have been considering is including some required functions and constants within the class. For the previously mentioned xoopspoll class you would have:
htdocs/modules/class/xoopspoll/
This would contain any of the files needed for the xoopspoll class. The main class would of course be in a file called xoopspoll.php




33
redheadedrod
Re: Making Libraries of functions to be used in many modules? Action Ques? X2 and X3 related..

I believe to make this work fully the module install script will need to be made aware of these library classes so they can check for them and install them correctly. You could in effect have a new module with a library class that contains totally different code as long as it was still compatible with the original code. As long as the class is backward compatible you could then just install this newer module and both the new module and the old module would work with the new code as long as the modules themselves used different names.

Any new modules should try to make use of an old library when possible. It also makes it much simpler to make conversion scripts as well when you have two different modules with similar functions and a newer one replaces the old one.


34
redheadedrod
Re: Making Libraries of functions to be used in many modules? Action Ques? X2 and X3 related..

The base level for a library class should have a defined minimum of attributes and methods defined within it. Here are some I am thinking of:

class xoopspoll
{
    const 
VERSION '1.2.3';
    const 
RELEASE_DATE '02/12/2013';
    const 
AUTHOR='Rodney Fulk';
    const 
AUTHOR_EMAIL='nospam@here.com';
    protected 
$mod;
    
    public function 
__construct($modsite ''
    {
          
$this.mod $mod;
    }
}


May have to make additions to this but the basic idea is the following.
The release date should be the release date of this version.
The author and email is of the official author of the official version.

The name of the module is passed to the constructor so that it can access the proper database. (Note this will allow for cloned modules to use the same code...)
This module name would be of the module you want to access the information for so it could be the name of the module running or another module. For xoopspoll you would call the class with the name xoopspoll.

In this case if you were using CBB and it was making use of the xoopspoll class so it could interface into the polls you would include the CBB class with the module name being CBB and you would also include the xoopspoll class with the module name of course being xoopspoll.

The optional site argument would be for potential multi site support.

The versioning portion is the touchy part of this class. There are 3 different portions to this version. The first portion would be the major portion. All classes of the same major portion would need to be compatible. So any future versions need to be backwards compatible throughout the series so that if you have a program using version 1.0 of a class it will still work with version 1.999 of the class as well. You would only go to 2.0 if the new version contains new functionality. Going from 1 to 2 would still be backwards compatible to the last version of the 1 branch but any replaced methods would be depreciated to be removed in a major version 3.

The mid portion would be the official step increases. They may add some functionality but none can be taken away and should be backward compatible.

The final portion would be the minor portion and would be the maintenance versions. Any minor adjustments or non official additions would be made in these versions.

The first two portions of the version could only be done by the official writer. To release an official newer version the original author would need to make the additions and release the official new version. If the class has not been updated for more than 6 months or permission is given by the original author then someone else can release an "official" version. (Official modules can only be released by the core developers regardless.)

If someone does not want to abide by the rules they can produce their own work but it must be a different name and the class must be a different name. It can be an extension of the official class if so desired as one way to get around this.

Hopefully this won't be much of an issue.

35
irmtfan
Re: Making Libraries of functions to be used in many modules? Action Ques? X2 and X3 related..
  • 2013/5/11 5:11

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


AFAIK, if a module follow the standard i wrote in this thread:
https://xoops.org/modules/newbb/viewtopic.php?post_id=353437
It would not be any issue for other modules to use its functions only with one instance:
$MODULE Module::getInstance();

which "Module" is the module dirname with uppercase of the first letter.
for example in userlog (with dirname = "userlog") you just need to have this in any other module:
$Userlog Userlog::getInstance();

then you have access to all functions and handlers and can use it with ease:
$Userlog->getHandler('log')->getCounts($criteria)

the above means you access to table mod_userlog_log so for any other standard module you just need to know the table name suffix.

all functions to work with database like "getCounts" can be found in XoopsObject class. so all modules have a unify interface functions.

even you can delete table rows or drop fields (and damage the userlog module) from any other module using that handler
$Userlog->getHandler('stats')->dropField("time_update");

In 2.6 it turns to a core helper class that makes usage of another module class/functions more simpler for module developers.
I show the way to write that helper for 2.5.5 modules in how to write standard module for xoops tutorial.
so instead of what you propose for a module class (Xoopspoll) we have this:
http://svn.code.sf.net/p/xoops/svn/XoopsModules/publisher/trunk/publisher/class/publisher.php
but you should know:
- one table in a module needs one class extend the XoopsObject Core class to work with its own table.
Im still reading this long topic. I will add my comments.

Login

Who's Online

154 user(s) are online (112 user(s) are browsing Support Forums)


Members: 0


Guests: 154


more...

Donat-O-Meter

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

Latest GitHub Commits