How to run out of memory in Revolution

[[MemTest]] (cached or uncached -- doesn't seem to matter)

$chunk = $modx->getObject('modChunk',array(
    'name' => 'TestChunk'
    ));

print_r($chunk);

echo $chunk

echo $chunk->snippet

$chunk = getChunk('TestChunk');
echo $chunk;

Not anymore. Things are much simpler . . .

$chunk = $modx->getObject('modChunk',array(
    'name' => 'TestChunk'
    ));

echo $chunk->snippet;

print_r() seems to either execute the code it finds in the object or else it can’t tell where the object ends. Both seem odd.

While messing with this, I did get some output for a while and saw the whole array of info on the current document followed by its fullly parsed content go by over and over.

The correct answer is:

echo $chunk->snippet

but it’s not very obvious or intuitive.

To paraphase part of Shaun’s tutorial page:

Evolution:

$chunk = getChunk('TestChunk');
echo $chunk;

Not anymore. Things are much simpler . . .

Revolution:

$chunk = $modx->getObject('modChunk',array(
    'name' => 'TestChunk'
    ));

echo $chunk->snippet;

I’m sure the new way is more efficient, flexible, powerful, and faster, but no way it’s simpler.

I miss getChunk.

Could we maybe bring it back as a wrapper?

<?php
$chunk = $modx->getObject('modChunk',array(
    'name' => 'TestChunk'
));
$chunkProperties = array(
    'foo' => 'This replaces a placeholder with the name TestChunk.foo',
    'bar' => 'This replaces a placeholder with the name TestChunk.bar'
);
echo $chunk->process();
?>

<?php
$snippet = $modx->getObject('modSnippet',array(
    'name' => 'TestSnippet'
));
$snippetProperties = array (
    'param1' => 'foo',
    'param2' => 'bar'
);
echo $snippet->process($snippetProperties);
?>

<?php
    function getChunk($chunkName, $properties= array ()) {
        $output= '';
        if ($chunk= $this->getObject('modChunk', array ('name' => $chunkName), true)) {
            $output= $chunk->process($properties);
        }
        return $output;
    }
?>

Quote from: BobRay at Oct 05, 2008, 05:39 PM

While messing with this, I did get some output for a while and saw the whole array of info on the current document followed by its fullly parsed content go by over and over.

The correct answer is:

echo $chunk->snippet

Actually wrong; that is not the way to access the chunk output...in fact, you should never reference the snippet property except from the manager code for presenting and editing it in a form. This property will be subject to change in future versions; it remains the same in the initial release only to support legacy code with SQL queries that depend on the table/column names. This will give people time to migrate their code to the Revolution way of doing things while their old code isn’t horribly broken in the meantime.
$modx->getChunk() is still there.

Sorry, I did a search of the whole core for getChunk and didn’t find it. I must have misspelled it.

I have to say that for me $chunk->process() for output is even less intuitive than $chunk->snippet, IMO. Maybe I’m just not used to it, but I’m more comfortable using the raw field content than calling a function that does stuff I may not need and don’t fully understand. I would think it would also be faster. And, AFAIK, any placeholders that have been set will be replaced later before the output is rendered.

Also, if I want to modify a chunk’s contents (not its placeholders) programmatically, it still looks like I’d have to user $chunk->set(’snippet’, ’newValue’);

As for migration, if the field names are going to change, it might be better to break their code now rather than later before many add-ons are converted -- or to build in an alias in the functions that use the field name. Just my $.02.

Quote from: BobRay at Oct 13, 2008, 03:49 AM

I have to say that for me $chunk->process() for output is even less intuitive than $chunk->snippet, IMO. Maybe I’m just not used to it, but I’m more comfortable using the raw field content than calling a function that does stuff I may not need and don’t fully understand. I would think it would also be faster. And, AFAIK, any placeholders that have been set will be replaced later before the output is rendered.

Nope, everything in Revolution is done recursively; each modElement instance is responsible for parsing it’s own cacheable content and providing the output back. You never use the source content of a modElement directly.

Quote from: BobRay at Oct 13, 2008, 03:49 AM

Also, if I want to modify a chunk’s contents (not its placeholders) programmatically, it still looks like I’d have to user $chunk->set(’snippet’, ’newValue’);

Changing the source code for a modElement is a content management operation and should generally be performed through the processors in the model. Can you give me a scenario for modifying a modChunk’s fields outside of content management operations?

As for migration, if the field names are going to change, it might be better to break their code now rather than later before many add-ons are converted -- or to build in an alias in the functions that use the field name. Just my $.02.

I disagree, introduce the new way on top of the old structures, get them converted to using the new API with a version for cushion, and then start changing the model to get where we want to go. At that point, the objects can have aliases for the changed field names to prevent breaking any code that does reference the old column via the new API (vs. direct SQL which would no longer work at that point at all).

Not sure which statement you are saying "nope" to, but I think the placeholders definitely got replaced when I tested returning the raw content of a chunk from a snippet (though maybe I’m misremembering). I can see why you wouldn’t normally do that. If I’m right, though, it sounds like the placeholders could be being replaced twice, once by the chunk’s process() method and later, possibly by the document parser. If I can find some time, I’ll check it out.

How about a search and replace module for chunk and resource content? Or a version control system for site content?

I’m currently using it because I stash some info in a chunk and modify it automatically based on the local environment the first time a snippet runs. I understand that you wouldn’t normally access the field content directly, but MODx developers are always getting their hands dirty.

Ok, but if the aliases were there now, we could make the field-name change now without breaking any code. I don’t see the advantage of waiting, but I’m probably missing something.

I hope these discussions are at least a little productive and I’m not just wasting your valuable time.