We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
  • What are the thoughts about integrating MODx and Code Igniter? I’m not dead-set on anything here, but I need a way to easily perform CRUD operations on a series of random tables. Only the admins really need to edit the stuff in those custom tables, but it’s possible that the the front end "normal" web users will have to read that information.

    So my thought was to make one directory and modify my .htaccess file so that MODx doesn’t get to play with any incoming requests for that folder. Then I can use the standard Code Igniter stuff to build out CRUD stuff to manage my special tables -- I’ll create those tables in the MODx database (I might give CI a separate user, though, just to make sure it doesn’t mess with MODx). Then back in MODx, I might be able to use simple @SELECT bindings to get the info I need.... Ditto offers much greater functionality, but I don’t think It could be easily hacked to execute queries on custom tables. I might be able to write queries into Snippets, and then get the formatting options I need.

    Anyhow... just thoughts. I’m sure others have come up with other solutions. Thoughts?


    • CodeIgniter is much more than CRUD. If you just want CRUD, why not consider xPDO, on which Revolution (i.e. MODx 2.0) is being constructed. That’s exactly what it is for, and well, integration is not really a problem... wink

      We don’t yet have great, easy-to-use form building systems built on xPDO/Revo (I’m sure CodeIgnitor would excel there at this point), but we do have some example code for building forms really easily using xPDO, and it is almost trivial to write that stuff with xPDO and MODx (even in 0.9.x sites I use xPDO for custom table access/integration). We even use xPDO with Smarty for stand-alone applications. It’s very lightweight, fast, and will be seeing growing support in the MODx community.

      Just my thoughts...
        • 34017
        • 898 Posts
        I’ve been thinking of this recently too. And really modx admin is a crud tool.

        If you need complex relationships in your tables, create a Template with TVs for the fields you need. Then create a plugin to copy those values to the table or tables you need. Then you could use xpdo, doctrine, activerecord, anything to show the results on the frontend.

        It would be like a CCK drupal concept. You could even do a reverse and use eForm with its onMail, etc. on the frontend to save this info as a modx document. Why? you would have access to ditto, ajaxsearch, permissions, etc. for the "rows".

        If the site got very large, you might need to migrate this solution because of all the assorted content metadata, but it’d be great to save users info from an eform contact page into the modx db with ajaxsearch capabilities and all of the modx admin crud.
          Chuck the Trukk
          ProWebscape.com :: Nashville-WebDesign.com
          - - - - - - - -
          What are TV's? Here's some info below.
          http://modxcms.com/forums/index.php/topic,21081.msg159009.html#msg1590091
          http://modxcms.com/forums/index.php/topic,14957.msg97008.html#msg97008
        • Hmm.... I’m not a big fan of TV’s when it comes to complex custom table structures.... it works, but if we don’t have a clean, fully normalized database architecture underneath it all, then reporting, updating, and viewing gets to be jumbled. Something as simple as selecting a row (i.e. document) with each of its template variables in a separate column becomes a messy bunch of SQL joins. I understand the solution outlined would make maximum use of Ditto and eForm, and maybe that’s the easiest way to go with the time we have, but I get irked when the DB tables aren’t really clean.... some of our tables are using InnoDB and enforcing foreign key constraints, so it’s pretty meticulous on the DB level.

          I’m not familiar with CCK or Drupal other than trying to make it work for about an hour and half and then moving on... until I found MODx smiley

          xPDO... I’ve looked at it briefly, and I’ll be the first to admit that my understanding of how these frameworks do their magic is limited, so any little bit of unclarity in the docs just kills my chances... I need to see the ENTIRE php file to know what’s going on... nearly all of their examples show a line or two of code, and I’m just not experienced enough to know where to put those lines. That equals instant death. Game over... next framework please. So I wasn’t able to make sense of xPDO... and it certainly doesn’t help when the doc pages have broken links (e.g. http://www.xpdo.org/documentation/migration-guides.html -- was this page intentionally left blank?). Code Igniter had 2 really helpful videos on their site which really could get me going with my project. I haven’t seen anything like that for xPDO. I know I could figure it out if given enough time, but I don’t have infinite time for this stuff...

          One simple suggestion: loose the "extends xPDOObject" name... that name might make sense to the original developers, but "xPDOObject" has no place in my brain... I don’t even know how to begin thinking about that object. Why not choose a friendlier, descriptive name? Maybe it sounds trite, but a good variable name really greases the rails.
          • Quote from: Everettg_99 at Dec 13, 2008, 10:35 PM

            Hmm.... I’m not a big fan of TV’s when it comes to complex custom table structures.... it works, but if we don’t have a clean, fully normalized database architecture underneath it all, then reporting, updating, and viewing gets to be jumbled. Something as simple as selecting a row (i.e. document) with each of its template variables in a separate column becomes a messy bunch of SQL joins. I understand the solution outlined would make maximum use of Ditto and eForm, and maybe that’s the easiest way to go with the time we have, but I get irked when the DB tables aren’t really clean.... some of our tables are using InnoDB and enforcing foreign key constraints, so it’s pretty meticulous on the DB level.
            I agree with you on this completely; TV’s are great for dealing with content managers editing view related aspects of things, but ultimately, you need a solid data model, and IMO, a solid domain model (or object model) with which to interact with your data model. And this is where xPDO can help, though I have not yet done testing or work with InnoDB foreign key constraints, but would love to add that support for 1.0 final.

            Quote from: Everettg_99 at Dec 13, 2008, 10:35 PM

            xPDO... I’ve looked at it briefly, and I’ll be the first to admit that my understanding of how these frameworks do their magic is limited, so any little bit of unclarity in the docs just kills my chances... I need to see the ENTIRE php file to know what’s going on... nearly all of their examples show a line or two of code, and I’m just not experienced enough to know where to put those lines. That equals instant death. Game over... next framework please. So I wasn’t able to make sense of xPDO... and it certainly doesn’t help when the doc pages have broken links (e.g. http://www.xpdo.org/documentation/migration-guides.html -- was this page intentionally left blank?). Code Igniter had 2 really helpful videos on their site which really could get me going with my project. I haven’t seen anything like that for xPDO. I know I could figure it out if given enough time, but I don’t have infinite time for this stuff...
            Agreed; documentation sucks, and as we approach both Revolution final and xPDO 1.0 final, that will be addressed. We’re approaching the close of a long period of development and unfortunately and have avoided producing documentation I know we desperately need; it would simply need to change too often as we made progress with Revolution and xPDO core code, on which other developers’ code would rely on. This will soon be priority number one...

            Quote from: Everettg_99 at Dec 13, 2008, 10:35 PM

            One simple suggestion: loose the "extends xPDOObject" name... that name might make sense to the original developers, but "xPDOObject" has no place in my brain... I don’t even know how to begin thinking about that object. Why not choose a friendlier, descriptive name? Maybe it sounds trite, but a good variable name really greases the rails.
            Again, I think better documentation will help understanding here; xPDO is the prefix for all classes in xPDO. Object, well, it is the class all user-defined classes that want to make use of xPDO must extend, so xPDOObject seemed perfectly sensical to me. stdObject is PHP’s internal base object class, so I was just trying to follow standard conventions.
            • Thanks for the thorough response. In case I sounded ungrateful, let me say loudly that I’m a huge fan of the work you guys are doing. I think MODx is wonderful, and if xPDO was built with the same thoughtfulness, I expect it to be nothing short of brilliant. I know I’m not the most senior developer out there by a long shot, but maybe I can continue to help out with my freaky obsession with documentation.
                • 34017
                • 898 Posts
                I totally agree with you as well everett. My idea is TVs more for protoyping / rapid development. But plugins into external tables for solid model/domain dbs. modx base just lets a ’manager’ insert/update data. then we do with it what we want. And this is more for the basic small website. If it’s a larger website, you may need to spend more time on the crud itself.
                  Chuck the Trukk
                  ProWebscape.com :: Nashville-WebDesign.com
                  - - - - - - - -
                  What are TV's? Here's some info below.
                  http://modxcms.com/forums/index.php/topic,21081.msg159009.html#msg1590091
                  http://modxcms.com/forums/index.php/topic,14957.msg97008.html#msg97008