Fun with CQ5: 3

My manager referred me to a couple of posts on Jörg Hoh's blog of tips and tricks for CQ5. And from there I learned that Adobe offers two certification courses in CQ5.5. It's always nice to have a new certification to add to your resume. But I should probably wait to sit for the Component Developer exam until I finish the new project I'm starting in January, because my experience to this point has been with 5.4.

Sad but probably true

ReadWrite has placed One Laptop Per Child on its technology death watch list.

Spoiler alert: we drop the bomb

An adorable gallery of improbable Hollywood computers doing improbable things. The star of the piece is a decommissioned IBM AN/FSQ-7 Combat Direction Central, part of the SAGE radar defenses of the Eisenhower-Kennedy era—you know, the times back when the operator's console had an integrated ashtray. Parts of the defanged AN/FSQ-7, Q7 for short and cute, appeared with O. J. Simpson, Woody Allen, and babealicous scientist Lee Meriwether—but not with Peter Sellars in Dr. Strangelove. That part was filled by an IBM 7090/94.

...we find it rather amusing that in the one movie where the AN/FSQ-7 would make perfect sense, you don't find the AN/FSQ-7.

At least it was one the scientific systems, not one of IBM's business mainframes.

ᔥ Bits

Fun with CQ5: 2

We follow Adobe's recommendation to use the tag structure to represent menu navigation. Thus, pages can be organized in the content tree the way that is convenient for authors to work (or perhaps to enforce some design restrictions by template), while menus can evolve flexibly in response to usability testing or can differ depending on platform (desktop vs. mobile).

So to render a menu, it's a typical coding pattern to walk a subtree of tags, and for each one, find its corresponding web page (Node) and render its hyperlink. The only tricky bit is that com.day.cq.tagging.Tag.find() returns both Nodes that are explcitly marked with the specified tag as well as Nodes that are only subordinate to a Node that is assigned the tag. A lot of the time, you just want Nodes of the first kind.

We had been using a scheme that matched the Node's navigation title to the tag's title, but that pattern broke down when authors started designing menu items with duplicate names. (And there were other wrinkles.) So, after some desperate Friday afternoon whiteboard sketching, I realized that we could inquire of each candidate Node what tags were assigned to it explicitly, and test for an exact match of TagIDs. And I cooked up the following method, stripped of exception handling, debugging logic, and a little project-specific stuff. The cq:tags property is multi-valued, so there's a little more messy object navigation than you might expect.

import com.day.cq.tagging.Tag;
import java.util.Iterator;
import javax.jcr.Node;
import javax.jcr.Property;
import javax.jcr.PropertyIterator;
import javax.jcr.Value;
import org.apache.sling.api.resource.Resource;

* * * 

    /**
     * Returns the node tagged with the specified tag; if there is more than one such node, returns
     * one of them arbitrarily.  The node must have the tag assigned directly to it as a property;
     * nodes that are tagged by inheritance in the content tree are ignored.
     * @param tag
     * @return node: the node tagged with the specified tag, or null
     */
    public static Node getMatchingNode(Tag tag) {
        Node matchingNode = null;
        Iterator<Resource> relatedNodes = tag.find();
        outer:
        while (relatedNodes.hasNext() && matchingNode == null) {
            Node node = relatedNodes.next().adaptTo(Node.class);
            PropertyIterator tagIds = node.getProperties("cq:tags");
            while (tagIds.hasNext()) {
                Property property = tagIds.nextProperty();
                Value values[] = property.getValues();
                for (Value value : values) {
                    String id = value.getString();
                    if (id.equals(tag.getTagID())) {
                        matchingNode = node;
                        break outer;
                    }
                }
            }
        }
        return matchingNode;
    }

So you think you understand optimization

James Hague suggests some elements of your application that might need to be optimized, putting aside questions of memory/storage footprint and execution speed. Three biggies of the new mobile age:

Number of disk sector writes (especially for solid-state drives).

* * *

Number of bytes of network traffic.

* * *

Number of taps/clicks it takes to accomplish a task.