4
votes

I was studying the new feature of AEM, "Content Fragments", introduced in AEM 6.2 and further enhanced in 6.3, however I am not very clear about the actual use-cases of the Content Fragments and need more insight.

  1. The Content Fragments are suitable for long article pages or news pages, but I don't think it can be used for all types of authoring right?
  2. Suppose, we have Article Pages and News Pages in our website, both of which are created everyday, so authors can create those as Content Fragments instead of authoring those as pages? Is that right? And once the authors have created the content fragments, are we required to write some workflows/event listeners which automatically create pages for them?
  3. Also, as Content Fragments are only about content and not layout, so we need some component which will take its content and render it in the required layout. What happens when we want different layout for different content fragments for Article and News Pages? Also, in a dialog we can ask author to provide the summary text, description, author, date and article body, which is displayed on the page, however how will these different fields be written in a content fragment and how will component recognize which part is what?

I have some other questions as well, however, the above three would help in really understanding the actual use-case scenarios, for which this feature was created.

Regards, Gaurav

2

2 Answers

4
votes

Content fragments are, simply stating,

  • Reusable content
  • Channel (or presentation) agnostic

Based on this logic:

The Content Fragments are suitable for long article pages or news pages, but I don't think it can be used for all types of authoring right?

No, long pages are not fragments and most fragments would be text wall or simple paragraphs with minimal layout dependencies. Creating full page contents as reusable fragments will be counter intuitive.

Suppose, we have Article Pages and News Pages in our website, both of which are created everyday, so authors can create those as Content Fragments instead of authoring those as pages? Is that right? And once the authors have created the content fragments, are we required to write some workflows/event listeners which automatically create pages for them?

Again, this is one possible use case although there could be other alternative solutions. If articles are created and reused across channels then this would be a perfect case. However, like you said, you will need additional logic (workflow or similar) to listen for these new content fragments and insert them into channel specific pages. This isn't the most elegant solution as authors don't get a lot of control on WYSIWYG authoring features.

Also, as Content Fragments are only about content and not layout, so we need some component which will take its content and render it in the required layout. What happens when we want different layout for different content fragments for Article and News Pages? Also, in a dialog we can ask author to provide the summary text, description, author, date and article body, which is displayed on the page, however how will these different fields be written in a content fragment and how will component recognize which part is what?

Yes, this should be covered by your page templates or components with associated styles and scripts.

Content fragments are more advanced version of old school sling reference component. If you keep the content simple, it becomes more reusable across pages and components. A good example would be footer or header content or things like legal disclaimer that needs to be displayed in various places of the site.

Another way to look at it is to simplify authoring. You allocate content creation task to simple authors. More advanced authors can then pull in the content as they see fit for the pages.

Hope this helps.

1
votes

You need to think of content fragments literally as reusable content if you want to make use of this feature. A lot of content sites struggle to utilise this concept because the authors fail to identify the reusable content.

A few common use cases would be

  • Disclaimers
  • Footnotes
  • Common content (like an employee or product brief)
  • Time sensitive content

Anything which needs to be authorable and be displayed in multiple locations across the site is a potential candidate for content fragment.