1) AEM jar naming convention – <cq/AEM>-<publish/author>-p<port>.jar
2) Templates in AEM:
A template is a node of type cq:Template and has the following properties and child nodes:
Type
|
Description
| |
.
|
cq:Template
|
Current template. A template is of node type cq:Template.
|
allowedChildren
|
String[]
|
Path of a template that is allowed to be a child of this template.
|
allowedParents
|
String[]
|
Path of a template that is allowed to be a parent of this template.
|
allowedPaths
|
String[]
|
Path of a page that is allowed to be based on this template.
|
jcr:created
|
Date
|
Date of creation of the template.
|
jcr:description
|
String
|
Description of the template.
|
jcr:title
|
String
|
Title of the template.
|
ranking
|
Long
|
Rank of the template. Used to display the template in the User Interface.
|
jcr:content
|
cq:PageContent
|
Node containing the content of the template.
|
thumbnail.png
|
nt:file
|
Thumbnail of the template.
|
icon.png
|
nt:file
|
Icon of the template.
|
A template is the basis of a page.
1) Persistent Identity (PID) – Refers the Configurations field in the Web console
2) The edit behaviour of a component is configured by adding a cq:editConfig
cq:editConfig node properties:
§ cq:actions (String array): defines the actions that can be performed on the component.
§ cq:layout (String): : defines how the component is edited.
§ cq:dialogMode (String): defines how the component dialog is opened.
§ cq:emptyText (String): defines text that is displayed when no visual content is present.
§ cq:inherit (Boolean): defines if missing values are inherited from the component that it inherits from.
cq:editConfig child nodes:
§ cq:dropTargets (node type nt:unstructured): defines a list of drop targets that can accept a drop from an asset of the content finder.
§ cq:actionConfigs (node type nt:unstructured): defines a list of new actions that are appended to the cq:actions list.
§ cq:formParameters (node type nt:unstructured): defines additional parameters that are added to the dialog form.
§ cq:inplaceEditing (node type cq:InplaceEditingConfig): defines an inplace editing configuration for the component.
§ cq:listeners (node type cq:EditListenersConfig): defines what happens before or after an action occurs on the component.
To disable the “Target” context menu item on components , set the property “cq:disable Targeting” to true on the cq:editConfig node.
3) Usage of declarative services:
Annotations
|
Description
|
Is the only required annotation. If this annotation is not declared for a Java class, the class is not declared as a component.
| |
@Activate
|
These annoations have no attribues.
|
@Modified
|
These annoations have no attribues.
|
@Deactivate
|
These annoations have no attribues.
|
The @Service annotation defines whether and which service interfaces are provided by the component. This is a class annotation.
| |
properties which are made available to the component through the ComponentContext.getProperties() method. These tags are not strictly required but may be used by components to defined initial configuration. Additionally properties may be set here to identify the component if it is registered as a service, for example the service.description and service.vendor properties.
| |
The @Reference annotation defines references to other services made available to the component by the Service Component Runtime.
| |
4)Replication Facts:
§ Any replication rights applied to a group apply to all the users in that group.
§ A user’s replication privileges supersedes a group’s replication privileges.
§ The replication rights are evaluated bottom-up in the node tree.
§ The allow replication rights has higher precedence than deny replication rights.
§ To grant replication rights to a user on any resource, user has to have read permissions for/etc/replication, /bin.
5) Causes of dispatcher stopped updating cache files in the cache directory:
The request contains query string parameters.
The request has authorization headers and dispatcher.any does not contain \allowAuthorized.
The request contains query string parameters.
The request has authorization headers and dispatcher.any does not contain \allowAuthorized.
6)
Dispatcher Flush agent
|
Publish
|
http://www.cqtutorial.com/courses/cq-admin/cq-admin-lessons/cq-dispatcher/cq-dispatcher-flush-agent-set-up
|
Replication Agent
| ||
Reverse Replication Agent
| ||
Static Agent
| ||
7)
Bundle
|
Usage
| |
Adobe CRXDE Support (com.day.crx.crxde-support)
|
Web based log viewing
|
/bin/crxde/logs?tail=
|
Apache Sling OSGiLogService Implementation (org.apache.sling.commons.logservi
|
To configure log path, level.
| |
8)Maven Plugins:
Maven Plugins
|
Usage
| ||||||||||||||
Builds OSGi bundles instead of plain jars
| |||||||||||||||
Handles OSGi SCR (service component runtime) annotations in Java files at build time
| |||||||||||||||
Allows to create CQ content packages via maven (previously called maven vault plugin)
| |||||||||||||||
Java doc plugin
|
It uses the Javadoc tool to generate javadocs for the specified project.
| ||||||||||||||
Maven Sling Plugin
|
provides a number of goals which may be of help while developping bundles for Sling. Following are the goals:
|
9) Custom log file creation:
10) Installation run modes are provided out-of-the-box:
§ author
§ publish
§ samplecontent
§ nosamplecontent
11)Common API Usage:
To get the template Path
|
Page.getTemplate().getPath();
|
Delete a property using node api
|
node.setProperty(“propertyName”,null);
|
VLT Commands:
resolve
|
Removes the conflict-related artifact files
|
export
|
Exports from a JCR repository (vault file system) to the local file system without control files.
|
import
|
Imports a local file system to a JCR repository (vault file system).
|
Replication Type(Serialization Type):
Default(Durbo)
| |
Binary Less
|
Replicate when author and publisher has shared data store.
Binaryless replication or shared data store works on the basis that binaries are not copied across datastores. Only the metadata is replicated or transferred between the instances. The setup can be applied between authors and publishers. Alternatively data store can be shared between author instances also in a cold standby setup. It has 3 major use cases:
1. When you are dealing with very large DAM assets (high res images or videos), any replication involving binary copies over network is very costly. Binaryless is shared data store so binaries are not copied and you save on internal network traffic. It saves time and cost for some setup.
2. When you have lots of publishers, binary copy can bottleneck your author network. This reduces the load of that transfer and publishers can be scaled without impacting network usage exponentially.
3. TarMK cold standby has a limit of 2GB binary sync transfer across primary and standby standalone data stores. Binaryless (or shared datastore) is the only workaround for this limit.
For very large datastores you also save time in backups and restores as there is only one store as opposed to 2 stores for author and publishers.
|
Static
| |
Dispatcher Flush
|
used for flushing the dispatcher cache.
|
No comments:
Post a Comment
If you have any doubts or questions, please let us know.