We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 9207 ☆ A M B ☆
    • 2,475 Posts
    Ok, I’m able to generate XML schema files now, either by hand or by modifying the code presented here:
    http://modxcms.com/forums/index.php?topic=40174.0

    I can follow along with the column data as it is represented in the XML, but I wanted to get some information on the other attributes there, specifically the package, baseClass, and defaultEngine.

    <model package="modx" baseClass="xPDOObject" platform="mysql" defaultEngine="MyISAM">
    	<object class="Samples" table="samples" extends="xPDOObject">



    • Under what circumstances would I use a different package name?
    • Will these XMl schema files always use the xPDOObject baseClass? Can anyone give me an example of when they wouldn’t?
    • It’s easy to manually change the defaultEngine in the XML file, but is there a way for the generator to detect that my custom database is using the InnoDB storage engine? I know it’s frowned upon, but it is possible to have MyISAM and InnoDB tables inside the same database. How do you override the engine on a "per-table" basis?

    Thanks. I’m working through creating some tutorials for this stuff.
      • 21257 MODX Staff
      • 730 Posts
      Hey Everett,

      Packages (and subpackages) are a way to logically and physically separate groups of class and map files. Classes in the "modx" package essentially "are" the MODx core model, and they exist physically in a certain place. If you’re designing a custom model which is not logically a part of the MODx core, say, an extension or 3PC, or a domain model for a particular project, then you can keep that model isolated by having it in it’s own package. Quip and Engage are two current example components where the model is given a custom package.

      The baseClass is going to be xPDOObject or something that extends it. The most commonly used example of an extended class is xPDOSimpleObject - which just pre-defines a primary key named ’id’ for you. If you are modeling a table with a PK named ’id’, and extend xPDOSimpleObject, you don’t need to define the ’id’ field your xPDO model schema. You might also extend xPDOObject to give it some other behavior, like I’ve done here http://github.com/netProphET/xPDO-Collection-Tools

      I can’t comment on the MySQL tables business, I don’t keep up on that stuff like I should ;-)
        Mike Schell
        Lead Developer, MODX Cloud
        Email: [email protected]
        GitHub: https://github.com/netProphET/
        Twitter: @mkschell