AEM Sites Modernization: Movement from Static to Editable Templates

[S__k__Agarwal]

A client is modernizing some of their AEM sites to go from static to editable templates so they can use the latest features around has the following parameters:

• The client currently has a dozen static templates that they want to move to editable templates.
• The existing pages use the parsys paragraph system for storing components.
• Each page based on one of the static templates has its own custom properties tab that is unique for that template type.
• The client wants template authors to be able to create the editable templates.

Which approach should an Architect use to meet these requirements?

(A) 1. Use a new page component for editable templates based on the core components page component
2. Migrate page properties to respective components dialogues

(B) 1. Use a new page component for editable templates based on the core components page component
2. Convert page properties to policies

(C) 1. Use the same page components for editable templates
2. Create a new editable template based on each of the existing page components

(D) 1. Use the same page components for editable templates
2. Use a new template type for each static template

@aanchal-sikka @EstebanBustamante 

@arunpatidar @Shashi_Mulugu 

@Pranay_M  @Mahedi_Sabuj 

@DivrajSingh  @Sudheer_Sundalam

@lukasz-m @Rohan_Garg 

[muskaanchandwani]

@S__k__Agarwal 
(D)
1. Use the same page components for editable templates
2. Use a new template type for each static template

[SantoshSai]

Hi @S__k__Agarwal,

I believe, the best choice here is:

(D) 1. Use the same page components for editable templates
2. Use a new template type for each static template

Reason:

Let’s walk through how this meets all the client’s requirements:

1. Client wants to move from static to editable templates

• Using template types is essential in editable templates (they define structure like allowed components, initial content, and policies).

• Each static template likely had its own custom logic/layout, so making one template type per static template allows you to preserve this structure.

2. Pages use parsys

• parsys is used in classic static templates.

• When moving to editable templates, it's recommended to switch to responsivegrid (from Core Components).

• But using the same page component (while adapting it to support editable templates) is a more gradual and safe migration path - especially if custom logic already exists.

3. Each static template has custom properties tab

• With separate template types, you can control page properties for each - since template types allow defining specific cq:dialog nodes for template authoring.

4. Template authors should be able to create templates

• Editable templates created from well-defined template types allow template authors (non-devs) to build new templates via the Template Editor.

Why other options fall short:

• (A) suggests migrating page properties to components - which doesn't preserve custom page-level property dialogs.

• (B) suggests converting page properties to policies - policies control components/settings in the layout container, not page properties.

• (C) reuses page components but only creates templates, not template types - which won’t scale well for author flexibility or custom dialogs.

Hope that helps!

Regards,
Santosh