Productive Feature Abuse

Chapter 1: Staging without staging

Sometimes there are several ways to achieve a goal - and this is a story about one of those times, and one of those different paths to achieve a goal.

Recently, in a conversation, I came across two different ways to solve the same problem: One is way more graphical than the other, and both have their advantages, disadvantages and limitations: How to edit next month's special opportunity site's pages hidden from public view?

The immediate solution for that would be Staging and Page Versioning: You would prepare those pages as you like, and publish them on demand or on schedule.

But then: Staging can be quite a heavy weapon for just changing some appearance for the holiday season. Also, staging content pages with all their variations doesn't cover all possible combinatoric usecases. Not the least problem is that Staging Page Variants of Experiences of Content Pages (that's a mouthful) currently is unsupported.

So, let's say:

  • I want to serve extra holiday decoration on my site in the month of December (choose the appropriate holidays and decoration for your target audience).
  • I love the Content Page's WYSIWYG editor.
  • And I want to refrain from Staging/Page Versioning, because my authors don't understand it well. Or because I deliver targeted content with Experiences that don't support staging.

Here's where the feature abuse idea comes in:

How about creating a custom segment that applies to all visitors visiting the site in a specific time interval? Lucky me, some of my colleagues have just prepared a simple custom segment that I could simplify even more and try it out. (Later on I got notice that even this specific scenario also has been implemented already, but figured that my solution is even shorter and more flexible. And - lucky you - it comes with this article)


 

It turns out that I - as well as others - always thought of segments as separating users by different attributes that belong directly to them - e.g. their geolocation, language, personal data, used device, or other. But it could be an attribute completely independent of a user - like: The time of their visit to the site... (an attribute that is naturally common to all visitors). with that, I proudly present: The "Visiting Month" Custom Segment.

@Component(
        immediate=true,
        property= {
                "request.context.contributor.key=" + VisitingMonthSegmentKey.KEY,
                "request.context.contributor.type=Integer"
        },
        service=RequestContextContributor.class
    )
public class VisitingMonthSegmentRequestContextContributor implements RequestContextContributor {
    @Override
    public void contribute(Context context, HttpServletRequest request) {
        if(!context.containsKey(VisitingMonthSegmentKey.KEY)) {
            int month = Calendar.getInstance().get(Calendar.MONTH);
            context.put(VisitingMonthSegmentKey.KEY, (Integer)(month+1));
        }
    }
}

With this, you can easily create a segment that applies to all visitors as soon as the calendar switches to a new month (e.g. December). Or you can combine different rules to create your own segment (e.g. northern hemisphere geolocation and June, July or August, denoting a summer segment). This way you can prepare the targeted Experience for date-based segments months before the criteria is ever matched and use the Simulator to show the appropriate content.

You can find the full code for DXP 7.3 (easy to adapt to CE) on github.

0