We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 39932
    • 483 Posts
    It's nice to know I'm part of a community that is almost as crazy fun as I am. smiley
      Website: Extended Dialog Development Blog: on Extended Dialog
      Add-ons: AJAX Revolution, RO.IDEs Editor & Framework (in works) Utilities: Plugin Compatibility List
      Tutorials: Create Cross-Context Resources, Cross-Context AJAX Login, Template-Based Actions, Remove Extensions from URLs

      Failure is just another word for saying you didn't want to try. "It can't be done" means "I don't know how".
      • 34012
      • 88 Posts
      About the constants for classes and tables. There are multiple ways of to get them. First are the xPDO class methods.

      $xpdo->getTableName('myObject');

      This will return quoted table with prefix set for the package. Example: "my_object" and if prefix for package: "modx_my_object" for example

      $xpdo->getClassName('my_table');

      This will return the object name for my_table eg. myTable.

      Then if you have already constructed your object with getObject for example, you can directly get values through object variables.
      $obj->_table; // the table name with quotes
      $obj->_class; //class name without driver postfix

      But recommend to stick with xPDO methods

      Also then are the non-magical methods that will come handy.

      xPDO::call("objectClass", "redo", array("meep"));


      You can call static method within a objectClass for example, without the 4th parameter set to true. This will actually call objectClass_driver::redo("meep"). Also will call xPDO::loadClass().

      xPDO::loadClass('objectClass')


      If you got derived classes from own classes, most likely you'll get error thrown for class not found. Driving the loadClass() with class you want, will load the class + the driver based class.

      This is the power of "constants" with xPDO. Obviously there are xPDO::CONSTANTS but those have different meaning then.

      getMany(), getOne() etc... they use the object names obviously. Thats how pretty much everything works with xPDO. But it is good to know how to get the table names also. Also if needed, xPDO has class method literal() which will strip off the quotes around table names. There are also functions for field names etc... but not gonna go there.

      Throwing my 2 cents to discussion I guess.

      ## Edit

      Forgot arbitrary query to keep up the spirits

      $c = $xpdo->newQuery('lazyTickets');
      $c->select($xpdo->getSelectColumns('lazyTickets', 'ld', '', array('id', 'desc')));
      $c->where(array(
          'id:IN' => array(1,2,3,4,5),
          'lc.name:NOT LIKE' => '%lazy%'
      ));
      $c->innerJoin('lazyClient', 'lc');
      $res = $xpdo->getCollection('lazyTickets', $c);
      foreach($res as $dummy) { $out[] = $dummy>toArray('', false, true); }
      


      To get the objectNames to some IDE, not possible right now. As there is no constants like people have already noticed. But this should not be a problem really, I guess they could be added to maps. Dunno what the head chief will say about the idea smiley [ed. note: lazylegs last edited this post 11 years, 8 months ago.]
        Almost retired from web-development industry but still randomly writing at Lazylegs.info and on schedule hopefully in near future to finish Oracle and PostgreSQL ports of MODX
      • I just found this thread by accident.

        The BEST reason to use xPDO is code re usability. It is extremely easy to build a set of tools which can be used over and over and not hashed out as every project is reduced to dealing with the same thing: an xPDOObject. The attributes are mostly irrelevant to the developer so they can focus on security and other issues which are more important.

        The OTHER BEST reason is the simplicity to expand and grow a project. xPDO forces the developer to hash out the relationships in the schemata so the interrelational aspects are pretty much a done deal when the schema is parsed and the model generated - leaving the developer to focus on function instead of relationships.

        Not to mention it is REALLY nice to be able to
        $this->xpdo->getObject('some_other_class_not_even_in_this_package', array('inventoryid' => $this->getPrimaryKey()));


          Get your copy of MODX Revolution Building the Web Your Way http://www.sanitypress.com/books/modx-revolution-building-the-web-your-way.html

          Check out my MODX || xPDO resources here: http://www.shawnwilkerson.com