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...