Default views in AEM Sites Content Tree

Image may be NSFW.
Clik here to view.

Background
When using Adobe Experience Manager (AEM), you will come across pages that can be viewed in multiple ways. A prime example of this is the sites page. By default in AEM 6.3, pages such as the sites page display in what is called the column view. The user can change the view to either the card view or list view. This change will persist between user sessions through the use of browser cookies.

Problem/Use Case
There are some issues with the way these views work. The first is the simplest. Since the user’s current preferred view is stored as a cookie, it does not persist between browsers, computers or when the browser’s cookies are cleared (which at times is very frequent in AEM development). This can be a source of annoyance in the best case, and a source of confusion in the worst case. For example:

Let’s say that we have a client that has just hired a new employee to be one of their content authors. This new author has never used AEM before. On the first day of their new job, they are given a collection of training documents. These training documents were written very well, and included lots of helpful screenshots. The problem is that these documents were written to train authors on AEM 6.0 (consistent with the project at the time) and since then the project was upgraded to AEM 6.3. The default views for the sites page being different between the two versions (“card” and “column” respectively). This causes much confusion to the new author as what they see on their browser does not match what they see in the training documents.

Some operations might not be that difficult to figure out despite a different view. However, some operations can only be done in a particular view (like sorting in the list view). An operation like sorting might be necessary if the site has a lot of sibling pages or folders, and it may be very difficult to accomplish finding a particular page or folder in such a situation without the ability to sort.

Each view has its own pros and cons and depending on the intended use of the instance one view may make more sense than the others to be used as the default. As such, if one view stands out as better for a particular project and the majority of the users would be using it anyway, it would make sense to make that view the default view.

It would also make sense to change the default view if there are customizations to that view for a particular project and/or client.

A Solution
The Sites page and those like it are made from a lot of different files working together. This can make it difficult to know how and where to make effective changes. In this case we are overlaying the file /libs/granite/ui/components/shell/collectionpage/collectionpage.jsp with the file /apps/granite/ui/components/shell/collectionpage/collectionpage.jsp and will not be a full solution to the problems set forth above. At this time, we will simply be changing the default view.

This is the default code that sets the view (column view) of the page when it loads:

String targetViewName = getTargetViewName(slingRequest, consoleId);

List viewCache = new ArrayList();
Resource currentView = null;

int i = 0;
for (Iterator it = resource.getChild("views").listChildren(); it.hasNext(); i++) {
	Resource item = it.next();

	if (i == 0 || item.getName().equals(targetViewName)) {
    	currentView = item;
	}

	viewCache.add(item);
}

The method “getTargetViewName” returns the value stored in the browser cookie mentioned earlier, or null if the cookie isn’t found. Knowing this, we can change the line:
if (i == 0 || item.getName().equals(targetViewName)) {
to:
if (i == 0 || item.getName().equals(targetViewName) || (targetViewName == null && item.getName().equals(“card”))) {
in order to enable the card view as the new default.

Similarly, to enable the list view by default, we can change the line to:
if (i == 0 || item.getName().equals(targetViewName) || (targetViewName == null && item.getName().equals(“list”))) {
The “i==0” case will handle the column view and ensures that if any view is available that there is one set.

Although, we could make these changes to the collectionpage.jsp file within the libs folder, we should (for best practices) overlay the file and make the changes to the overlayed file. To do this, copy the file /libs/granite/ui/components/shell/collectionpage/collectionpage.jsp to the folder /apps/granite/ui/components/shell/collectionpage/ and make the desired changes to this new file as described above.

Future Plans
In the future, we would like to add an option to the user preferences dialog to set the default view on a per-user basis. Specifically, this would be added as a selectable option that will store a value in the JCR, and we will alter the code above in the file /libs/granite/ui/components/shell/collectionpage/collectionpage.jsp to use that value within a variable instead of a hard-coded string. We plan to follow up on these ideas, and if we succeed in doing so, we will follow up with another article.