by Ursula Johnson

Created

June 12, 2017

And…..he’s back! We are excited to share another post in the AEM Rockstar Tips & Tricks Guest Blog series! This Tips & Tricks post is a follow-up from Brett Birschbach, an AEM Certified Architect and AEM Rockstar semi-finalist who presented at Adobe’s global virtual developer conference, IMMERSE 2017. Brett previewed his Tips & Tricks in a preview post before IMMERSE. As promised, he’s returned to share more from his presentation. 

Brett is the Adobe Marketing Cloud Solutions Architect for HS2 Solutions, a digital transformation company based in Chicago. He is a hands-on problem solver with experience leading large multinational, multi-site platform projects.  Brett led the development of the new Shared Component Properties feature in the open-source ACS AEM Commons library. For more from Brett, connect with him on LinkedIn,  (https://www.linkedin.com/in/brettbirschbach/ ) or visit his Github: HitmanInWis.

 

AEM Multi-Site Tips & Tricks – Top 3½ Tips from IMMERSE 2017

 

Faced with a multi-site project and looking to get off on the right foot?  As mentioned in my previous article, most mature AEM installations involve multiple sites, but nearly all began as a single site before expanding to support more.  Why should you care about “getting it right” up front, rather than figuring it out as you go?  Well…

  1. Multi-site code structures don’t happen by default.
  2. Setting up the right structures makes it easy for developers to do the right thing.
  3. Getting multi-site wrong early will haunt you as long as the sites live.

But hey, I don’t need to convince you of this, or else you wouldn’t invest your time into this article.  You’ve got sites to write, and lots of them!  So let’s get right to the good stuff – the tips most voted as new/helpful by the attendees of the Adobe IMMERSE session on Multi-Site Platforms – Setting your Codebase Up for Success.  These tips were demonstrated in the context of coding a multi-site platform for a fictitious football league (HFL) including the Green Bay Peckers (Go Peck Go!) and Chicago Boars (a.k.a. Chicago Bores), the demo of which is available to download at the bottom of this article.

 

Tip #3-1/2 – Leverage the Page Root Provider in ACS Commons

IMMERSE Presentation Time Slots: 18:21-19:24, 27:04-28:09

OSGi Configs for Page Root Provider:

Coming in at a virtual tie in votes with Tips #3 and #2, the Page Root Provider in ACS Commons earns the distinct honor of being Tip #3½ by playing a supporting role making Tips #3 and #2 possible.  The Page Root Provider in ACS Commons gives your code a simple, reliable way to determine the homepage of the site pertinent to the request being processed.  This allows you to:

  • Write OSGi services and components with generic code that executes on content specific to the applicable site.
  • Easily reference the homepage node from code for complex use cases as well as simple tasks like rendering a link to the homepage.

 

Tip #3 – Use the “Contextual Path Browser” Field

IMMERSE Presentation Time Slots: 19:24-20:12, 28:09-29:05 

OOTB Path Browser Field:

 

Contextual Path Browser Field:

Frankly, I was blown away by the popularity of this tip–it is such a simple and narrow concept compared to Tips #2 and #1.  The tip’s simplicity, however, is offset by its even simpler effort to implement.  The Contextual Path Browser field in ACS Commons (sling:resourceType = acs-commons/touchui-widgets/contextualpathbrowser) is a drop-in replacement for AEM’s OOTB Path Browser field with one powerful improvement – the ability to limit the author to the “context” of the site on which the component lives.  The main benefits include:

  • Less clutter and clicks for authors, automatically putting them where they need to be.
  • Authors working on multiple sites are far less likely to accidentally navigate into an incorrect site and potentially create invalid links.

 

Tip #2 – Use Shared/Global Properties

IMMERSE Presentation Time Slots: 20:13-22:09, 29:05-30:31

Component Supporting Shared and Global Properties Dialogs:

 

Shared Properties Dialog – Properties Shared Across All Pages within a site:

 

Global Properties Dialog – Logo Shared with Header:

Tip #2 comes as a long-awaited boon to battle-hardened AEM developers, who have custom-built support for “global properties” again and again. Developers try to ease the burden on authors for component values that need to be repeated on multiple pages of a site, but that authors don’t want to have to set (and maintain) on every page.   Often, it is tempting to hard-code these values, but that has limitations in that it doesn’t allow authors to change the values (the opposite of a CMS) and it doesn’t allow the value to differ between two sites.  Shared Component Properties in ACS Commons solves both of those issues, allowing a property to be set once for an entire site, but still different on individual sites.

Take the “Tout” component in the images above that links off to the Schedule page.  This component needs to link to the same page and have the same copy on all pages of the Green Bay Peckers site, but have a different link and potentially different copy on the Chicago Boars site.  Shared Component Properties allows this component to do just that, with no specialized coding on the part of the developer.  The “Tout” component also renders the team logo on all pages, another great use case for Shared Component Properties.  Because the site header also uses that logo, however, a “global” property dialog is used to share the logo between the two components.

There are numerous applications of Shared Component Properties, even in non-multi-site solutions.  I encourage you to check out the main documentation page for Shared Component Properties to learn more.  In summary, benefits include:

  • Allowing repeated component copy and configs to be authorable without putting a burden on authors to maintain on multiple pages.
  • Allowing shared properties to be internationalized via standard AEM translation (as opposed to a solution using the design dialog).
  • Sharing properties within a sling:resourceType (termed “shared” properties).
  • Sharing properties across sling:resourceTypes (termed “global” properties).
  • Ability to simplify headers, footers, and other site-wide content to no longer require the use of an iparsys.

For a deep dive on Shared Component Properties, check out my article on Shared Component Properties.

Tip #1 – Add a Living Style Guide to Each Site

IMMERSE Presentation Time Slots: 34:57-37:49, 42:10-43:36 

Green Bay Peckers Style Guide vs Chicago Boars Style Guide

Let’s just call this tip “the secret to make everyone like you.”  When this tip came in as the top voted tip, I can honestly say I wasn’t surprised.  Why?  Simple – it is extremely useful, everyone (especially clients) loves it, and it costs you nothing to implement.

Living style guides are so highly touted by UI designers, front-end developers, and marketers, that the term is a buzzword applied to nearly all style guides these days, regardless of whether they are actually living.  However, when you do a living style guide in AEM, you get the real thing.  Because the style guide is rendered by AEM using real live code, it is guaranteed to be 100% up to date at all times.

Though few people will argue against the usefulness of a living style guide, many will claim that such a construct is too expensive to produce and maintain.  I’ll be the first to admit that I was originally a skeptic sitting in this camp.  However, after having done this on multiple projects, I’ve come to a new realization – a living style guide in AEM is effectively free.  Here’s why:

  • Your front end developers are already authoring components in all of their variations in order to style them. As such, the only overhead for a front-end developer is the original setup of the style guide page structure (perhaps a day) and incremental overhead of exporting their authored content from AEM to the codebase (literally seconds).
  • Your QA personnel is likely testing components by authoring them completely from scratch, repeating the work that is already being done by your front-end developers. With the style guide exported to the code base and thus deployed to AEM, along with the code changes to test, your QA team will often now be 75-100% set up for their component testing, recouping any extra time (and likely more) spent by your front-end developers creating and maintaining the style guide.
  • Because a complete style guide requires all variations of the component to be displayed, it is a forcing factor to ensure your developers actually work through all variations, thus reducing the number of bugs that make it to QA in the first place.

Your economics professor probably drilled into your head that “there’s no such thing as a free lunch,” but when it comes to AEM living style guides your professor was wrong!  Benefits of a living style guide include:

  • 100% up-to-date rendering of site components in a consolidated, easy to navigate location.
  • The ability for developers to easily verify a styling change across multiple sites and components.
  • The ability for marketers to see what a new brand site and/or styling scheme will look like with very little development time and effort.
  • Fewer bugs that get to and/or through QA.

But wait, there’s more!

…says the infomercial trying to sell us the latest widget, I know I know.  But there really is more to multi-site tips & tricks – 12 more tips to be exact!  Each principle covered in the IMMERSE session on Multi-Site Platforms – Setting your Codebase Up for Success received numerous votes as being new and/or helpful to attendees – the ones covered here are just the start.  If you’re able to access the IMMERSE site and view the entire presentation, it will be time well invested.  Otherwise, download the presentation deck and associated code demo to dig directly into the details yourself.  As always, please reach out if there’s any way I can help! You can contact me on LinkedIn or email brett.birschbach@hs2solutions.com.

All opinions expressed by Brett Birschbach are his own and not Adobe’s.