Introduction to Component Development

Hello, in this video, we will be looking at some of the basics and underlying technology of developing components in Adobe Experience Manager.

Adobe Experience Manager Sites, at its core is a platform for managing web content. So the basic use case is really building out a website. You know, of course, we layer in advanced features to support personalization, analytics, social, headless, spa, you name it, basically everything you need to build a modern digital experience but at the core, AEM Sites, it really starts at the website. So right now, we’re looking at the WKND reference site and this is a published version that you know, this is a version that would be live for site visitors. And so when we talk about AEM components, we’re looking at decomposing this webpage, breaking it down into individual pieces or components. So at the top, we’ve got this main region or container which really forms the header of our webpage. If we take that container, break it down even further, now we’ve got a navigation component, we’ve got a search component, we’ve got this logo which is really an image component. And if we keep going down the page, we’ve got another image component, this is our main image for the article and if we keep scrolling down the page, okay, now we’ve got sort of a main body container and then a side rail container. And of course, we can break those down even further so we’ve got a, this is a breadcrumb component, we’ve got a title component, beneath that, a subtitle component, beneath that, a text component and so the basic idea behind developing with AEM Sites is figuring out how to slice up the page or a markup into these reusable components and the way AEM is designed is that hopefully this process is very natural and it just makes sense from a development standpoint as well as an authoring standpoint.

So let’s go ahead and open up that same page on the AEM authoring instance.

So this is that same Ultimate Guide to LA Skate Parks article but now we’re looking at it on the authoring instance and you can start to see that our page is composed into these different AEM components. And one of the main features of AEM is that once we build a component, then content authors can reuse these components and add it to other parts of the page. So let’s go ahead and add a new image to our page. So we can just drag it to one of these layout container regions, we can then configure this image. So let’s add a new skateboarding image. We can go ahead and search through the dam, find one, then we can make some updates to some of the metadata for this image component. So, in our case, we want to display the caption, not as a pop up, so uncheck that and we click Done and all right, hey, look, here’s our image, we’ve updated this page.

So as an AEM developer, your goal of course, is to make sure that we’ve got a beautiful website that’s functional but we’re also building these reusable components that can be added to a page and these are going to be configured by an author and it’s going to display some content. So, in some ways, it makes our job a lot easier as a developer because we only need to build a single image component, we can add some configuration settings to it and then we can hand it off to our editorial team and our content authors and they can go ahead and update the entire site. So when developing for Adobe Experience Manager, it’s kind of important to keep in mind that there are actually two end users of the application. There is, of course, our site’s visitor persona and this is the user who would be viewing and browsing the published web experience. There’s also the persona of the content author and this can be a business user or a marketer and this user is responsible for creating, editing and publishing content for the site. And then finally, we’ve got the AEM developer. And so it’s their job to develop these reusable components that when combined form a great and engaging web experience for our site visitor, however, it’s also equally important that our developer enables the content author to update and edit these components. So it’s really important for our developer to kind of consider both the content author and the site visitor.

So at a high level, AEM is deployed into two environments. So we’ve gotten an author environment and a publish environment. And our developer is going to be writing and creating code code and this code is going to be deployed to both the author and publish environments. And as a best practice, identical code is deployed to both.

Now we have our site visitor and they are going to be browsing and consuming content through the AEM published here whereas our content author is going to be logged in to the AEM author environment and this is the environment where they’re going to create pages, add and update and edit existing components. And so they’re able to preview this content on the author environment and once it looks good, they can then publish those content changes. So they’ll publish those updates to the AEM published here. And this effectively makes that content live and then our site’s visitor, that end user can see all of these updates. All right, so we’ve talked a lot about the importance of these reusable AEM components. So now let’s peel back the layers a bit and look at some of the main areas of a component. And so from a technical perspective, there’s really five main areas that a developer needs to be concerned about. So there’s the component definition, the dialog and design dialog, there’s sling models, HTL scripts and client-side libraries. So what we’re calling the component definition is really the properties on the component node itself and this is almost the metadata of the component. So some are pretty obvious like a title or an optional description and those are going to be shown to the author in the authoring interface. This is also where you define the component group and this can govern where a component is allowed to be used on a page or by template. One of the key properties is the sling resourceSuperType and this determines component inheritance and this is really powerful because Adobe actually provides a series and a set of core components and this allows customers to actually inherit all of that functionality without having to implement it themselves. So it’s a really powerful part of AEM components. Now dialogs, this is the mechanism for which content authors can update the component. So we’ve sort of seen that in action and each dialog can contain any number of fields or tabs and it’s really up to the developer to decide how they want to design that component. Now one of the key features of the dialog is that this is going to persist or save the values entered by our author to the JCR which is AEM’s underlying repository. Now, the dialogs themselves are defined by a node structure and in the code base, these are really just XML files. So as a developer, you’re not actually writing any code yourself to define these dialogs, you’re simply creating one of these XML files and you’re going to use that to define whether you want a tab, a text field, checkbox or any many other standard form elements. And so it’s actually pretty straightforward, you don’t have to create any code to create one of these dialogs and AEM core components actually provide a ton of dialog examples. So this teaser component, this teaser dialog that we have up front, this is just one of many examples that you can look at and reference to get an idea of how to define a dialog for a custom component. So design dialogs are almost like a cousin to our standard dialogs except they’re used to define policies that authors and power users can manage. And so unlike the standard component dialogs, design dialog are used to control component behavior across multiple component instances and pages. And so the design dialogs, those are configured at the template level and so basically any component that’s used on a page that inherits from that page template can be controlled through a design dialog and these policies.

And like the standard dialog, design dialogs are also defined as node structures and saved as XML in source control. All right, so sling models is written in Java and they’re really plain old Java objects or POJOs. And so the purpose of our sling models is to add some business logic to the component. So for example, in that teaser component, there was a dialog option that would allow a user to manually enter the title or they could click a checkbox and have the component dynamically pull that title value from say a linked page and so where we would implement this logic would be in the components sling model. And so the sling model is going to implement all of this complex business logic and then expose that value through a public getter method. Sling models are also annotation driven, which makes it really easy to map values parsys to the JCR to Java variables. And so by encapsulating all the business logic in our sling model, this is going to keep our HTL script really simple. So every component is going to have one or more HTL scripts. And HTL stands for HTML Template Language and it’s AEM’s server-side templating system. Now the output of HTL is HTML and our HTL scripts provides some very basic presentation logic as well as dynamic variables. So the HTL script is going to determine the final output for our component markup. And as we mentioned, HTL is going to rely on the sling model for most of the complex logic and this is by design because we want our HTL script to resemble that final markup as much as possible. Now the last area of a component that we want to discuss is client-side libraries and client-side libraries is AEM’s way of managing CSS and JavaScript files that are going to be used on the front end. And so there’s multiple options for organizing client libraries, sometimes you would have individual client libraries per component, other times you might have a larger client library that provides a site-wide theme. You can apply metadata to client-side libraries called categories and this provides kind of a tag-like capability so it allows you to establish relationships between other client libraries so you can embed one client library inside of another or you can mark and tag another client library as a dependency. All right, so hopefully that gives you a brief overview of what an AEM component is, how it’s used, as well as an introduction into some of the technical details of an AEM component. Thanks for watching. -