We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
  • Quote from: OpenGeek at Jan 18, 2007, 07:06 PM

    Use xPDO. wink

    ...

    Or borrow the techniques from the xPDO caching layer for extracting appropriate object vars from your objects; which uses PHP’s get_object_vars() function.

    Do you recommend mashing up xPDO w/ a MODx 0.9.5.1 build? Would it be easier to implement xPDO as a whole, or just the referenced methods?

    I’ve said it before, I’ve got to dive right in, it’s just hard when you don’t know your limitations, etc wink
      Mike Reid - www.pixelchutes.com
      MODx Ambassador / Contributor
      [Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
      ________________________________
      Where every pixel matters.
    • Quote from: pixelchutes at Jan 18, 2007, 07:10 PM

      Do you recommend mashing up xPDO w/ a MODx 0.9.5.1 build? Would it be easier to implement xPDO as a whole, or just the referenced methods?
      Absolutely; I recommend xPDO for anything. In fact, I just helped someone on IRC build a fully-functional model of osCommerce with xPDO (started Monday, had his first view functional on Tuesday), which he in turn is using to build Smarty-powered views of osCommerce data that will completely replace the osCommerce front-end application, and possibly the back-end too eventually.

      In any case, xPDO is designed to manage persistence of data to database tables and provide object-oriented access to that data. I don’t think I have a single MODx site of any version (even 0.9.1) that doesn’t just love to work along-side xPDO for custom data.

      In fact if you have your tables designed, contact me via IM or something, I can help you quickly reverse-engineer an XML schema of your model, which you can then use to forward engineer all your classes...
      • Can xPDO function as an extender? Is any heavy core-modification required?
          Mike Reid - www.pixelchutes.com
          MODx Ambassador / Contributor
          [Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
          ________________________________
          Where every pixel matters.
        • Quote from: pixelchutes at Jan 18, 2007, 07:25 PM

          Can xPDO function as an extender? Is any heavy core-modification required?
          You mean for extending internal MODx tables? If so, then yes it can, but you would need to make sure any legacy code could handle whatever table structure changes you made...if it’s just additional fields that don’t need to be dealt with outside of the xPDO code your write, then all should be well except for cases where SQL statements were expecting a specific structure (bad SQL statement!)...
          • Well, more specifically, I meant is it something that’d end up in /manager/includes/extenders, such as the DBAPI?

            For my first trial run, I’d be using solely to leverage the "serialization" benefits, and then would progress into the more advanced from there. (Cool DB stuff)

            In short: Do I implement via uploading a few files, and adding an include statement, or is it a bit more complex?
              Mike Reid - www.pixelchutes.com
              MODx Ambassador / Contributor
              [Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
              ________________________________
              Where every pixel matters.
            • Quote from: pixelchutes at Jan 18, 2007, 07:35 PM

              Well, more specifically, I meant is it something that’d end up in /manager/includes/extenders, such as the DBAPI?

              For my first trial run, I’d be using solely to leverage the "serialization" benefits, and then would progress into the more advanced from there. (Cool DB stuff)

              In short: Do I implement via uploading a few files, and adding an include statement, or is it a bit more complex?
              xPDO gives you an object model of your tables. Without that model (i.e. the schema and the classes generated for them), you won’t be able to take advantage of the serialization benefits, other than borrowing the techniques and reimplementing them for your custom (i.e. non-xPDO) classes/objects...

              And yes, using xPDO is as easy as uploading it and including your file, but there are a number of ways to utilize xPDO within any PHP script. But at the bare minimum, you upload the /xpdo dir, include the main xPDO class, and then you can utilize PDO API functionality (direct db access layer), even in PHP 4 without PDO. To make use of serialization, you need to create a model and generate your classes/maps.

              And no, it has nothing to do with the legacy extenders dir in the manager.
              • Great! Any specific folder you’d recommend?
                  Mike Reid - www.pixelchutes.com
                  MODx Ambassador / Contributor
                  [Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
                  ________________________________
                  Where every pixel matters.
                • Quote from: pixelchutes at Jan 18, 2007, 09:22 PM

                  Great! Any specific folder you’d recommend?
                  Well, it’s flexible... I typically put it in the root of my site (i.e. /xpdo) but you can even put it somewhere accessible outside the web document root altogether...for extra security...
                  • Ok--

                    So I’d like to have use of xPDO site-wide (MODx, of course). I’ve got my directory in place, and am ready to go! So, do I need to include xpdo.class.php with the main MODx includes, or would require_once within a plugin/snippet make more sense? I guess with MODx, having the power to decide is really the cool part wink

                    Update: Ah, ok, on the right track....

                    <?php
                    global $modx;		
                    include_once ( $modx->config['base_path'] . 'xpdo/xpdo.class.php');
                    $xpdo= new xPDO('mysql:host=localhost;dbname=mydb', "mydbuser", "mydbpass");
                    


                    Hmm...is there a way to quickly reverse engineer an existing table into a Map file? (*.map.inc.php)

                    I couldn’t test the Person example on xPDO site per lack of table/class/map files. So, I created the table and the class, and as I looked at the map file, I realized I hadn’t created a table for the Person example, rather the xpdosample table... So, I needed to adjust the person example to match that of my table/map file...
                      Mike Reid - www.pixelchutes.com
                      MODx Ambassador / Contributor
                      [Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
                      ________________________________
                      Where every pixel matters.
                    • Yes, though the reverse-engineering mechanism is slightly broken in certain situations. However I’m fixing it right now and you can see my note at the bottom if you encounter this known issue...

                      But anyway, here is a generic version of the build file for the MODx 0.9.7 model. To forward-engineer your database, just tailor the reverse-engineered xml file (the schema) you generate, then comment the reverse-engineering line and uncomment the forward-engineering line; that will generate the classes and maps of your object model and provide the basic scaffolding for working with those objects (i.e. CRUD, or ACID, or basically just be able to manage individual instances as rows in a database).

                      Please note, the resulting XML schema is incomplete; you will need to define relationships between the various objects in the schema to take full advantage of xPDO. I’ll post another topic on this issue...

                      <?php
                      $mtime= microtime();
                      $mtime= explode(" ", $mtime);
                      $mtime= $mtime[1] + $mtime[0];
                      $tstart= $mtime;
                      include_once (strtr(realpath(dirname(__FILE__)) . '/../xpdo.class.php', '\\', '/'));
                      
                      $xpdo= new xPDO('mysql:host=localhost;dbname=mydb', 'user', 'password', 'optional_tbl_prefix_');
                      $xpdo->setPackage('mymodel');
                      $xpdo->setDebug(true);
                      
                      $manager= $xpdo->getManager();
                      $generator= $manager->getGenerator();
                      
                      //reverse-engineer an existing database
                      //$xml= $generator->writeSchema(XPDO_CORE_PATH . '_model/mymodel.mysql.schema.xml', 'mymodel', 'xPDOObject', 'optional_tbl_prefix_');
                      
                      //forward-engineer a model
                      $generator->parseSchema(XPDO_CORE_PATH . '_model/mymodel.mysql.schema.xml');
                      
                      $mtime= microtime();
                      $mtime= explode(" ", $mtime);
                      $mtime= $mtime[1] + $mtime[0];
                      $tend= $mtime;
                      $totalTime= ($tend - $tstart);
                      $totalTime= sprintf("%2.4f s", $totalTime);
                      
                      echo "\nExecution time: {$totalTime}\n";
                      
                      exit ();


                      I usually create this in a folder called _model under my xpdo directory, for convenience.

                      BTW, the bug is it will put AUTO_INCREMENT as an element directly in columns with that attribute if you have not named them ’id’ specifically. To fix this, simply replace the AUTO_INCREMENT string it erroneously inserts with the following line:
                      generated="native" attributes="unsigned"
                      NOTE: obviously, if you allow signed values in an AUTO_INCREMENT column, you are insane... and if so, just don’t include that part. tongue