While working with AEM, we should know about all relevant technologies in the market. SPA and PWA are such ones. AEM already supports SPA OOTB. Let us understand about them more.
SPA:
SPA are the applications having single page and the content gets updated within the page dynamically based on user interaction. Commonly used technologies to develop SPAs are AngularJS, Ember.js, Knockout.js, Meteor.js, ExtJS, Vue.js and React .
Eg: Gmail
SPA Features:
1. Responsive
2. Fast and efficient.
3. Not served through app store.
4. No extra queries to the server to download pages
5. User friendly.
PWA:
This is an application behave like a native application and developed using modern web technologies. This application supports offline features(using service worker & Web App Manifest) when no internet connection and are extremely fast & engaging.
PWA is an idea proposed by Google developers.
What is a Service Worker?
They are scripts that stand between your web application and your network
What is a Web App Manifest?
Web App Manifest is a JSON file with meta-information about the site.
Angular, React , Vue
PWA Features:
1. Responsive
2. Push Notification.
3. Offline Support.
4. Fast and efficient.
5. Not served through app store.
6. relatively cheaper than developing native apps
7. Does not require installation
Conclusion
An SPA can be a PWA, but a PWA does not have to be a SPA.
Progressive Web Apps are the next level of browser based applications, offer a rich user experience that parallels what users know and expect from native apps and combine that with the benefits that browser based applications provide.
Progressive Web Apps are not Single Page Apps
- PWA's Register a Service Worker with a Fetch Event Handler and Minimal Offline Support
- PWA's Have a Valid Web Manifest File with a Minimal Set of Icons
- PWA's Served using HTTPS (Secure)
What is Single Page Application and its uses?
Single Page Applications (SPAs) are a wonderful tool for making engaging and unique experiences for website users. SPAs helps to build a fluid, scalable experience. SPA can be used within AEM to give both developers and marketers the level of control they need while authoring a content.
Some examples where SPA in use are Gmail, Google Maps, AirBNB, Netflix, etc.
The core principle of an SPA is that it is a single page where a lot of information remains the same and only a few pieces gets updated at a time. This is different from a traditional HTML page load where the server re-renders a full page with every request.
SPAs provide great ease to developers because of the separation of back-end services and front-end display without disturbing critical back-end functionality. Developers have the option to work in the language they prefer.
Common SPA frameworks are Angular, React, Ember, and Vue are JavaScript
Click on image to see it big
Advantages of SPA's
• Behaves like a native application
• Provides rich user experiences
• Good separation of concerns
• API-based
• Decouples content from presentation
• Can provide live preview & editing
• Supports a hybrid setup
• Personalization on the server side
AEM & SPA
The latest versions of AEM supports SPA and allows authoring through SPA Editor.
AEM SPA Editor Steps
Below given sequence of activities involved in AEM SPA websites.
1. SPA Editor loads.
2. SPA is loaded in a separated frame.
3. SPA requests JSON content and renders components client-side.
4. SPA Editor detects rendered components and generates overlays.
5. Author clicks overlay, displaying the component’s edit toolbar.
6. SPA Editor persists edits with a POST request to the server.
7. SPA Editor requests updated JSON to the SPA Editor, which is sent to the SPA with a DOM Event.
8. SPA re-renders the concerned component, updating its DOM.
We are coming up with more blogs/ videos on working with SPAs now.
AEM Core Components follow modern implementation patterns. There are two types of component patterns in AEM, General Component Pattern & Reusable Component Pattern
1. General Component Patterns
This set of patterns are recommended for any type of components(regardless whether the component is specific to a single project, or reused across multiple sites or projects).
a. Configurable Components
There are cases where we have a requirement of components which are having variation of similar elements. In such cases, it is recommended to have configurable components having dialogs with various options instead of creating multiple components.
b. Separation of Concerns
This patterns recommends the usage of separation of logic from markup.
- HTL can be used for markup which is more secure.
- SlingModels are the recommended option for Logic implementation
2. Reusable Component Patterns
These patterns are used for any kind of component, which are most suitable for components that are intended to be reused across multiple sites or projects(For eg. Core Components)
a. Pre-Configurable Capabilities
It is recommended to define the components/templates flexible as much as possible. Some examples could be using edit dialog (For Page authors), Design Dialog (For Template authors) and all these options are availabe under 'Policies' as part of editable templates.
b. Proxy Component Pattern
Here component inheritance is used as a proxy. Create second level components by referring the resourceSuperType property from core components.
Which offers more flexibility and avoid content refactoring if one site needs a different behavior for a component.
c. Component Versioning
Always introduce component versioning by adding a number in their resource type path, and in the fully qualified Java class names of their implementations, which will help keeping the components compatible over time. Useful when upgrade happens.
d. Model Interfaces
This pattern recommends the usage of HTL's data-sly-use instruction to point to a Java interface, while the Sling Model implementation is also registering itself to the resource type of the component.
When there is a requirement to redefine the implementation of a Sling Model or HTL markup of a component, this avoids complexity. Because they are loosely coupled.
Proxy Components are site-specific components which are inherited from core components, which define the desired component name and group to display for page authoring.
Proxy Components refer to a Core Component as their super-type.
These site-specific components are called proxy components, for the reason they don't need to contain anything; they just serve mostly to define the version of a component to use for the site. Infact, when customizing the Core Components, these proxy components play an essential role for markup and logic customization.
[Click on image to see it big]
Advantages of creating Proxy Components
Proxy components helps categorization of components in a reusable way.
Better seggregation: It is a good practice to have 'sling:resourceType' property pointing to site-specific components, instead of pointing to components that are shared by multiple sites.
This provide more flexibility and avoid content refactoring if one site needs a different behavior for a component.
Customization can then be achieved on the site-specific component and won't affect the other sites.
Proxy components can be entirely empty if they fully inherit the functionality, or they can redefine some aspects of the component.
AEM Core components are available from AEM 6.2. AEM 6.3 onwards Core Components were getting more stabilized. Now we have AEM 6.4 which has the more advanced Core components.
Core Components were introduced to provide robust and extensible base components, built on the latest technology and best practices, and adhering to accessibility guidelines.
Core Components leverage the latest technology to enable the creation of flexible, extensible, and feature-rich components to enable authors to easily create content.
AEM Core components are with HTML Template Language, or HTL, Touch UI dialogs and Sling Models, Secure, robust, version-able
There are 16 Core Components in AEM 6.4 at present (This count keep getting increased based on developer contrbutions in GitHub), which can be divided into two categories .
Page authorable components
-Breadcrumb
-Content Fragment
-List
-Navigation
-Page
-Quick Search
-Social Media Sharing
-Text
-Title
-Language Navigation
-Image
Form specific core components
-Form Hidden
-Form Options
-Form Text
-Form Button
-Form Container
When to Use the Core Components?
New Projects - New projects should always attempt to use Core Components.
Existing Projects - Recommendation is keep using the foundation components, unless a site or component refactoring is planned.
New Custom Components - Assess if an existing Core Component may be customized. If not, recommendation is to build a new custom component following the Component Guidelines.
Existing Custom Components - If your components work as expected, then keep them as they are.
If not, refer to "New Custom Components" above.
Foundation Component Support
Since the foundation components have served as a basis of so much project development over many versions, they will continue to be supported into the foreseeable future.
However, Adobe's development emphasis has shifted to the core components and new features will be added to them whereas only bug fixes will be made to the foundation components
Core Components Advantages
100% written in HTL.
Apache 2.0 License.
Allow versioning of components.
GitHub
latest features are supported, plus backward compatibility is also available.
I have given a step by step demo of content approval process in AEM 6.4 in the video. Here I will explains the steps involved in detail.
[Click on images to see them big]
There are 3 major steps involved in AEM content approval,
Creating a simple workflow model
Creating a content approval workflow based on the model created
Verify the workflow
User Creation
Before we start, we need a set of users to understand our Workflow process. For this , we will create 3 users called author, editor, legal.
Go to tools> Security > Users and create 3 users author, editor, legal. This is quite simple and direct step.
Steps for workflow creation
1) Creating a simple workflow model
- Go to Tools, Workflow, Models
- Select 'Create', then 'Create Model'.
- Then Add Workflow Model dialog appears. Enter the Title and Name, then select Done.
Newly created model is listed in the Workflow Models console.
- Select your new workflow, then click on Edit to open it for modification:
The new workflow will contain:
Flow Start
Step 1
Flow End
- Delete Step 1
- From the Workflow selection of the steps browser, drag a Participant Step onto the workflow and position it between Flow Start and Flow End.
- Open the properties by clicking on configure option
- In the Common tab enter Validate Content - for both the Title and Description.
- Open the User/Group tab:
- Select Editor for the User/Group field.
- Confirm the updates by selecting the tick mark.
- Drag an Or Split onto the workflow and position it between Validate Content and Flow End.
- Open the Or Split for configuration.
Configure:
Common: select 2 Branches
Branch 1: select Default Route. - This option will be selected by default when the user reviews the content.
Branch 2: ensure Default Route is not selected.
Confirm your updates to the OR Split.
- Drag a Participant Step to the left hand branch, open the properties, specify the following values, then confirm the changes:
Title: Reject Publish Request
User/Group: Author - (Editor will reject the publish and notify the author).
Now,
- Drag a Participant Step to the right hand branch,
- In the properties section, specify the following values, then confirm the changes:
Title: Approve for Legal review
User/Group: legal - (If editor is fine with the content, he asks the legal person to review for legal adherence).
- Drag an Or Split onto the workflow and position it between Validate Content and Flow End.
- Open the Or Split and make configurations as below.
Common: select 2 Branches
Branch 1: select Default Route.
Branch 2: ensure Default Route is not selected.
Confirm your updates to the OR Split.
- Drag a Participant Step to the left-hand branch, open the properties, specify the following values, then confirm the changes:
Title: Reject Publish Request
User/Group: Author - We will reject the publish and notify the author.
- Drag a Participant Step to the right-hand branch, open the properties, specify the following values, then confirm the changes:
Title: Publish Page as Requested
Process: select Activate Page. This process publishes the selected page to the publisher instances.
Now the workflow model looks like this.
Note: Remember to sync the workflow so that the latest changes will be always updated in run time.
2) Creating a content approval workflow based on the model created
- Now login as user 'author'
We have two options to trigger the content approval workflow.
a) Go to workflow model (http://localhost:(port)/libs/cq/workflow/admin/console/content/models.html) select, click on start workflow and specify the payload.
b) Go to sites> a project specific page. Select the page and click on 'Create workflow' from top left menu. Then in new window select the workflow model and provide a title. In next window click on 'create' so that the workflow will start.
3) Verify the workflow
- Now login as user 'editor' and go to inbox and open the message and complete the workflow. Editor will have options Approve for Legal review , Reject Publish Request
Now the workflow will be moved to legal person as per our workflow model definition,
- Login as legal, and from inbox he will have options like 'Reject Publish Request', 'Publish Page as Requested'. Complete the review and approve it. So that the page gets activated.
If any of the editor or legal person rejects, the payload goes back to author and asks for re-verification.
Below given a video recording of the above mentioned activity. Let me know if you face any issues through the comments section.
