Custom tables in MODx Revolution

In this article we will sort the following questions:

1. Creating custom tables for MODx Revolution.
2. Generation of XML-schema and php-file-classes for xPDO.
3. Work with custom tables.

One of the biggest difficulties in switching from Evolution to Revolution is xPDO IMHO. After all, as it used to be simple: I climbed into a muscle through phpMyAdmin, created a label, and work with it, sending pure SQL queries through $ modx-> db.

Now, however, any changes in the database do not worry much about $ modx, except for a full drop of tables, etc. As interconnected xPDO and MODx (or rather $ modx), I wrote here .

I consider the difficulties in working with user tables in MODx Revolution to be a considerable obstacle for many programmers.

But in fact, everything is not so difficult.

The whole algorithm considered in three words:

1. Also through phpMyAdmin (or another convenient used tool) we create the tables we need
2. Using the code below, we generate the necessary xPDO files for operation.
3. Using the $ modx-> addPackage () method, we load our new class in the right place and we are already working with our tables through the methods $ modx-> getObject (), $ modx-> getCollection (), etc.

So, the code we need to generate files (Source here ):

<?php







/*******************************************************/



/* */



/*******************************************************/





// . $modx->addPackage()

<br>

$obj = 'program' ;





/*

. , .

, xPDO ,

, .

*/

<br>

$tablePrefix= 'modx_program_' ;





// , XML-



// $modx->addPackage();

<br>

$Path = dirname(__FILE__). '/model/' ;





// -

<br>

$Schema = $Path. '/' .$obj. '.mysql.schema.xml' ;





/*******************************************************/





<br>

// -

<br>

require_once dirname(dirname(dirname(__FILE__))). '/core/config/config.inc.php' ;





// MODx

<br>

include_once MODX_CORE_PATH . 'model/modx/modx.class.php' ;





// MODx

<br>

$modx= new modX();





// ,

<br>

// $modx->initialize('mgr');





//



//

<br>

$modx->setLogLevel(modX::LOG_LEVEL_INFO);

<br>

$modx->setLogTarget(XPDO_CLI_MODE ? 'ECHO' : 'HTML' );





// !!! !

<br>

// -

<br>

$modx->addPackage( 'transport.modPackageBuilder' , '' , false , true );





// (MySQL / MsSQL ..)

<br>

$manager = $modx->getManager();





// -

<br>

$generator = $manager->getGenerator();







// -XML

<br>

// /xpdo/om/mysql/xpdogenerator.class.php

<br>

// public function writeSchema($schemaFile, $package= '', $baseClass= '', $tablePrefix= '', $restrictPrefix= false)

<br>

// $tablePrefix - , , .

<br>

// $restrictPrefix - true,

<br>

$xml= $generator->writeSchema($Schema, $obj, 'xPDOObject' , $tablePrefix ,$restrictPrefix= true );





// (php) xml

<br>

$generator->parseSchema($Schema, $Path);



<br>

<br>

print "<br /><br />" ;



')

Fill this file with the server, assign the correct path to the MODx configuration, and the directories where the generated files will be created. Access the file through the browser. As a result, an xml file should be created in the specified folder, in which our tables and a php file will be described.

These files, if very necessary, can be moved to another folder where you decide to store your new Class. In the future, these files will always be needed to work with their tables.



Now you can work with your tables. In order to better understand the mechanism of xPDO interaction with the XML schema, as well as to understand what is written in the generator file, and what objects you get at the output, I quote my note on this issue. Honestly, at first without it was just no way ...

1. Connection of packages and execution of requests to the scheme

1.1 Selection of records from the table

The first thing to do is to figure out what is generally needed in order to refer to the scheme. To do this, examine the XML file.

Here is the main block of the scheme we created:

< model package ="testtbl" baseClass ="xPDOObject" platform ="mysql" defaultEngine ="MyISAM" version ="1.1" >

< object class ="Tbl" table ="tbl" extends ="xPDOObject" >



The most basic thing we need here is:

one.

< model package="testtbl"

we need the value of the package attribute to know which package we need to load. In this case, this is testtbl. Call the package like this:

$modx->addPackage( $package, $path, $prefix);

// !!! addPackage , , .

Consider the parameters carefully.

$ package . The name of the package. In our case, just testtbl

$ path . Path to the package directory (in which there is an XML file and a folder by the name of the Object, in which all PHP files)

$ prefix . If the prefix, which is different from the default prefix, was indicated when creating the scheme, then it is necessary to indicate it.



There is another little trick, how to accurately determine the required prefix.

Formula: $ prefix = $ fullTableName - $ tableName;

Here $ fullTableName is the full name of the database table to which we refer,

$ tableName - the value of the attribute table <object tag of our XML file



Execute the query:

$result = $modx->getCollection( 'Tbl' );

foreach ($result as $row){

print “<br />Next:”. $row-> get ('columnName');

}

1.2 Creating a new entry in the table

private static function testCreateRows(){



$pkg = 'testtbl' ;





$modx->addPackage( 'testtbl' , $Path , 'modx_kl_test' )) ;



$row = $modx->newObject( 'Tbl' );

$row->fromArray(array(

'id' => 5

));

$row->save();



return ;

}



It seems to be all. If anything is not clear, ask.