Evo or Revo?

I’ve seen it, and I’m still using Evo.

Quote from: TimGS at May 01, 2011, 06:08 AM

I’m still not seeing how learning xPDO is going to help the coding of my websites.
-- Tim.

Which may be precisely why you are arguing against it - because you have not worked with it as extensively as, say Bob or Mark for example. I abandoned Evo long ago after forcing myself to understand Revo, and realistically I see no comparison between the two models in terms of usability, functionality and overall cohesiveness.

But it’s precisely how Morpheus describes the Matrix: Unfortunately, no one can be told what MODx Revolution is. You have to see it for yourself.

Quote from: Mark at May 01, 2011, 07:56 AM

Also - the underlying database structure can me modified to be more efficient / make more sense, while keeping a clean upgrade path if you use the recommended object approach.

How would you want to modify the db structure? I’m not being rhetorical - though I admit to being skeptical as to any realistic practical advantage.

@Tim -- I find this a really interesting conversation and you’ve made some very good points. I hope we can keep if from being a, "my CMS can kick your CSM’s butt" conversation, or worse yet, an argument about parsing the meaning of each other’s posts. I think we can all agree that Evo and Revo both have strengths and weaknesses.

By way of changing the subject back to comparison of the two platforms (and especially xPDO), I thought I’d try another example. In retrospect, my last one wasn’t that great. Suppose that you want to show the names of the parent containers holding other docs created by the creator of the current resource. You’re obviously very good at the Evo DBAPI (much better than I am) and I’d be curious to see what this code would look like in Evo and how readable it would be. This is off the top of my head, so please forgive any errors:

<?php
$containers = array();
$creator  = $modx->resource->getOne('CreatedBy');
$docs = $creator->getMany('CreatedResources');

foreach ($docs as $doc) {
   $parent = $doc->getOne('Parent');
   if ($parent) {  // ignore docs with no parent
       $parentName = $parent->get('pagetitle');
       if (! in_array($parentName, $containers) {
           $containers[] = $parentName;
       }
    }
}
return ('The author of this article has written articles in the following categories: ' . implode(', ', $containers);  

$creator = $modx->documentObject['createdby'];
$docs_result = $modx->db->select('parent', $modx->getFullTablename('site_content'), 'parent != 0 AND createdby='.$creator);

$containers = array();
while ($docs_row = $modx->getRow($docs_result))
	{
	$parent_doc = $modx->getDocument($docs_row['parent']);
	$parent_name = $parent_doc['pagetitle'];
	if (!in_array($parent_name, $containers)) $containers[] = $parent_doc['parent'];
	}

return ('The author of this article has written articles in the following categories: ' . implode(', ', $containers);

$modx_site_content = $modx->getFullTableName('site_content');
$result = $modx->db->query('SELECT pagetitle FROM '.$modx_site_content.' WHERE id IN
		(SELECT DISTINCT parent FROM '.$modx_site_content.' WHERE parent != 0 AND createdby = '.$modx->documentObject['createdby'].')');

$containers = array();
while($row = $modx->getRow($result) $containers[] = $row['pagetitle'];

return ('The author of this article has written articles in the following categories: ' . implode(', ', $containers);

Quote from: TimGS at May 01, 2011, 08:54 AM

Quote from: Mark at May 01, 2011, 07:56 AM

Also - the underlying database structure can me modified to be more efficient / make more sense, while keeping a clean upgrade path if you use the recommended object approach.

How would you want to modify the db structure? I’m not being rhetorical - though I admit to being skeptical as to any realistic practical advantage.

I meant that the core developers can (and have in 2.1 I believe) modify the underlying structure, without breaking any snippets that properly use the objects.

There’s quite some snippets (Didn’t check, but I guess most of them) for Evolution that directly access the database through SQL queries - modifying any database structure in there would break all those snippets.

You are in a different situation from me though. I already know Evo well, and see no benefit in switching. Despite the above, I don’t think Revo’s bad (but I don’t see it as being better.)

// Make your manager and extras multilingual:

$translatedString = $modx->lexicon('namespace.tag');

// Flexible, fine-tuned caching system (without polluting $_SESSION):
// Supports file-based caching or memcache. Can create a custom cache implementation by overriding the xPDOCache abstract class.
// Some easy ways of getting and setting cache data:

$modx->cacheManager->add($key, $value, $ttl); // add an item to the cache for $ttl seconds
$modx->cacheManager->delete($key); // remove an item from the cache

// xPDO - examples of Revo power out-of-the-box:

$xPDO->addPackage; // instantly extends MODx core with your own package (classes and maps), making your custom database available to xPDO.
$xPDO->prepare, $xPDO->execute, etc. // prepared statement support
$xPDO->getOne, $xPDO->getMany, $xPDO->remove, etc. // Define your own database field relationships to create simple or complex associations with one another.

// Contexts - discrete areas with isolated configuration parameters, useful for subdomains or multiple MODx instances with a single installation:

$modx->switchContext('context'); // switches to a different context

// Programmatic access to MODx or custom processors, with full error handling support

$response = $modx->runProcessor();

// Speaking of error handling...

$modx->error // Object that supports field and group validation, error messages and return responses.

// For more: check out api.modx.com

...although I have to admit I might well be tempted just to do...

$modx_site_content = $modx->getFullTableName('site_content');
$result = $modx->db->query('SELECT pagetitle FROM '.$modx_site_content.' WHERE id IN
		(SELECT DISTINCT parent FROM '.$modx_site_content.' WHERE parent != 0 AND createdby = '.$modx->documentObject['createdby'].')');

$containers = array();
while($row = $modx->getRow($result) $containers[] = $row['pagetitle'];

return ('The author of this article has written articles in the following categories: ' . implode(', ', $containers);

...but that is (arguably) an unfair comparison given its quite a different programming style. The two selects may also be quicker as a join, but I don’t know enough about MySQL to be sure.

<?php
$c = $modx->newQuery('modResource');
$c->select('modResource.*, Parent.pagetitle as category');
$c->where(array('Parent.parent != 0', 'CreatedResources.createdby ' => $modx->resource->get('createdby')));
$c->groupBy('Parent.pagetitle');

$containers = array;
$rows = $modx->getCollectionGraph('modResource', '{"CreatedResources":{"Parent":{}}}', $c);
foreach($rows as $row){	$containers[] = $row->get('category'); }

return ('The author of this article has written articles in the following categories: ' . implode(', ', $containers);