We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 27519
    • 275 Posts
    Hi,

    I see the following constructor in my persistent domain classes:

        public function __construct(& $xpdo) {
            parent :: __construct($xpdo);
        }
    


    Does this mean that I can access database functions with $this->xpdo->someDbFunction() (like getCollection, newQuery etc.)?

    For transient domain objects that need access to the DB I use a constructor like:

        public function __construct(& $modx) {
            $this->mgr = $modx;
        }
    


    Although this works, I’m not sure about whether it’s the proper way of doing it?

    Does MODx inherit from xPDO or does it delegate to an instance of xPDO?
      MODx Revolution / MAMP / OS X
      • 3749
      • 24,544 Posts
      OpenGeek can give you a more definitive answer but:

      class modX extends xPDO {


      You should be able to use:

      $this->mgr->getCollection(); 
        Did I help you? Buy me a beer
        Get my Book: MODX:The Official Guide
        MODX info for everyone: http://bobsguides.com/modx.html
        My MODX Extras
        Bob's Guides is now hosted at A2 MODX Hosting
        • 22303 MODX Staff
        • 10,725 Posts
        MODx extends xPDO, so anywhere you pass the reference to the $modx or $xpdo objects, you will have access to the core xPDO methods and delegated PDO methods (xPDO doesn’t extend PDO, but provides access to it’s methods directly with the addition of connect() on demand functionality). BTW, you may want to assign the $modx instance by reference in your constructor, e.g.
        <?php
        public function __construct(& $modx) {
            $this->mgr =& $modx;
        }
        ?>
          • 27519
          • 275 Posts
          Ok thanks.

          Quote from: OpenGeek at Oct 18, 2010, 09:41 AM

          MODx extends xPDO...

          The downside I see in this is that transient domain objects (say helper objects that collect other objects from the DB or aggregate / manipulate information) are now tied to the modx instance while they would only need access to the database and not need the other more CMS-like services the modx object offers.

          It’s a bit of an academic discussion but, say you had:

          interface MODxDbBroker {
            public function getCollection()
            public function newQuery()
            ..etc...
          }
          


          ...and then...

          class xPDO implements MODxDbBroker
          


          Again maybe academic but this would allow for alternative ORM handlers to be plugged in to MODx with an adaptor class:

          class SomeOrmAdaptor implements MODxDBBroker
          


          Probably not very high on the list of "must haves", but it’s alway good to be open... smiley
            MODx Revolution / MAMP / OS X
            • 22303 MODX Staff
            • 10,725 Posts
            Our O/R model defines the API for the application, so we are not really interested in rewriting the API for other O/RM’s or database access layers. The benefit of this model is not having to have additional connections to a database, which is one of the most expensive operations when developing a web database application, and being able to quickly port the application and it’s components to another database engine. The fact that it uses PHP’s standard PDO DBAL and gives you direct access to the methods (with on-demand connections and full result-set caching capabilities) is another win for xPDO, and thus MODx.

            You can always load other classes for working with databases however you want using the xPDO::getService() method.