I’ve recently been learning kotlin and have experimented with using it for development in AEM. What follow are a few observations from those experiments. To say the least, this is not inteded as an exhaustive exploration of all the pros or cons, not an attempt to draw any sweeping conclusions to questions like “should I write my aem project code in Kotlin?”

Why Kotlin?

For the un-initiated, Kotlin in a language created and design by JetBrains, that among other things features a modern, concise syntax, and full interoperabily with Java. When compiled, it produces standard JVM bytecode.

There are many other posts comparing the syntax of Java and Kotlin, or highlighting the language features and benefits of Kotlin, so I don’t intend to duplicate those or produce a full analysis, but I do think it’s worth highlighting a few things that I find particularly useful for AEM development.

Read More...

A quick hint, mostly as a reminder for myself for the next time it happens. When trying to access editable templates through the UI; Tools->General->Templates or via the URL <instance host>/libs/wcm/core/content/sites/templates.html/conf, I’ve run into occasional issues where not all template folders are displayed. After deugging, I ultimately found that this runs the following query:

SELECT * FROM [cq:Page] AS p WHERE p.[jcr:path] LIKE '/conf/%/settings/wcm/templates' ORDER BY [jcr:path]

That should use the cqPageLucene index, and simply running a re-index will fix the issue.

Read More...

While debugging why our AEM javascript client libraries weren’t properly minifying on my current project, I learned a few new tricks. Most of this is documented here but it was new to me, at least.

Debugging GCC Client Library Minification

Our js client libraries were mysteriously not actually outputing as minified, instead just coming back as the full source versions. This didn’t cause any functional issues, but was an annoyance for a long time. It was also hard to find the problem because the default error log doesn’t actually print why the js failed to minify, just a generic statement about the number of errors. The key to this was adding a logger on the google javascript compiler classes. I ended up creating a custom logger configuration for 2 packages at the debug level to get all of the info I needed:

• com.adobe.granite.ui.clientlibs
• com.google.javascript.jscomp

This got me to a low enough level of info on what errors were acutally occuring during compilation, so I that I knew what the problem was. As it turns out, some our developers had been using the ES6 let keyword to declare variables, and the compiler was choking on this because the source mode defaults to ES5.

Read More...

CQ’s (really Sling’s) out of the box vanity url features provide a powerful mechanism for authors to set and modify vanity urls for a page at run time, without the need for IT or sys admin involvement. One conflict I ran into for a long time with this was resolving the need to let authors create vanity urls, with the need to follow adobe security best practices of using a whitelist filter at dispatcher to not allow arbitrary request to be passed along to CQ publish instances.

As you can see, these 2 things conflict. If we want to follow security best practices, we can’t allow authors to specify arbitrary vanity urls. Or can we?

Read More...

For my latest project, we’ve instituted a process where-by every single commit gets code reviewed by at least one other person, and usually by 2 or more people. It’s a process I really enjoy and think has led to exponential gains in code quality. At some point I’ll probably post more info on the tools we use to facilitate this process and how it works. It’s nothing groundbreaking or revolutionary, but it’s interesting nonetheless. That’s a post for another day.

However, in the course of doing said code reviews, I’ve found myself frequently commenting on my preference for higher level APIs over their lower level equivelents. This has drawn some confusion at times, so I thought I would explain that stance, and why I believe it is, in general, the right approach.

Read More...

I recently finished reading The Non-Designer’s Design Book on my kindle, a book that has been on my reading list for a while, but that I just got around to purchasing and reading about 3 weeks ago. The title couldn’t be more accurate, as the book describes in laymens terms the bare minimum you need to know to recognize and apply good design.

Read More...

Kiran explained that he likes it when people say I don’t know because it lends credibility to everything else that they’ve said.

I loved this post from Jason Freedman at 42 Floors, and totally related to it from the consulting world I live in. Many consultant, especially younger consultants, are afraid to say those 3 magic words, afraid that it makes them come across as fallible, as lacking knowledge that they should have. Certainly, you don’t want to be telling your clients “I don’t know” on too much of a regular basis, but being able to confidently say, “I don’t know, but I’ll figure it out,” is often one of the telltale signs of a good consultant.

Read More...

Note: I had originally written this post sometime last year on my old blog (at this same domain). I'm restoring it here, because I think it contains some useful information. The exact same content can aso be found on the Crown Blog.

At this point, it’s pretty much common wisdom that the loading of JavaScript libraries should be deferred to the footer of the page if at all possible. Sam Saffron has some good suggestions on why this is a good idea and also how you can go about implementing it while still making use of the jQuery $ variable in script fragments in your page’s body to bind function calls to $.ready. But for the purposes of this post, I’m not really trying to convince you that this is a good idea, I’m just going to assume you’re already on board and are looking for ideas on how you might implement such a pattern in Adobe CQ.

Due to the nature of CQs component structure, if you have components that rely on JavaScript to load dynamic portions, it can very quickly become a bit of a mess trying to maintain that JS code with the components, without it being littered throughout your pages. The solution Sam suggests works great, and I’ve used it on projects in the past. But I was thinking about this as I started a recent project and thought I might be able to use CQs built in client libs functionality to come up with a better way.

The final solution is described in detail below. I would note that there are probably a few ways to accomplish this, but I like this method because it’s simple and flexible while still getting the job done, and since we are using client libs, all of the js for a particular component is maintained with that component.

Read More...

If you’ve spent any serious amount of time as a cq developer or administractor, you are probably aware of the ability to configure OSGI services both via the webconsole or via runmode scoped configuration folders in the crx repository. This post is an attempt to document (perhaps for myself more than for anyone else) the services that I configure for every single CQ project, and that I think every CQ project should configure to fit their needs.

Read More...

One of the most powerful parts of AEM is OSGI and the ability that gives you configure servies and modify those confiugration on the fly if needed. By creating custom services and providing appopriate configuration properties, your services become more flexible. If we extend that a bit furthur, and use runmode scoped configurations in the repository we can now dynamically modify how our services behave based on the environment they are running in. But for me personally, the one piece that was always missing was how to create a factory configuration service. That is, how can I create single service, but apply multiple configuration to it and then consume those configurations from another class, similar to how the loggers are configured. What follows are the steps needed to create such a configuration; it actually turns out to be pretty simple.

Read More...