1
kaper
DB tables shared between modules - how to do?
  • 2013/4/5 8:36

  • kaper

  • Just popping in

  • Posts: 75

  • Since: 2003/4/26


I am planning to make a system for small business support. There would be a database of customers, store, documents (e.g. invoices) etc. I think about writing separate modules for each field of activity - one module for store management, another for issuing invoices, other for CRM rtc. However, every module will work on comman database: for example if I want to prepare an invoice then, apart form accessing invoices database, I also have to access customers and store database.

The concept of separate modules for separate tasks over common database will help make the system modular and thus easy to tailor / configure for a particular customer.

So the question: is there a preferred way to make tables accessible from multiple modules?

2
luciorota
Re: DB tables shared between modules - how to do?
  • 2013/4/5 9:44

  • luciorota

  • Module Developer

  • Posts: 216

  • Since: 2007/4/20


Module Handlers are useful for your task

e.g.
$errorHandler =& xoops_getModuleHandler('error''xhttperror');


more info here:
http://api.xoops.org/2.5.6/d4/d01/include_2functions_8php.html#ae72e9470c0a71f93625a661dfc64b34c

and also here:
http://www.slideshare.net/xoopsproject/oop-adventures-with-xoops

bye


3
Mamba
Re: DB tables shared between modules - how to do?
  • 2013/4/5 15:59

  • Mamba

  • Moderator

  • Posts: 11366

  • Since: 2004/4/23


Quote:
I am planning to make a system for small business support.

I am extremely interested in this, as this was the plan for me to do something similar, i.e. to have standard "business" modules like payment, invoicing, which would be then used to create a specific customer solutions.

AdsLight is already doing it by using the xPayment module for its payments.

This is part of our initiative to standardize our modules and utilize as much "standard building blocks (modules/extensions)", like ratings, captcha, etc. The Core Team is doing an awesome work on XOOPS 2.6.0, extracting common functionality and making extensions out from them.

So please take a look at XOOPS 2.6.0, and see how some of the extensions work, and also look and AdsLight and its use of xPayment, and then let's talk about doing something concrete out of this, that could be replicated and reused across many modules.
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

4
kaper
Re: DB tables shared between modules - how to do?
  • 2013/4/5 19:09

  • kaper

  • Just popping in

  • Posts: 75

  • Since: 2003/4/26


You mean inside module1, to use xoops_getmodulehandler(module2) to access tables managed by module2? So simple, indeed

5
zyspec
Re: DB tables shared between modules - how to do?
  • 2013/4/6 15:05

  • zyspec

  • Module Developer

  • Posts: 1095

  • Since: 2004/9/21


That's pretty much it... What you need to do is use

$m2ClassnameHandler =& xoops_getmodulehandler('classname''module2');


So you can access module 2 classes from within module1, provided module2 sets up classes using the standard XOOPS methods. For example in module 2 setup a class named Module2Classname() with a handler class named Module2ClassnameHandler().

I'd recommend you look at some of the recent BlueMove modules (look at the BlueMove Basic Module Pack) to see how to properly setup classes. Note that the filename and location are also important for this to work properly. So in this case you would place your class for module2 in './modules/module2/class/classname.php'

6
kaper
Re: DB tables shared between modules - how to do?
  • 2013/4/6 19:04

  • kaper

  • Just popping in

  • Posts: 75

  • Since: 2003/4/26


Thanx.
What about merging features (e.g. form elements) between modules?

Say I have one module including basic customer information (name, address) and another module for CRM (including notes about contacts). The database tables would look like this:
customers: cust_id, cust_name, cust_address
crm_notes: crm_note_id, crm_cust_id, crm_note_content
crm2cust: crm_note_id, cust_id // to link the two tables above

I assume that Customers is a basic module, and CRM is optional, that is I can use Customers module without having CRM installed, but to use CRM, Customers is mandatory.
Naturally I can add a CRM note from inside the the CRM module. But it would be useful to allow that also inside the Customers module: say I go to customer's data edition to change its address. Right after doing that it will be convinient to click "Add CRM note" to note time and reason of making that change.

So: is there a good way to put inside one module (A) a "plugin" from other module (B)? The plugin would define (or point to a definition) elements which would appear in module A and invoke module B actions. For example a plugin file in Customers module would add the "Add CRM note" button to customer data form.

7
zyspec
Re: DB tables shared between modules - how to do?
  • 2013/4/6 19:39

  • zyspec

  • Module Developer

  • Posts: 1095

  • Since: 2004/9/21


There's several ways to accomplish this. You can check within the Customers module to see if the CRM module is available and then display the "Add CRM note" button if it finds the CRM module. Of course you should check several things to make sure the user is allowed to add the CRM note. For example, you may want to check to make sure the module is installed and active, make sure the user has permission to add a CRM note, etc.

Once you're sure the user has the rights to add a CRM note then if they click the button you can take them to a form in the CRM module (passing it the cust_id) so you can then easily save the data into the crm_notes data table after entry in the form.

Not sure why you need the crm2cust table. Isn't the value in your cust_id (customers table) and crm_cust_id (crm_notes table) always the same?

8
redheadedrod
Re: DB tables shared between modules - how to do?

Quote:

zyspec wrote:

Not sure why you need the crm2cust table. Isn't the value in your cust_id (customers table) and crm_cust_id (crm_notes table) always the same?


Was going to point out the same thing.. Since the CRM has to have customer to exist it should be using the customer table for the ID.

The only issue with doing this at this time is there are not dependencies requirements built into xoops at this time. So you have to check each module for the presence of the other.

In other words you can remove the customer module without removing the crm module and your crm module would crash.

9
irmtfan
Re: DB tables shared between modules - how to do?
  • 2013/4/7 4:25

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


The first thing is very important to accomplish such a features, is writing new modules by using XOOPS API without any hard-code.
e.g.: you should create a class for each table and use "XoopsObject" and "XoopsPersistableObjectHandler" classes for all access to your module tables and avoid using "global $xoopsDB"
Now i cannot find any module in xoops 255 that didnt use $xoopsDB (except userlog). you can search $xoopsDB in any module to find how many hard-code access it have.

when you create a class for each table (e.g. here: customers, crm_notes) and define all needed functions to access database (It may be time consuming but the result is excellent) then sharing them between modules will be very easy using xoops_getmodulehandler.
from a long time ago module developers used profile and pm functionality so it is not a recent feature.

edit:
code example for class. e.g: mod_customers_customers table ( but i prefer to change it to mod_customers_info)
the standard for tables are mod_MODULENAME_TABLENAME

class CustomersCustomers extends XoopsObject
{
    
/**
     * constructor
     */
    
public function __construct()
    {
        
$this->initVar("cust_id"XOBJ_DTYPE_INTnullfalse);
        
$this->initVar("cust_name"XOBJ_DTYPE_TXTBOXnullfalse50);
        
$this->initVar("cust_address"XOBJ_DTYPE_TXTBOXnulltrue255);
    }
    
/**
     * @param string $method
     * @param array  $args
     *
     * @return mixed
     */
    
public function __call($method$args)
    {
        
$arg = isset($args[0]) ? $args[0] : null;
        return 
$this->getVar($method$arg);
    }
    
    static function &
getInstance()
    {
        static 
$instance false;
        if (!
$instance) {
            
$instance = new CustomersCustomers();
        }
        return 
$instance;
    }
    
// other functions here
}
class 
CustomersCustomersHandler extends XoopsPersistableObjectHandler
{
   
/**
     * @param null|object $db
     */
    
public function __construct(&$db)
    {
        
parent::__construct($db"mod_customers_customers"'CustomersCustomers'"cust_id""cust_name");
    }
    
// other functions here
}

10
Mamba
Re: DB tables shared between modules - how to do?
  • 2013/4/7 6:09

  • Mamba

  • Moderator

  • Posts: 11366

  • Since: 2004/4/23


Quote:
you should create a class for each table and use "XoopsObject" and "XoopsPersistableObjectHandler" classes for all access to your module tables and avoid using "global $xoopsDB"

The TDMCreate module's goal is to simplify such tasks, i.e. to create the right objects for each table. As it is getting better and better, I am using more and more in rewriting existing modules and converting them to XOOPS API.

I still have a lot to learn, and the module needs to get better, but it is already a huge help, and we all should appreciate the dedication of Timgno who keeps working on this, and the original TDM team that create this module.

The new modules created with TDMCreate from scratch, like the Hotel module, don't use $xoopsDB.

Please help us with testing and improving the TDMCreate module.
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

Login

Who's Online

198 user(s) are online (115 user(s) are browsing Support Forums)


Members: 0


Guests: 198


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