DD4T and deeply nested components

Question

We've an implementation where we are using the DD4T framework. Some of our pages contains up to 5 levels of nested components:

• Page
  • Component embedded into page (with CT 'blah')
    • Component embedded into component
      • Component embedded into component
        • Component embedded into component
          • Component embedded into component

Something like that ^

When we publish the page we'd like all the components to publish to the broker (all comps are dynamic and associated to dynamic cts).

I've seen in the templates there is configuration for 'Merge Action' and 'Number of levels for links' and so on.

To fire that they all publish, i've thought about the following:

• doing nothing, tell the customer to check the 'publish components' check box in the publish dialog

• a tbb to trigger the publishing of these components directly

• reviewing if this is possible using a custom resolver

Just wondering if there's some other advice out there. I'm looking for a simple solution that doesn't kick off a load of unnecessary publishing.

Thanks in advance.

John

Answer 1

Just to check, and apologies if I've misunderstood this: Do they definitely need to be Dynamic CTs? DD4T doesn't require CTs to be marked as Dynamic.

Are you using these Components in normal Content Delivery API queries? If not, they don't need Dynamic CTs.

If you just want to have the linked components available to the "blah" CT: all you need to do is set the link level to 5 on the Generate Dynamic Component TBB parameters on the "blah" CT in your example.

The XML for all of the Components will be included in the XML for your Page in the PAGE_CONTENT table in the Content Data Store when you publish it and so available to be rendered as part of whichever view you have specified for the "blah" CT.

Answer 2

For the options you mentioned,

1. Do nothing? You'll need an extension to automatically publish component links (afaik).

2. By TBB yes, like auto-publishing multimedia components.

3. Custom resolver, yes. Especially if you want to prevent the other scenario when an editor attempts to publish one of the deeply nested items.

I'd suggest revisiting the content model, but figure you wouldn't be asking if that was really an option. If it's a many-to-many relationship, then simplify with taxonomy (keywords). One-to-many? Folders.