Reading Time: 2 minutes

So, not too long ago I had the opportunity to sit down with Miguel Miguelez and Nuno Linhares, both from SDL. Over the course of one or several beers, we discussed the Frenchness of the French, super awesome tattoo ideas, and content injection. And we came up with an idea which I’d like to share.

Content Injection

If you haven’t read Miguel’s article on content injection, you really should because it’s a mighty dandy read. A few years ago, Miguel came up with an approach called “Content Injection” and he summarized the concept this way:

For nesting a component presentation within a component presentation the result of the render of the component presentation must contain a reference to the component presentations that will be nested in.

So we’re talking about nesting component presentations inside of other component presentations. If this concept doesn’t sound ground-breaking yet, let me re-iterate: We’re talking about injecting fully rendered content inside of fully rendered content. What Miguel described to me that evening was that content authors were able to do this via rich text fields. That’s right, a content author was nesting component presentations —with minimal knowledge of code.

Miguel accomplished this with custom elements following a bracket notation:

Using for instance the Bra-ket notation all the information needed for inject a component presentation in another component presentation can be represented as <PUBID|CID|CTID> where

• PUBID is the publication id
• CID is the component id
• CTID is the component template id

Introducing Angular.js

Angular.js is my new favorite toy. It’s a JavaScript-based MVC framework that was developed by Google, and it particularly loves Single-Page applications (SPAs). One of the features of angular.js is directives. In a nutshell, a directive is a marker on a DOM element. Assuming there could exist a component template called “articleList”, there are a few ways you can to create such an angular directive:

• <cp-articleList></cp-articleList>
• <span cp-articleList="12345"></span>
• <!-- directive: cp-articleList 12345 -->
• <span class="cp-articleList: 12345;"></span>

What’s cool about angular’s directives is two-way data-binding. So what happens in the Session affects the DOM, and what happens in the DOM can affect the session. Adding or changing HTML can trigger actions to happen in the background.

Where am I going with this?

Miguel’s approach currently only injects content at either delivery or page request. But what if it didn’t have to?

What if angular did it in the component:

You see, angular directives aren’t just for creating custom pieces of HTML. They’re made for you to tie complex functionality, including ajax requests, to a simple piece of HTML.

So, imagine what the aforementioned directive could do:

1. Identify the publication ID in the background
2. Query the Broker Database for a Component Presentation based on the CID
3. Resolve, within the component that a content author is editing, this directive into fully rendered HTML

So, why wait until we’ve deployed or published to see the content we’ve injected? We could do it right there in the component!

Not only that, we could create incredibly simple and semantic directives to do this; <cp-articleList></cp-articleList> seems like a very author-friendly way to do content injection.

In summary

This is only a thought experiment; I don’t yet have a fully vetted idea of how to turn this into a Tridion extension. But the idea is simply that Miguel’s content injection is pretty cool and that theoretically, through angular, we don’t have to be limited to just waiting until delivery or deployment to see what happens.