Rotating Messages in Magnolia (with text placeholders)

In a project, an external resource repository is not available from 00:05 AM to 02:30 AM everyday. You need to inform your users about this. How can you do it?

Simple way: using a static disclaimer text

More complex way: a scheduler with a variable.. and so on..

Building a new Magnolia component: Rotating Messages!

Which should be the requirements (in this case is the project scope that drive them..)?

  1. i18n  based (in a standard Magnolia way)
  2. flexible
  3. configurable (best should be at runtime!!)
  4. extendible
  5. usable in an existing running environment (plug-and-play, transparent!)

So, proceed!

First, we need configurable mechanism. A Magnolia Module has already it, use it!

With this setup, we can change the rotation policy (because SimpleRotatingMessage is an implementation of RotatingMessage interface) and we are free to develop RotatingMessages implementing the ScheduledMessage interface.

For java people, the RotatingMessage simply declare a method public String getMessage(). The implementating class SimpleRotatingMessages uses the interface ScheduledMessage with a simple method public boolean isValid(). The first valid message found in config is considered.

Now, we want as less impact as we can over existing dialogs / paragraphs set up.

So, we need a new paragraph:

Notice that we use a new modelClass RotatingTextImageModel extending the STK TextImageModel… see next in ftl why…

At this point we need to define a dialog:

Using inheritance, we use an existing dialog, based upon stkTextImage, and we provide only a new selection field, rotatingMessage. This automatically load its values from the configuration point said before. You change configs and fields options are up-to-date.

Now, we need a simple change in ftl:

Please notice the model.getParsedString(stringToParse) method. It is the only difference between the original STK TextImageModel and our new RotatingTextImageModel.

And now use it:

with this result:

If we change the configs, the final output is:

And that’s it.

Drawbacks:

  1. Content is stored in locale.properties files. The project case requires this, but in other environments / projects you may want your users to edit text. It can be easily made with a group-paragraph pattern where you define each values with their validity periods. You loose flexibility and extensibility, but you gain in user friendlyness
  2. You have to change the ftl. This is because original stk templates uses direct content access (e.g.: ${content.text}) instead of model class invocation.
  3. Need to exclude from cache or to configure browser cache policy and cache policy to force flush when message should be changed. Thanks Jan!
  4. Any other? Please tell me!

Latest articles

Matteo Pelucco Written by:

2 Comments

  1. Jan
    October 25

    3. need to exclude from cache (or to configure browser cache policy and cache policy to force flush when message should be changed)?

    Other then that. Cool. 🙂

  2. Matteo Pelucco
    October 25

    Hi Jan, it is something really simple (and stupid) but mixes i18n, hot config, stk, modelClass..
    And yes, sure.. my project works without cache so I simply forget this.
    You are right! Flush mechanism or cache deny policy should be implemented.

Leave a Reply

Your email address will not be published. Required fields are marked *


eight − 3 =