<![CDATA[ The Benefits of xPDO over Writing SQL - My Forums]]> https://forums.modx.com/thread/?thread=78304 <![CDATA[Re: The Benefits of xPDO over Writing SQL]]> https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=3#dis-post-473352
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()));


]]> wshawn Jul 29, 2013, 03:33 AM https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=3#dis-post-473352 <![CDATA[Re: The Benefits of xPDO over Writing SQL]]> https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=3#dis-post-432800 
$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]]> lazylegs Aug 10, 2012, 07:11 AM https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=3#dis-post-432800 <![CDATA[Re: The Benefits of xPDO over Writing SQL]]> https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=3#dis-post-432795 ]]> fuzzicallogic Aug 10, 2012, 06:27 AM https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=3#dis-post-432795 <![CDATA[Re: The Benefits of xPDO over Writing SQL]]> https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=2#dis-post-432753
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]]> BobRay Aug 09, 2012, 10:32 PM https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=2#dis-post-432753 <![CDATA[Re: The Benefits of xPDO over Writing SQL]]> https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=2#dis-post-432695
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).]]> fuzzicallogic Aug 09, 2012, 04:40 AM https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=2#dis-post-432695 <![CDATA[Re: The Benefits of xPDO over Writing SQL]]> https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=2#dis-post-432688 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
]]> pbowyer Aug 09, 2012, 02:52 AM https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=2#dis-post-432688 <![CDATA[Re: The Benefits of xPDO over Writing SQL]]> https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=2#dis-post-432626 ... 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]]> fuzzicallogic Aug 08, 2012, 11:07 AM https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=2#dis-post-432626 <![CDATA[Re: The Benefits of xPDO over Writing SQL]]> https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=2#dis-post-432589 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?
]]> pbowyer Aug 08, 2012, 04:07 AM https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=2#dis-post-432589 <![CDATA[Re: The Benefits of xPDO over Writing SQL]]> https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=2#dis-post-432238
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.]]> fuzzicallogic Aug 03, 2012, 11:15 PM https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=2#dis-post-432238 <![CDATA[Re: The Benefits of xPDO over Writing SQL]]> https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=2#dis-post-432235
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.]]> stalemate resolution associate Aug 03, 2012, 09:54 PM https://forums.modx.com/thread/78304/the-benefits-of-xpdo-over-writing-sql?page=2#dis-post-432235