Adobe Experience Manager Sites Basics

Learn how to create rich and engaging customer experiences in Adobe Experience Manager in this 5-part webinar series. We will start with the building blocks of content authoring while introducing you to the fundamental concepts and operations. This will include sites admin features and basics of handling digital assets within AEM. In the later part of the series, discover features that can help you save time and be more efficient by re-using the content and delivering it across channels.

The Web and Beyond - The Power of Traditional and Headless Content Management

Transcript
Hello, everyone, and welcome. Thank you for joining today’s session of our Adobe Experience Manager Sites headless hybrid deep dive theories; The Web and Beyond: The Power of Traditional + Headless Content Management. My name is Anu, and I’ll be your host for this session. If you haven’t already, please take a moment to respond to the polling questions on the screen. Today’s session is approximately 60 minutes and is being recorded for future on-demand viewing.
During the presentation, you may enter questions at any time in the Q&A pod on the left hand side of your screen. We will address your questions as we go along and also at the end as time permits.
Joining us today is Luis Duarte, Adobe certified architect and authorized instructor for AEM. Luis, you now have the floor.
Thank you, Anu, for the introduction and welcome, everyone, to our first webinar of this webinars series, which is the AEM Sites headless hybrid deep dive series, where we’re going to explore from the perspective of front end and for front end development, how AEM provides what you need in order to deliver headless content, and while also providing a traditional way of working with content. So today in our first session will be the web and beyond: the power of traditional and headless content management. Now, before we tap into the actual meat of the session today, just a few items here on the agenda. First, we’re going to do our quick review of the whole program, of this skill builder series. Then we go into the actual contents of the day, and at the end, we’ll have a quick Q&A, okay? Just before I get started, once again, my name is Luis Duarte. I’ve been working with AEM for the past 10 years as an architect, a senior consultant, and also as an authorized instructor. And I will be glad to help you out and guide you through this process of learning this aspect, very important aspect of AEM, okay? So day one is, as mentioned before, the power of traditional plus headless content management with AME, okay? That’s today. We’re basically going to cover everything today, the whole series, the whole session, or three weeks of webinars is kind of condensed on today’s session.
With our initial sort of going into the motivations and why we do these sort of hybrid approach or what’s the benefit of these hybrid approach? And then on the second day, we’re going to delve deeper or dive deeper into the features and the support that AEM gives you to create single page applications and be able to edit those single page applications in-context. Then we’re going to look at, on day three, at the whole ethos of AEM of to create once and deploy everywhere and update once and deliver everywhere with content fragments and experience fragments and how those also have different ways of getting delivered, both in a traditional way, as well as the headless way, as well as authoring them in both traditional and headless manners. And then, on day four, we’re going to go into how we can create API endpoints with the AEM Content Services API, so that these constant services API endpoints can be consumed by third party applications or other applications that you may have on your setup channels and get that content from AEM.
Okay? Now, in addition to these sessions, we have also some other skill builder stations around AEM that you may want to explore. Here below is our link that you can go to so you can learn more about them. Okay. So without any further ado, let’s get started now with today’s session. So today we’re going to explore headless and hybrid content management with AEM and see how AEM provides development teams ways of delivering content which are flexible. So you can think of AEM of delivering content for headless as well as traditional CMS. But this flexibility doesn’t come at the price of marketers not having or not retaining rich authoring capabilities. So basically how can you provide an AEM development team a flexible way to deliver content while still retaining those rich authoring capabilities, okay? All right. So first the agenda for the .
So today we’re going to first explore the difference here between the two types of CMS architecture and how AEM.
Then we’re going to go into how AEM tackles both aspects.
And we’re going to explore how AEM gives you in-context editing capabilities, as well as traditional CMS, that we’ve already have content in HTML. Then we’ll progress to understand how AEM, while still retaining the rich authoring capabilities provides also a way to deliver headless content that can then be used on a front end application, such as for example an SPA. We’re going to delve into the SPA Editor for AEM.
We’re going to explore that and then learn a little bit about that one. And this is the next day that actually we’re going to be covering in more detail on the second day of the webinar series. Then we’re going to move on from the headless, sorry omnichannel content re-use side of things. We’re going to define and understand what content fragments and experience fragments are, how they’re used and what they’re used for, what’s the whole expectation of those. what is the difference between them? Now there’s a little bit of confusion among developers specifically as to what is the difference between experience fragments and content fragments? So we’re going to try to also make sure that’s clarified. Content Services API channel pages. This is for creating end points that you can manage in AEM as you would a pages, AEM pages, but these AEM pages become API endpoints so that you can have in AEM and create using the standard page editor. And last but not least, we’re going to talk about the HTTP for the AEM Assets, the HTTP API, the basic any concept of that. Now, what I want to do now is just a heads up, even though these theories is geared to front-end developers that are going to develop against AEM, that doesn’t mean that an AEM developer that does back-end development, or maybe an architect, solution architect, or maybe a product owner or business analyst, wouldn’t derive value from the series. So stay put and make sure that you also pay attention even if you’re not a front-end developer, okay? So first the headless CMS concept.
Basically a headless CMS allows you to have a centralized content management system where authors the content or marketers the content, but the delivery of that content, the actual rendering of that content and putting together of the pieces is done by the client application. For example, applications such as a single page application, okay? So as you can see, this is great for those kinds of use cases. You have an SPA, and then you can create a very personalized interactive experience with that application, okay? And this is something that visitors have come to expect. Okay? This sort of a native feel to the application where pages don’t get reloaded every single time you click on something. So that’s great, okay? It supports that use case and many other ones. The whole deal here is that you get great flexibility for your development team to then reuse that content that you’re creating, managing centrally on a headless CMS and use that across the different applications that cater to the different channels that you want to cater to, okay? So that’s great. So that would be the good things about headless CMS. Now there are some aspects that can be either good or bad but it depends. For example, the way in which we author content in headless CMS is a form-based type of, using a form based type of editor. You fill up fields. And that kind of helps in making the content creation a little bit faster and more efficient. You can create more content at scale using this approach.
Okay? And additionally, you have the development team controls the layout all the time. So that means that you don’t have to deal with maybe an author that is composing a page or something like that and break something, or maybe they are not well trained and they ruin something on the layout or on the presentation. So a good thing that you can control that and basically bulletproof or at least have the possibility to bulletproof your application from those sorts of user costs, user cost issues, okay? But there’s another side to the point here. So in the case of marketers being able to edit the content, a from based type editor, when they are doing that, they are basically relinquishing the ability to control the layout and the presentation, okay? And thus also relinquishing the ability to control the customer journey, okay? And in the case of IT, then you can become a bottleneck, okay? Because any changes, you are controlling the in the presentation and an application for a particular presentation layout in now, after your work, you begin to get requests that the new content needs a different layout, then you once again have to go through the whole development process and you have the development team become a bottleneck that basically requires everything to go back through the same cycle and it’s going to make it slower. So content velocity gets affected there.
And here’s where things get a little bit uglier. So markets nowadays do really want to control the customer and own the customer journey, but the presentation and the layout, once you have created an application, maybe you use the headless CMS and you create an SPA for example, when the application in its initial rollout was a complete success, everyone was happy. Okay, did you get native field through your application? But then you have to evolve through time. Maybe you’re going to localize it for different markets, or maybe there’s some changes that need to be done to a layout. Now here, the market, there has to go back and basically have the development team recreate something for specific things that maybe could have been done by themselves had they had a traditional CMS in this case. Okay. And then marketers, they also want to have a coherent content strategy and that’s across all channels. That means if they create the same messaging and they expect the same messaging to be delivered to all the channels, maybe with some adaptations, but in general the same messaging, okay? But the problem here is that if you have a different channel, let’s suppose that you have an SPA, for example, and some other channels mobile application and . You have another network channel or other traditional web channels where you want to also deliver that messaging. So those traditional web channels may have been built on a different CMS with have different, basically conforming a separate content silo that provides its own way of rendering and managing the content. And then you have to, as a marketer, go and resort to copying and pasting from the CMS, from the headless CMS into your other content silo, okay? So what this means is that maybe the headless CMS, even though it is very great in providing RESTful API kind of API for you to do act as the content. Okay? This is great for development things, okay? To develop against that if you’ll have another content silo, another content management system where you need to get that content automatically, it’s not going to be that easy, okay? In the end marketers are probably going to end up copying and pasting, okay? So what about contrasting headless CMS versus traditional CMS? And we’re going to do it by two aspects of content management. One is in-context editing or authoring, the authoring experience, that is. And other one is the delivery of the content, okay? So first in the case of the headless CMS, the authoring is form based, okay? And the delivery is done through JSON. So you would send out, or you have a JSON object that you expose or if there’s not contract or on our RESTful API that front-end developers are going to develop against. Okay? Now, in the case of traditional CMS, you have traditional in-context authoring, okay? And then the delivery is in HTML. So if you could kind of like the quadrant where traditional CMS lives, okay? So you have traditional delivery in HTML, in-context authoring so that the marketer or the author can see the content they are authoring the pages, okay? In case of headless, it’s this quadrant that is the most important one. Then basically, you edit your content in a form-based editor and deliver it via JSON, okay? But in addition, both headless and traditional have the ability to have something else. For example, the headless can also, in some cases, deliver HTML but that’s not the main goal. And in the case of traditional, they also have, in some cases, the ability to author in a form-based manner, okay? After that, besides the in-context , all right? Now, in the case of experience manager, Adobe Experience Manager, blows away the whole dichotomy here because it covers all bases. As you can see in AEM, you can have provisional in-context editing and render HTML, deliver HTML, which is the typical use case, okay? When I say render HTML, I basically mean the server side, the AEM server takes care of doing that rendering, okay? But you also have the ability to do in-context editing or authoring while also delivering JSON, okay? As well as you can have the ability, the AEM to offer in a form-based editor type of way, okay? While also delivering content in JSON or HTML.
So you can deliver the headless authoring in HTML or JSON. And you can deliver the in-context edited content either in HTML or JSON, okay? So if you want to learn a little bit more about that comparison of the two architectures, you can look at this URL that I have here at the bottom. You take note of that.
Okay. And what I want to show you now is first, how does AEM go through the different quadrants here? So first going to explore how AEM is the traditional way of doing things so you get out a nice footing for understanding that the rest of how AEM works, okay? So let’s start with last traditional in-context editing plus traditional HTML delivery in AEM. So for that, let’s first explore the page editor the components, we’re going to go into HTL and look at the HTML output, okay? Well, let me here. Let me go here into AEM. All right. So if you’re on AEM, this is your first time looking or seeing AEM, the case, or sometimes from some front-end developers, this is what you see first, the main navigation. If you go into Sites, this is the site’s console and what you need to know is that AEM is built on top of a hierarchical tree of modes, okay? So if you’re going through these We Retail site, you can see that the pages are hierarchically laid out, okay? And on top of these hierarchical repository, which is called Java Content Repository. So as you begin to navigate and expand different levels, you begin to see what’s inside in terms of pages. So these are the actual content hierarchically laid out. And now I’m going to go ahead and open one of these pages for editing. Now we’re going to see how we can edit in-context, okay? So I open the page editor by selecting that page. So once again, I just selected it and then clicked on Edit. Okay? And while here, what we need to understand is this is a what you see is what you get type of editor. When you are hovering over anything, you can see that the components that make up the page get highlighted, they give you a way for you to edit the components in the context with where they are going to be delivered to the browser, okay? And you can also do dragging and dropping. So for example, if I go here into the panel, I can search for… I can point here, let’s search, for example, for “Title”. Going to our title component over here. I can just go ahead and drag and drop that title component. Okay? And then I can just, if I want to, I could actually move it and put it up here, okay? So this is in-context page authoring, right? I’m going to just change here this, instead of it saying “EXPERIENCE”, I’m going to make it say “EXPEDITIONS” or something like that, okay? Let’s suppose that I don’t like this type of heading. I can change the heading, which to H2, for example.
Okay? And now I have basically shown you the authoring, right? But how does this look in terms of the rendering? So how does this authoring in-content get accomplished? So I want you to make a mental note or a mental bookmark of this component over here. This is called the responsive grid or the layout container. So in the backend, we call it responsive grid, but here on the user point of view, you see it as layout container. Take note of that responsive grid. This is the one that allows us to drag and drop components onto the page, okay? But how does the page actually get rendered in AEM, okay? So the way which that works is AEM works with a web framework is called Sling, okay? Which is RESTful resource centric web framework. We can begin to explore that here by changing from edit mode, into developer mode over here. And now I can basically click on any of these components. Let me refresh the page for a moment so I’m actually able to click on the title component that’s over here. If I click on the title component, on the left hand side you will see that on the first tab, we can explore the components on the page. You can see that these Sling web framework works in such a way that allows you to have a page view rendered by delegating the rendering of the individual pieces that make up the page to components, to AEM components. So you have the page, which itself is a component, but then there’s multiple components that render the individual pieces of the page. Since I clicked on this component, this left hand side panel opened up directly at some point. So you got the item on page. Then there this responsive grid. Within that responsive grid, we have this style component that I just clicked on. And here I can begin to see the details of that title component. So if I click here on View Details, for example, this will show me what is the content path, the resource, that this Sling web framework is rendering so you can see this title. It has the path. Like I said, it’s a hierarchical.
And these notes are regarded as resources by this web framework called Apache Sling, okay? So you have title, okay? And that is the actual content. And Sling, this web framework, will figure out that to render that content, that resource and we’ll come up with a script that we’ll take care of that. So I’m going to open this script by clicking on this. If I click on this one, this is going to open the CRXDE Lite. This is basically a web-based IDE that allows us to explore the JCR and look at the components that render the content. So here we have the title.html that is in this case in charge of doing the rendering. This HTL scripting, okay? This is also part of the Sling web framework which was developed by Adobe and given over to the Apache Sling project, okay? And this is basically HTML script. So our initial script is an HTML5 script in terms of it doesn’t break any of the standards of the HTML5 certification. But in addition, it gives us the possibility to ingest or embed backend properties through expressions and block statements onto a script. For example, you can see here. We’re making a reference to a backend Java class, which is called a Sling model. And this Sling model is basically modeling the title and will give us access to the actual value of that title that we want to display. And we can see here that we’re accessing that here when we say title.text, okay? So that’s basically the front-end rendering or how the, sorry how did the HTML backend rendering of AEM works. It works with this HTL scripting technology, okay? If we go back into the Experience the page, we can actually also see this in the way a site visitor would see it is to see how this gets delivered and rendered, okay? So I’m now looking at this as a site visitor, okay? And if I go ahead and click here on, click on…
Oh, go back. Want to go and view the page source.
View Page Source, okay. So I’m going to look for that title that we just had a look at, cmp title.
Okay, so here’s the actual end result. This is the piece that gets rendered for the site visitor to see on the browser, okay? All right.
Let me now go back presentations we can.
So what else? So we have just seen that way of in-context authoring, okay? And the traditional way of delivering HTML that is composed on the server side, using this HTL scripting language. But AEM also us another possibility. You can actually have, you have seen how we have authored in-context. But we can have that in-context of the content be delivered through JSON, okay? This is where AEM Content Services kick in, okay? So we’re going to explore right now our regular web channel page, just like the one that we just saw and see how we can see it’s JSON representation, courtesy of AEM Content Services. Let me go back here. Now I’m going to close these and I’m going to change this a little bit. Notice the following. So I’m going to add the word model.json here, okay? So model would be what we call a selector and JSON the extension, okay? And what happens is that from now AEM will show me a JSON representation of the whole page that we’re looking at. So we are looking at this page. Notice the path: content/we-retail/language-masters/en/experience. Okay? And if we look at this page from the perspective of the repository, we can search for it under that path very quickly. If I go into content, we-retail, language-masters, en, experience, okay? This is the actual page that we’re looking at, experience, and here’s the whole set of nodes or hierarchy of nodes or branch of nodes that exists within that . So we have this JCR content and this whole tree of nodes below it. So how does that get represented here on what we just did? So we can see that we have all of these properties here. These actually map out to the properties of the page which exists on these JCR content. So you can see the title, okay? And we can also see the title over here, okay? Of the page. But in addition to that, notice that there’s some items here that have a column at the beginning, they’re presented with this column. Now, this column that you’re seeing here is coming from the fact that as we saw when we’re looking at the HTL script, okay? We saw we can map the rendering of the component to a backend Java class, a backend Sling model. In this case, it was the title model. In that case, it was the title model. But in this case, it will be a page model that allows us to also export using a Sling model exporter export the content as JSON, okay? And there’s different, or several Sling model exporters are in here. For instance, we found the container Sling model exporter, which you basically called when you are rendering a page and that’s why you see column items and column items order. Why is that important? Because the items that’s basically the whole branch of content we need the page itself. So you have experience, and then you have JCR content. There’s a bunch of nodes over here, but we need to somehow get that into a JSON so we have here items and routes. And if you begin to dive deeper into that, you will begin to see all of those nodes being represented there. Additionally, all components in AEM will also have the component exporter which will provide the column type property, which tells us what is the backend component that is actually dealing with a vendor, okay? If we think deeper into the items, so we can search for that title that we just worked with, and that we edited in-context, you can notice that… Let me for a moment just collapse everything here. So you can see that there’s this root node. And within that root node, then we have another item because this one has child nodes as well, okay? And then you have this responsive grid. Remember I told you to make a mental bookmark of the responsive grid, the layout container, because that’s where all the components that you drag and drop and dump. Now, but this responsibility that we’re looking at is actually the full responsive grid that it was already there on the template that we can actually work with. But there’s another one that this contains, this one itself contains which is this one. So you have this responsive grid. And then within that responsive grid, you finally begin to see the actual components that you have on the . So here we have the title, okay? And then we have the values that we set up there. So you can see the H2, you can see the expectations, okay? Link disabled. So these are basically the property deposed by the Sling model that kicked in here when this piece of the JSON got rendered by the exporter, by Sling model exporter. So in this case, the title Sling model exporter kicked in and it gave us these properties, okay? Now the title itself is here, We.Retail.
There’s a part of this we retail reference site, okay? But it itself in based out of what we call a core component and all of the core components in AEM, we’ll give you for free the ability to export in JSON, because they already have their own content exporters or model exporters, Sling model exporters, developed there. So if you’re using a core component, you’ll get out of the box the ability to get the JSON representation of that particular component. You can also pinpoint a the specific component instead of rendering the whole page like we just did. We can go ahead and render just the specific component. Okay? For that let’s suppose that I want to render this style component specifically. I’m going to go back here into the JCR repository and find that node. So remember have root, then we have responsive grid. Within that responsive grid, then we have the title, okay? And I’m going to use this part of the path so I can put it on the address bar, okay? Copy that.
Go back over here. And now I’m going to basically upend that here. So basically, I am referencing the exact path to a title node, which is the resource that holds those values for the title. And I’m going to that model.json and this will make that title Sling model exporter fit in.
Okay? And we can pinpoint that. All right. So all of this is powered by this the AEM Content Services and the Sling model exporters and Sling models. If you want to learn more about that, there’s also a few links here that you can have a look at. So basically all is based on the Sling models on the delegation pattern for Sling models. You can see these links here at the bottom, and there’s a host of documentation pages that you can look at to learn more about this. So let’s keep going now. Okay. Now let me go back for a moment here to our quadrants. So in what we just did, we just saw that we did in-context editing. We dragged and dropped the style component, moved it around using the page editor in AEM. And then we saw how, aside from not just being able to render it as HTML, we also hope so how we could render that, not just the title, but the whole page, as JSON. Okay? But my question here is so did we actually do in-context editing for something that we then deleted it JSON? Did we actually do that or not? Okay, so I want to explore that question. So for now, let’s go back here and here’s three possibilities. So first we’ve got think of this as, well, we’re actually not, we were not in-context editing or authoring in-context for this same application that would actually consume data because the application for which we were editing in-context was the traditional web application that would render in HTML, okay? That’s what we were rendering context actually, okay? But if you have another application that is going to consume the JSON, okay? That other application is still going to have to provide the layout and the presentation, and it’s going to manage that layout and presentation. So it’s basically that we are not actually rendering in the context of that layout and presentation that will be provided by that third party application. So we’re not actually seeing that, okay? So unless that application goes through the pain or complexity of making sense of that JSON that got delivered, use of the JSON as sort of hint as to how to the layout, okay? But of course that would be complex, okay? And actually in the end, that’s something that the AEM SPA Editor and the AEM SPA applications, or the AEM SPA JS SDK that we’re going to explore on the next webinar, it actually gives you that. So if you end up doing this, then you’re basically not taking advantage of that, okay? You’re doing the complexity yourself. But now does this render what would just be useless? If this useless being able to author a page and then deliver the page in JSON and individual components in JSON? No, it is actually not useless because it’s useful for some use cases where authors won’t care much about the layout. So if you’re creating a page, okay? That is going to just hold a set of components with content that you want to expose as JSON that you don’t care so much about the presentation itself, you just care about what components they are there, okay? Maybe in what order as well, but not so much about the presentation, then in that case, this would be useful and we are actually going to explore this whole way of thinking on our fourth webinar in this series where we explore the AEM Content Services channel, sorry, the AEM channel API endpoints, okay? With Content Services, to consume them from a mobile application, okay? The second possibility with what we just did is that, okay, so maybe the AEM server web application will leave some fragments of the HTML that is rendering and produce will move some fragments off to a JavaScript framework on the front end to fill up, okay? Okay. So the problem here would be that if you are expecting your pages, as you are rendering to, when you open a dialogue for one of those components that is being rendered by the JS framework, if you expect that when you click on the dialogue and you enter a value there, and when you click Okay that then immediately, you’re going to see without refreshing the whole editor, you’re going to immediately see the effects of what you just moved reflected on the page.
Then you’re going to be in trouble because in order for that to happen, there needs to be messaging going on between the AEM page editor, okay? And your JS framework. Your JS framework needs to know that when certain events happen on the editor, that he needs to re-render specific pieces of the whole application, okay? Also, in order to do it, you’ll have to either figure out a way to scrape the whole dump so you can find the components to render. So if you’re leaving certain aspects of the whole HTML, so there are some aspects that you’re leading up to the front end application to the render, you have to know when those front-end components have to instantiated and when they should kick in, okay? So in order to do that, you have to either scrape the whole dump and be able to identify those components and render them when needed, okay? Or you have to make every single component a full front-end application so that every time you render the page, everything every single component knows they have to render in the front end, okay? And there’s another approach to this. So in this use case, basically what we’re looking at is, maybe you want to mix and match front-end component built with React and Angular, for example, with provisional HTL components. How would you go about doing that? So for that, there’s another approach that you can check out, which is the React component, which basically provides a way to do what I’m mentioning here on the second point.
It provides a way to scrape the DOM, and it also gives a way for you to identify which components need to kick in when, okay? Without having to create a full front-end application for every component. So that’s a good starting point for you to explore, okay? And then the third possibility. Now they’re actually there. We are editing in-context and delivering that in-content edited content. We’re delivering it in JSON for the same application. What would be that case? That would be when you have a full fledged AEM single-page application, okay? That means that that application will leverage the AEM SPA Editor, okay? Which provides also the AEM SPA JS SDK and the messaging. So then it’s going to add some thin layers to the editor and also to your application that will allow this messaging to happen so that components get re-rendered when they need to get re-rendered, okay? And we also deal with the mapping of the component that you have on the screen to the actual components on the page so we know which dialogues have to kick in when, okay? So basically that messaging and all of the DOM manipulation that is necessary for your front end components, your React components built for the SPA to interact with the page editor, okay? All right. So let’s go ahead and have a look at a sample SPA application here, okay? Let me go back into AEM.
And I have this WKND Events page or site, which is built with React, okay? If I come here to the Home, I can select this. We can edit just like I would with any other AEM page. The page editor comes up.
So in reality, there’s nothing, from the perspective of the author, there’s really nothing different happening. You’re still working with the editor. Let me make this a little so you get to see the whole window there. There’s really nothing special happening in terms of, apparently nothing special is happening, okay? Because you’re still seeing the editor. If I can open this and click on anything, for example, like I would with a traditional application. I’ll just add a + symbol there and it can automatically be rendered. So there is a title component built in React, which exists within this whole React application that is rendering everything that we’re seeing here, okay? And it did it automatically. I can also have a look at, if I create here, and we can view as published, okay? And see the page source.
Okay? You can see that this basically you have an empty body, okay? So nothing much there, as opposed to the other example where we were cutting all of the HTML basically delivered by AEM. Here we’re just delivering these div, okay? With an ID. If you’re used to React or Angular, this sort of framework will use it to identify where to instantiate the application, okay? All right.
Here.
All right. Now another important aspect here is with the SPA Editor or the whole site model is retrieved just once. And that includes all of the content that you’re seeing. That means if we begin clicking on items, like for example, if I go to the first article. And before, let me go ahead and open it up.
Right? Then open the network. Inspect Element here. The network console and clear this up.
, okay? And if I click on, if I refresh the whole page first, let me first refresh it, okay? We can see what are the requests that are being done. First you have the request for home HTML, okay? That’s the request for the actual shell HTML that we just saw, this shell in HTML that provides the ID where to render the React application, okay? But additionally, you can see we have this react.model.json request, okay? This is actually the model of the whole application. And if I click on any of these components, or links, sorry, like first article, for example. Let me clear this about here.
If I click on first article again, or second article for that matter, you can see that the only thing that got requested was the image that you have here, okay? But the text, the title, and all of those are aspects of the page, the header, everything else, none of that got requested again, okay? Because the model of the application is all contained within that route, that JSON that we saw the first request. So if I go back here to the, if I click here on this link, okay? Courtesy of have the model router, you can see that even though I changed the patient and nothing was requested, okay? The address bar did actually update, okay? The address bar keeps updating when I click on the links but the requests are not done. That is courtesy of the model router. We’ll go on to explore that on the next webinar. But the issue I wanted to point out the fact that there’s a model of the application that got requested here on the homepage. Let me refresh the whole thing again. Let’s make sure that we make the request just as if we are working from the perspective of our site visitors. I’m going to disable all the web content management features, the authoring and all of that is not requested now. And once again, I see the request for this react.model.json. Let me click on that. Here you can see that the JSON model for the whole application. If you look at the headers, you can see it being requested as content. We can react.model.json if we go back to AEM Sites. And now you get through that, we have WKND Events, React. That the actual path that we’re looking at there, okay? And then we have model.json, okay? Over here .model.json. So let’s go ahead and try that over here.
.model.
.model.json.
Enter. All right. So now you can see you have the whole model for the SPA application, okay? Once again, we have the column receiving some of the properties. That title, which is appropriately of the React App page that we’re looking at, this one. React App is the title of that one, okay? But then we have the path type items. So we have these path, hierarchyType, and children is added by the hierarchy node exporter, which we’re going to explore later. But what I want to point out right now is that this models will be having the whole set of child pages that this page has, basically in a flat list that you can see here, okay? You have the home, first article, second article, okay? And if whenever something is missing from this model, there is a layer of the AEM JS SDK that will know that it has to request for that specific piece, okay? Instead of having to request everything again. Okay. So we’re going to explore this in more detail on our next seminar. Last thing I wanted to show you is, of course, if I make a change here on the page editor, which you wouldn’t notice, you wouldn’t think that this is an SBA application from the perspective of a, at least from the perspective of an author, right? But it actually does update automatically. So if I go here and refresh this JSON. And this again, sorry.
Refresh this JSON requests. So we can actually see that title. How it got updated with the loss that I just added there. So you have items here on the responsive grid and you have home plus plus, okay? So these happening automatically there. All right? It is updating the model. All right. So what about content fragments and experience fragments? This is AEM’s way of feeding to the ethos of need once, re-use everywhere, or update once, re-use everywhere. But they have some though they have some commonalities, there’s some conceptual differences. Let’s first talk about context fragments at data for centralized management of textual data, okay? And creating and managing that data in such a way that it is channel presentation and layout agnostic, okay? You don’t care about presentation and layout, and it is up to a child to provide that, okay? This is managed as an AME asset so is using think the whole AEM asset module. And in order to deliver it on an AEM webpage, you have to use the HTL content fragments components and the content fragment leads components, for example. And these are core components of AEM, therefore they will give you for free as well the ability to get them in adjacent representation. All right? Delivery of components can also be done as JSON as courtesy of AEM Content Services, as I just mentioned. And additionally, you have the ability to get directly to the assets, to the content fragments, without having to put them on a page. So there’s two ways. You can either expose a content fragment by putting a content fragment component on a page, okay? And then getting that on JSON, or you can directly go to the AEM asset of the content fragment and use the AEM Asset HTTP API node to consume the contents of that content fragment. In the case of experience fragment in this case what we’re doing is we’re re-using an assembly and layout of components. So you configure, assemble and layout some components in a particular way based on a particular presentation. Okay? And then you re-use that across multiple channels. And the way in which you re-use that per channel is that you can create a variation for each standard channel of how you want to configure, assemble and lay out those components, okay? Through another AEM component, which is based out of the core components, experienced fragment components and it’s mostly meant for AEM based web channels, okay? So you want to re-use on your different web channels on AEM the experience fragment, but it also can be exported as plain HTML or JSON. And this is useful, for example, for exposing those experience fragments as Adobe Target offers, okay? All right. So what is the difference? As I said, the initial concept is the same. You basically want to be able to create once and re-use everywhere, okay? But that’s where the similarities stop, right? Because in the case of content fragments, what you’re re-using is textual content that doesn’t care about layout, presentation and channel. In the case of experience fragment, but you are re-using assembly and configuration of components that are done that is only a particular way and laid out in a particular way that you want it to cater to a specific channel, okay? So that means experience fragments don’t care about the presentation whereas the content fragments don’t. In both cases though, you have an editor. So you have a content fragment editor, which is your hub where you edit the content fragments in the text of the context fragment. And then you have an experience fragment editor where you edit the experience fragments and compose those experiences. Then you have the AEM Content Services API channel pages. We’re going to explore this on day four. Basically this allows us to leverage these Content Services that we just saw, where we were editing in-context. The first, then what I did when I was editing in-context, I added the title component to a traditional webpage of AEM, right? So I added that. And then I was able to see the whole page of JSON or the individual component of JSON and I was discussing whether we were actually rendering in-content. Of course we were not at that point, okay? In this case where we want to explore, it is still useful to be able to do that because I can compose what we call API endpoints or AEM Content Services API channel pages that will become these endpoints, where you combine components to expose them as JSON, as well as the page that holds them. So you can consume that on applications, such as for example, a mobile application. And basically you can create your API there, okay? And manage it. And the way in which you manage it is since this is done from an AEM page, you get all of the benefits of managing AEM pages, okay? And last but not least, we have the AEM Assets HTTP API, which is how you can get to AEM Assets, not just content fragments, but also assets in general. Okay? So you don’t need an AEM page to have an endpoint point to add to those pieces of content, but rather you can go directly through this HTTP Assets API, okay? This is meant mostly for back office integrations into, for example, a marketing resource management software or something like that that you want to script and automate the creation of content fragments, for example, things like that on the back office, okay? So you get full create, read, update operations on the authoring environment. And it is advised not to use the updating and deleting that the whole writing experience should be avoided on the published side of things, okay? So you have, in this case, also the situation that the presentation is not important on the server, okay? We just care about having the content there and being able to access it. How it works is that it maps the whole content dump folder, which is where you have the digital assets to API Assets and then you put the within content dump here then you have that model.json for example, if you content fragment. Then we’ll give you a data representation of that content fragment. But if it’s, for example, a JPEG, you just, instead of putting, if this were a JPEG, you would say .jpeg.json for example, okay? So it has its own JSON output specific for each kind of asset, okay? And do you cannot, you cannot customize here the JSON outputs, as opposed to the previous case and there are cases where we used the Content Services just for the SPA or for the channel pages. When you Content Services, you can actually update the API, sorry, update the JSON output, to fit your needs. In this case, you have a fixed JSON . Okay. So that’s it for our first. We’re not too late. I know we are at the top of the hour, but if you want to stick around for a quick Q&A, please go ahead and ask the questions and I’ll answer to them.
Great. Luis, thank you. Folks, in a moment, we’re going to have a couple of poll questions up on the screen for you. If you could participate in those and provide your feedback, that would be helpful. And Luis, we do have a few questions in the chat pod for you. is asking if you could share the links that you talk about in the presentation via the chat window. So maybe we can put together a document with those links highlighted and share that with the audience for future webinars? Sure. No problem. I’ll send that over to you. And so next time we read under the resources. Wonderful. And Michael is asking, “How does this work in the classic view?” He posed that question in during the HTML script that you were displaying when you started the demo.
Okay.
So what I was showing you using the TouchUI editor, the editor that is now most commonly used in AEM, it’s independent of the fact that in the back-end, I was using HTL, okay? So you can use HTL, even if you’re still using classic.
Where things do change is in the case of the dialogues, okay? But if you want to think about how does the whole idea of authoring in classic view, for example, and delivering that on JSON, okay? What I can say is that you can do, you can offer and still you can get the JSON representation, if you are basing your components out of the core components, because they provide the Sling model exporter. If not, then you have to provide the Sling model exporter for your components so they will expose that in JSON, okay? Now for the actual editing in-context, if you’re thinking about leveraging context editing with the AEM SPA editor, then you have to use the new editor. So and that involves having the new types of dialogues for your components, okay? So you can still get the JSON representation of the components, even if… If normally, you edit in classic view, you can get the JSON representation, all that. But to be able to be able to context, you have to do the SPA editor and that requires you to have everything in new type of UI, the UI that we use. There’re a few other questions that are coming forward. Let’s see. Can you export from content fragments and avoid using page components? Yeah, I think that kind of got us responded with the AEM Assets HTTP API. And I did point out that this, in the case of content fragments, at least. In the case of content fragments, you can export the JSON with AEM Assets HTTP API, all right? Directly, okay? And that’s meant mostly for reading, because if you want to do the reading and updating, that would be for integrations in the back-end, okay? And the case of experience fragments, you can also export them at HTML and JSON, okay? Mostly these exporting feature is useful integration with Adobe Target, okay? And you actually, most of the time re-using those experience fragments on other AEM web channels, okay? But you can export the experience fragment that plain HTML.
Can we pull all page data in one? Absolutely. And we actually saw that. So we saw that in two ways. So we saw that in the case of the traditional way where we just were editing a traditional page, wasn’t an SPA, the first one that we’re looking at, okay? And we took the path in that model.json and we got the JSON representation of the whole page, okay? And we could go into individual components. And we also were able to get the whole representation in the case of the SPA situation. We were able to get everything, not just the page, but all of the challenges and their specific JSON representations. So that was… And the SPA and that’s how the SPA we’ll navigate that to help your front-end React App to be able to instantiate the React components where needed and to re-render them when needed, okay? So how does these work with Jamstack that builds static pages in build time decided not to be hosted in AEM since there is no server side rendering? So honestly, I’m not familiarized with Jamstack so I cannot speak to that specifically. Well, I can say that there’s a server side rendering functionality for the AEM SPA editor and the AEM SPA editing . If you are using the AEM SPA JS SDK and leveraging the AEM SPA editor, you should have the ability to do server side rendering, though I have to let you know that there’s a lot of documentation on that. In my case, I have not actually used that specific feature, but I recommend that you take a look at it because there’s some, I’ll try to also add a link to that so that you can see that and I believe that Anu is going to share it next time. I think that’s pretty much it in terms of the question.
Perfect. So again, Luis, thank you for a wonderful presentation. And ladies and gentlemen, we appreciate you joining us. We do hope you’ll join us for the second session of the headless series next week. And we look forward to seeing you then. Take care, everybody. -

Series Recordings

recommendation-more-help
1b11e305-9ac1-4085-b79d-c0f5f0ae926b