We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 39404
    • 175 Posts
    stalemate resolution associate Reply #11, 11 years, 9 months ago
    Debussy,

    I'm in a similar boat to you, although historians will probably argue my "main issues" run deeper.

    I was looking through the documentation and came across this:
    http://rtfm.modx.com/display/xPDO20/xPDOGenerator.writeSchema
    which allows you to generate your xPDO schema from an existing database. From what I understand, you can take it and generate it from an existing database, although there are some things you still have to do on your own like generate relationships.

    This is cool because if you're looking for a quick win to see how a given table you've created gets represented in xPDO, you'll have it and then all you have to do is just keep it as a template for stuff going forward.

    It was hot and I was an insomniac last night so I tried to cool down by consuming some cool technology: I tried using xPDO on my own database (which is using SQL server). I didn't get as far as I wanted but at least I got to the point I understood the generation process and was able to generate a schema file with a couple of tweaks along the way.

    I had wanted to post these comments this morning before work but I wasn't able to log in: I probably hit my account quota of two posts for the month.

    Good luck! I'll be learning this too.

    On a related topic, thanks Bob for the OOP part in the book; it definitely gave me a boost.
      • 3749
      • 24,544 Posts
      BTW, the page link in my post above has a snippet that will run writeSchema() for you on your custom tables.


      ------------------------------------------------------------------------------------------
      PLEASE, PLEASE specify the version of MODX you are using.
      MODX info for everyone: http://bobsguides.com/modx.html
        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
        • 37044
        • 68 Posts
        First off big thanks to Bob / OpenGeek / SplittingRed / LazyLegs (+many!) the tutorials / documentation / add ons you have written have saved me in many occasions.

        I would like to think of myself as an accomplished php / mysql dev and have been getting into the more advanced side of Modx over the last year. However to a degree I have to echo debussy and stalemates experiences of learning XPDO - fairly slow and laborious.

        I have been using custom tables and also using XPDO to access standard Modx resources etc and now have started to be able to write fairly standard CRUD functionality pretty quickly and trouble free including some more advanced joins etc.

        But as soon as I want to do something a little out of the ordinary I always run into problems (...maybe more me than XPDO!). For example tonight I have been looking to rewrite a simple select query with an MD5 hash in - I have no idea how to translate this and quite some Googling I am none the wiser. Simple query - SELECT col_name FROM table WHERE MD5(ID) ='***hash_here***' ?

        I think in many respects it has proved frustrating to know how to hand code complex myqsql from memory pretty well and then to be having trouble writing simple (XPDO) queries again - feels a bit like regressing.

        Some of the benefits (database agnostic / upgrade proofing / etc ) are all very good for more advanced sites etc but I think for a lot of devs shallow learning curve and quick deployment within deadlines are probably more important (despite this maybe being slightly short sighted). And I think for a number myself included learning XPDO can seem like a massive undertaking especially when working to tight deadlines and also easy to "put off till the next project...". I think that the learning curve can be a barrier to entry for many.

        Despite 'understanding' the advantages of XPDO I cant help but feel like I am still waiting for them to materialize for me yet to a certain extent. But onward and upward I am still trying to break through and continue learning.

        But all that said please note I commend all of the contributors for all their hard work and do love the platform and will be using it for the foreseeable future!

        PS but don't get me started on CMP's and ExtJS ;-) [ed. note: megasteve4 last edited this post 11 years, 8 months ago.]
          • 39404
          • 175 Posts
          stalemate resolution associate Reply #14, 11 years, 8 months ago
          To Bob: I checked the link out. Thanks for this.

          To megasteve4: I know it isn't ideal, but if you were to create a view off the table and create the MD5 ID within the view, you probably would be able to still use xPDO.

          so, CREATE VIEW someview AS
          SELECT col_name, MD5(ID) AS md5_field FROM table

          then in your xPDO part, SELECT col_name from someview WHERE md5_id ='***hash_here***'

          ... of course my big assumption is that xPDO supports views. But from a SQL perspective, the view would just seem like a read-only table.
            • 39932
            • 483 Posts
            #1 reason for my satisfaction using xPDO: Speed and readability. (OK, that's two)

            Speed: Speed is comparable to that of using straight SQL queries (any platform). It's impressive.

            Readability: It's so much easier to understand. Further abstracting out variables for table names, object types, and values is much faster and easier than with an SQL string. No worries about escaping, injection... xPDO does all of that for you.

            When I started using xPDO, I got that same warm, fuzzy feeling that I got when MS first introduced ADO into Visual Studio 6. That's a rare thing for me, and I cherish it. The fact that it made me even more warm and fuzzy than ADO first did is incomprehensible. I would never have thought that it was possible.
              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".
            • Quote from: fuzzicallogic at Aug 04, 2012, 04:15 AM
              Further abstracting out variables for table names, object types, and values is much faster and easier than with an SQL string.

              Can you expand how you do that? I haven't seen MODX generate class constants for table names and columns (unlike Propel, for example), so I guess you have an extension that does it?
                MAPLEDESIGN MODX development and MODX web design and custom development. Proud to serve UK and International clients!
                • 39932
                • 483 Posts
                ... so I guess you have an extension that does it?

                No, I do not have an extension for that. Abstraction is more than just class constants. You can use System Settings, User Settings, Context Settings, Template Variables, etc. If you limit yourself to constants for abstraction, then you're missing a boat-load of options. You can further create your own custom tables and using the above can generate some really dynamic results.

                Additionally, MODX does use constants. 'modResource' is a constant value that points to the 'site_content' table. You can't access it like a constant, but it acts as one just the same. (Semantically, they are not the same, but functionally is the argument) -- 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".
                • Quote from: fuzzicallogic at Aug 08, 2012, 04:07 PM
                  No, I do not have an extension for that. Abstraction is more than just class constants. You can use System Settings, User Settings, Context Settings, Template Variables, etc. If you limit yourself to constants for abstraction, then you're missing a boat-load of options.

                  Can you provide an example of how you're using these abstractions in your xPDO queries? I'm clearly failing to 'get it'.

                  Thanks,
                  Peter
                    MAPLEDESIGN MODX development and MODX web design and custom development. Proud to serve UK and International clients!
                    • 39932
                    • 483 Posts
                    Absolutely! Here's a simple one. Make a Template that is a "sorted list". Make a template variable that acts as a string for a field that you want to sort by. Make two documents, and set the tv to different field names. In each of the pages make the same Snippet call ('mySnippet'). I should mention that the code below follows a bad example and should templatize the output.

                    mySnippet:
                     
                    
                    $fieldname = $modx->resource->getTVValue('sortbyfield');
                    $query = $modx->newQuery('modResource',
                        array('parent'=>0)
                    );
                    $query->sortby($fieldname, 'ASC'); 
                    $list = $modx->getCollection('modResource', $query);
                    
                    foreach ($list as $key => $res)
                    {   $output='<ul>';
                        if(!empty($res))
                            $output .= '<li>'. $res->get('alais') .'</li>';
                        $output .= '</ul>';
                    }
                    


                    Further, you could make a Resource that queries database objects and provides a list of them to the front-end. Instead of making a Snippet that does them all, you could make a single Resource. It accepts a URL parameter (not GET param) for the type of database object to list. Now you have one page that can sniff your entire MODX list. (This is not a good example, just an example).

                    Just in case these doesn't illustrate my point (you might wanna check out RO.IDEs proposed Add-on thread), since the tables are already abstracted via xPDO, we can further abstract them to provide more uses. For instance, you could make a Snippet out of a Resource and add code in TVs that could mutate the Snippet based on "web application state".

                    With xPDO, you can do what you want, when you want, how you want. You just gotta have imagination. Right now, all of this is being applied to a developer's social blogging network called Extended Dialog. The site is not quite ready, but is demonstrable. Here is the link:http://users.extendeddialog.com/user/2

                    There are 12 blogs on the site, so far, all created dynamically. There is one "mini profile" snippet for each type of blog (3 types). The tags are actually resources (which have no content yet), similar to StackOverflow or other Wiki tags. AJAX queries, Snippets and Plugins are all being run by RO.IDEs on top of the MODX Framework.

                    To make the queries happen, I use URL params, site-wide aliases across contexts (to keep in same domain), and Chunks filled with straight CSS and JS. The profile page I linked you to accesses (now) over 650 resources on the site at once. Again, nearly the entire site is managed with xPDO queries.

                    I hope this gives a clearer picture of what I mean. Class Constants are the basest form of abstraction; they are useful but hold nothing compared to the power of xPDO and MODX. In other words, you could build an entire CMS on top of the MODX CMS (if you wanted to... I'll just stick with MODX). [ed. note: fuzzicallogic last edited this post 11 years, 8 months ago.]
                      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".
                      • 3749
                      • 24,544 Posts
                      Here's a fairly simple example (minus some sanity checks).

                      Say that on a MODX site page, you want to display the pagetitles of all siblings of the current resource (the page the viewer is requesting in the front end) as a list.

                      <?php
                      $parent = $modx->resource->getOne('Parent');
                      $children = $parent->getMany('Children');
                      $output = '<ul>';
                      foreach ($children as $child) {
                          $output .= '<li>' . $child->get('pagetitle') . '</li>;
                      }
                      $output .= '</ul>';
                      
                      return $output;
                      



                      Since you define those aliases in your xPDO schema, They can express any relationship between your custom tables and retrieve the appropriate objects:

                      $salesman->getMany('customers');
                      $salesman->getOne('userprofile');
                      $teacher->getMany('Students');
                      $teacher->getMany('Courses');
                      $teacher->getOne('userprofile');
                      $student->getMany('Teachers');
                      $student->getOne('advisor');


                      You can also search with getCollection():

                      $NwSalesmen = $xpdo->getCollection('salesman', array('territory' => 'nw'));


                      The second argument to getCollection() can also be a query object with complex criteria, sorting, a limit, and/or a join.


                      ------------------------------------------------------------------------------------------
                      PLEASE, PLEASE specify the version of MODX you are using.
                      MODX info for everyone: http://bobsguides.com/modx.html
                        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