MODX3 Extras, backward compatability and build-script compatibility

Development
21

This is what I ended up with for MODX 3:

use MODX\Revolution\Error\modError;
/* ... */

/* Initialize $modx->error */
if (!$modx->services->has('error')) {
    $modx->services->add('error', new modError($modx));
}
$modx->error = $modx->services->get('error');
22

@jaredfhealy @markh @opengeek

I’m back here looking for help on ClassExtender. I can’t get it to run successfully in MODX 3.

These steps all return success:

// parse schema file and generate the class files
$this->generator->parseSchema($path, $this->modelPath); )

/* Add package */
$this->modx->addPackage($this->ce_package_name,
            $this->modelPath, $this->ce_table_prefix);

$manager = $this->modx->getManager();

When I get to $manager->createObjectContainer(‘userData’), it fails because it can’t instantiate the object. So the table is not created. The error is: core\vendor\xpdo\xpdo\src\xPDO\xPDO.php : 666) Could not load class: userData from mysql.userdata

In the schema:

<object class="extUser" extends="modUser">
...
<object class="userData" table="user_data" extends="xPDOSimpleObject">

In MODX 2 the two class files look like this (no namespace):

class extUser extends modUser {}

class userData extends xPDOSimpleObject {}

In MODX 3, I get this for the two class files:
namespace extendeduser;

namespace extendeduser;
class extUser extends \extendeduser\extUser

namespace extendeduser;
class userData extends \xPDOSimpleObject

MODX 2 metadata file:

$xpdo_meta_map = array (
  'modUser' => 
  array (
    0 => 'extUser',
  ),
  'xPDOSimpleObject' => 
  array (
    0 => 'userData',
  ),
);

$modx 3 metadata file:

$xpdo_meta_map = array (
    'modUser' => 
    array (
        0 => 'extendeduser\\extUser',
    ),
    'xPDOSimpleObject' => 
    array (
        0 => 'extendeduser\\userData',
    ),
);

In MODX 2, the two class files have an include statement to include the files listed above, the MODX 3 files don’t, so it’s possible that I’m supposed to set things up so the files can be autoloaded, but I suspect that there may be more serious problems.
I’ve created a test file that seems to expose the problem. It puts these in the $_POST array (these are the default values in the form):

$fields = array(
    'ce_package_name' => 'extendeduser',
    'ce_class' => 'modUser',
    'ce_parent_object' => 'modUser',
    'ce_table_prefix' => '_ext',
    'ce_table_name' => 'user_data',
    'ce_schema_tpl_name' => 'ExtUserSchema',
);

I can step through the createObjectContainer(‘userData’) method in the debugger. I can see where it fails, but so far I can’t see why.

Should the two schema files be different?

I’d like to make the extra run in both MODX 2 and MODX 3, but I’m wondering if that’s possible.

23

It’s possible, I’m sure. But you will definitely need to set up autoloading. And the classes in the schema should extend xPDO/Om/xPDOSimpleObject. All class references other than the object class attribute, that will be appended to the schema package (i.e. PHP namespace), will need to be fully qualified.

24

Keep in mind that package in xPDO 3.x is a namespace. The old-style packages from 2.x are supported only for loading legacy classes. You cannot build these classes in 3.x.

25

Thanks!

How can I set up autoloading for the two classes before createObjectContainer() runs so the method will use the autoloader?

26

Maybe this is answered somewhere already, but is this backwards compatibility temporarily? Or will this be continued in future releases? I have some CMP’s which I’ll partly have to rewrite if not.

27

Based on my own projects, I’d expect most build scripts targeting 2.x to keep working at least until MODX 3.3, which is when the BC layer (class aliases) are intended to be disabled by default. Fixing that would then require either opting in to load the BC layer again (adding a one-line include_once), or updating class names in your code.

We’re not going to keep MODX 2.x backwards compatibility around forever, but also aren’t in a rush, so the next time you update a component, just take half an hour extra to see if you’re ready to make it MODX3+ only and update class names.

Unless we start building and releasing much more quickly than we historically have, 3.3 would be 2024-ish, so that’s a fair bit of time to prepare.

3 Likes
28

I will be curious to see if the BC layer is removed in my lifetime. :wink:

1 Like
29

Hello everyone and my apologies for reopening this old topic

May i ask has anyone succeeded in getting Doodles working on Modx 3? I mean just the schema creation, model files creation, as well as basic queries in the back-end (create, select, delete…)?

I use modx since Evolution and I love it. On Modx 2 it was not so difficult to follow the tutorial or to use the Doodles extra. I have no IT degree at all but i always got Doodles working. However with modx 3 i cannot have tables created and simple queries working.

The “Developing and extra” doc is not up to date, which is really problematic. I assume many websites need to have additional tables to store custom data.

Per chance is there a doc or tutorial or working extra that i missed?

Any help appreciated

30

Doodles is notoriously difficult to get working.

You might find this helpful as an alternative.

1 Like
31

I made a series of videos on Youtube that shows the process (using the extra ExtraBuilder). Maybe this is helpful.

You can also use the MIGX extra to create custom tables. (Currently you have to load the package migx-3.0.1-beta2.transport.zip directly from Github to make it work in MODX 3.)

With MIGX creating a custom manager page is a lot easier, than writing your own controller/processors.

1 Like
32

Thank you everyone, my mistake sorry, I was not sure these resources were aimed at modx 3

Awesome reactivity as usual!

33

ClassExtender will make custom tables for you very easily.

A new version of the MyComponent extra development system is due (overdue, actually). It should be compatible with MODX 3.

1 Like