Ditto and documentIdentifier

I am working on a snippet that grabs document info for the page it is called from using $modx->documentIdentifer. When this page is aggregated by Ditto, the snippet call on the page gets the Ditto pages documentIdentifer. Is there a reliable way to get the page’s doc id for retrieval of properties and TVs specific to that document when every iteration of that snippet shows the Ditto doc id instead of the documents doc id?

Instead of just placing [[Snippet]] in the doucment content, the only solution I have so far is to pass an $id parameter.
It seems unnecessary to call [[Snippet? &id=`1`]] on page 1, [[Snippet? &id=`2`]] on page 2, [[Snippet? &id=`3`]] on page 3, [[Snippet? &id=`etc...`]]

I use allways the ditto-placeholder [+id+] to get the documentIdentifier of the related documents. Is it that what you are looking for?

Quote from: Bruno17 at Jun 07, 2009, 10:40 AM

I use allways the ditto-placeholder [+id+] to get the documentIdentifier of the related documents. Is it that what you are looking for?

[[snippet? &id=`[+id+]`]]

That is what I am doing right now, but it seems superfluous to have to push an id parameter. The other issue was that [+id+] only gets set from within ditto, so extra logic has to be added to the code to check if the id parameter is (string)’[+id+]’ and if so, replace it with (int)$modx->documentIdentifier, in the case that the document is viewed outside of a ditto aggregation.

I was hoping for a more elegant solution. This will work, but it certainly isn’t ideal.

I might look into the ditto snippet and see if I can override the $modx->documentIdentifier property with the id of the document being aggregated on each iteration.

Quote from: Dr. at Jun 07, 2009, 05:16 PM

I might look into the ditto snippet and see if I can override the $modx->documentIdentifier property with the id of the document being aggregated on each iteration.

Just note that $modx->documentIdentifier always represents the currently requested page in MODx, and modifying it is not really a valid solution to this problem. Processing dynamic content aggregated from other pages than the one you are viewing is not an easy problem to solve in 0.9.x/Evo in all honesty, simply because most components depend on $modx->documentIdentifier rather than requiring a specific value. The fact that source-order parsing of all tag-types is also not possible in 0.9.x/Evo can make it a real challenge to reproduce dynamic content in Ditto summaries (or any Document aggregation component).

Many of these challenges are solved in 2.0.0, but new components will still be needed to take advantage of these improvements (and are coming).

Thanks for the clarification OpenGeek. I’ll just leave it be and pass an id parameter.