Accessing Container fields from Containable

Topics: General, Writing themes
Jan 5, 2012 at 9:22 PM

Is is possible within a template (e.g. Content-MyContainableItem.Detail.cshtml) of a contained item (something w/ part Containable) to access the fields of it's Container? So within, Content-MyContainableItem.cshtml, I am using shape tracing to try to find one of the fields from the container.

Apologies, as I think I've seen this come up in other discussions, but I can't seem to track it down


Jan 5, 2012 at 9:26 PM

It should be possible yes. What happens when you try?

Jan 5, 2012 at 9:39 PM
Edited Jan 5, 2012 at 9:39 PM


Jan 5, 2012 at 9:45 PM

Well, shit. That's what I get for posting in haste. :-)

So, it's there, under Model.ContentPart.Container, the first place I looked before.

Thanks for quick response Bertrand. I love the CMS, by the way. Really getting good results.

For someone who might stumble on this later (and is new like me), when Shape Tracing doesn't give you what you expect (or know is there), here's what I just did:

  1. "Turn off" all custom Theme templates (or most of them) by just prefixing the offending template's filename with an underscore. So any mistake I might have made in that template is not keeping Shape Tracing from showing what is there.  I have found the default behavior of Shape Tracing to be fairly reliable. It's when I muck around with templates that I see it leaving fields out, etc.
  2. Comment out all <Place /> lines, or at least the suspect ones.
Jan 5, 2012 at 10:00 PM

Shape Tracing tends to lose the plot a bit if you have templates with no markup in themselves, i.e. a template where you just had:


The reason being that the JS markers left by shape tracing have no actual element to latch onto.

Jan 5, 2012 at 10:13 PM


That makes total sense and it explains my early failed attempts at stripping that "extraneous" markup out. It was particularly nasty with Zone templates--which I'm finding very little need to customize. What I realized is that overdoing the cleanup is counter-productive. The markup is generally semantically correct (or very close) and I realized that it was the markup that Shape Tracing was using as hooks, as you're saying (not the data--since it's JS, it really can't use data to "find where to go". You have to put the "shape-id" onto something)

And not to ramble on too much about this, but I reinforces the importance of the file instead of going crazy with @Model.ContentItem.BlahBlah in your templates, which took me a while to grok.