I have a scenario where I have components with parent-child relationship. For instance, a news can have multiple child news component.

The pages for each news will be created under its parent news.

Example: /news/parent1/default.aspx will contain a component presentation of "parent1" along with its CT. And its child "child1" has page at "/news1/parent1/child1/default.aspx".

I need to determine the parent of "child1" while rendering the page of child1.

One easy way is to have a "parent" field for news component and select the parent component in child news component.

Is there any other way to get the parent news component from structure group hierarchy of the page.

Please suggest the approach to determine the parent using structure group pages and also let me know if it requires a C# TBB on the page. I will be passing the TCM of child as well as its parent news to a user control while rendering the child news page.

This user control requires current news component tcm and its parent news tcm to render other news summary on that page.

  • Do authors need to create a Structure Group for each page? Are they all named Default.aspx? Commented Mar 2, 2015 at 23:15
  • Yes Alvin. Author will create structure group for each new news and all pages would be default.aspx. We have already implemented it by having parent component link in child component but since they (authors) are creating the child page under structure group hierarchy of parent- thus they don't want to tag them again by linking parent component. On child news page we are supposed to render another dynamic presentations of all news except its parent news. Commented Mar 3, 2015 at 2:20
  • Okay, so having a News schema and probably dates help with getting those News Dynamic Component Presentations (and in reverse date order, probably). I would agree with the authors--they shouldn't need to manually add something they've created. It's functionally similar to outputting a breadcrumb based on page location. :-) Commented Mar 3, 2015 at 15:32

2 Answers 2


Let me use an explicit but hypothetical example to add an answer. It looks like a "Parent" is a News Topic or event of sorts, which can have individual News Stories. For example:

  • /News/Weather/Default.aspx
  • /News/Weather/SanDiegoRain/Default.aspx

So the requirement is to know or maybe render something related to "Weather" while on the "San Diego Rain" page?

Note: the folder paths do not need to be based on Structure Groups. If using the Content Delivery API, (custom) metadata or Taxonomy could relate the Components so that you can retrieve other Weather-related items from anything tagged Weather (Parent1).

If you can flatten the Structure, you could instead have:

  • /News/TopicA/Default.aspx
  • /News/TopicA/Story1.aspx
  • /News/TopicA/Story2.aspx
  • /News/TopicA/Story3.aspx

Then you can get the location of all the stories under Topic A based on Structure Group location. You can use a page link in template code to resolve it correctly as well.

Though the parent field would work, from an editorial perspective the CMS user already created these relationships with Structure Groups and Pages. They shouldn't need to add another link to further relate the child items to their parents (be careful with "child" and "parent" since these can be confused with BluePrinting). This also assumes there's only a one-to-many relationship between the News Topics and Stories ("parent" and "children"). What happens for stories that belong to multiple "parents?"

Technically, C# TBBs don't go on pages (they can go on Page Templates). If not handled by the Page Template you might have a "dummy" Component Presentation that editors place on the page to add some type of in-page navigational element. The Component might be called "Section (SG) Nav" or similar.

If you do use Component links, consider flipping or otherwise changing the requirement. For example:

  • The "parent" component links to its "children" -- this creates a "related links" type of relationship.
  • Tag Components with topics (Keywords) so you can find related items regardless of Structure.

I'd suspect Taxonomy might be the better fit for the requirements here, which would be easier for editors creating the relationships, developers working with the requirement (which might evolve), and for visitors finding related content.


The complete answer will depend on your implementation. Basically whether the parent child relationship is managed through BluePrinting (child websites) or if you are simply talking of related articles which have a ComponentLink field to link the main news to the related news articles?

Either way you can use a C# TBB in your page template to read all components on the page, and if the schema is News, then call the Where Used functionality programmatically. See GetUsedItems and GetUsingItems methods explained here: http://codedweapon.com/tag/getuseditems/

Also check this post for an additional code sample: How to retrieve parent component object from a localized component using Tom.Net API?

Reading the parent component from the Structure Group hierarchy does not seem to make much sense, but you could have a ComponentLink field on the parent Structure Group metadata and check if that field exists from the child page template.

I would go for the ComponentLink field to point to the parent component so that the relationship is clearly defined in your content, not simply dependent on page/SG hierarchy.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.