Fortuitous Naming

Naming files and objects in a way that makes using them easier and more efficient


In the last article, we looked at a concrete example showing a particular chunk based a User Setting named custom_theme using a dedicated snippet. In this one, we'll look at an easier method that works without any snippet or output modifier. It's a method I like to call "fortuitous naming."

MODX logo

Quick Review

In the previous article, we used a snippet with a switch statement to show one of four different chunks depending on the value of the custom_theme User Setting. Here are the tag and the snippet:

[[!AddChunk]]
/* AddChunk snippet */

$chunkName = '';

$themeName = $modx->getOption('custom_theme');

switch ($themeName) {
    case 'midnight':
        $chunkName = 'chunk1';
        break;

    case 'lakeview':
        $chunkName = 'chunk2';
        break;

    case 'seaview':
        $chunkName = 'chunk3';
        break;

    default:
        $chunkName = 'defaultChunk';
}

return $modx->getChunk($chunkName);

return $output;

A Better Way

It might have occurred to you that calling our chunks chunk1, chunk2, and chunk3 was kind of dumb, since the names tell you nothing about what's in the chunks. It makes much more sense to name them after our three themes: midnight, seaview, and lakeview. What's fortuitous about this naming scheme? It allows us to do away with the snippet altogether and just put this tag where we want the chunk's content displayed:

[[!$[[++custom_theme]]]]

In case you don't recognize the structure, this is a setting tag inside a chunk tag. The inner tag, [[++custom_theme]] is parsed first, and is replaced by the value of the User Setting, leaving a standard chunk tag like this: [[!$midnight]]. Since we have a chunk named "midnight," its content will replace the remaining tag on the next pass of the parser.

When you have nested tags like this, be careful not to call the inner tag uncached (with the exclamation point). Making a tag uncached delays its evaluation. The outer tag needs the inner tag to have been evaluated and replaced. If you delay evaluation of the inner tag by making it uncached, the outer tag may fail. In this case, it would be evaluating the inner tag itself rather than the value of the User Setting.


Fortuitous Naming

Call this "fortuitous naming" because it allows you to use the actual names of things in both tags and PHP code. A few articles ago, we saw the same thing with CSS files placed in directories named for the theme they supported. With all main CSS files called theme.css all you need to load one is a single tag containing a setting tag for the theme name. Here's the directory structure:

assets
    components
        mysettings
            themes
                midnight
                    theme.css
                lakeview
                    theme.css
                seaview
                    theme.css

Once the files are in place and the custom_theme setting holds the name of the theme, all you need to load the CSS is a line like this:

<link rel="stylesheet" href="[[++assets_url]]components/mysettings/themes/[[++custom_theme]]/theme.css">

What about a Default Chunk?

Our "Better Way" above selects one of three chunks based on your System Setting, but what happens when no User Setting has been set? You might think an output modifier would be the best solution for this, but there are several approaches that are more efficient at handling the case where no User Setting for custom_theme has been set.

If you would like nothing to appear if there's no custom_theme User Setting, you don't have to do anything at all. When MODX fails to find the chunk, it will simply remove the tag.

If you would like to use one of the three existing chunks as a default chunk if no custom_theme User Setting exists, just create a custom_theme System Setting with the name of that theme as the value. If there is no User Setting with that key, the System Setting will be used.

If you have a fourth chunk that you would like to use as the default when there's no custom_theme User Setting, create the chunk, create a custom_theme System Setting, and put the chunk's name in the value of the System Setting. Again, the System Setting's value will be used when there's no custom_theme User Setting


Coming Up

It's usually easier to create settings in the Manager, but suppose that you're creating an extra. In that case you won't have access to the Manager when the extra is being installed. You'll need to create the settings in code in a resolver for your package. We'll look at how to do that in the next article.

 


Looking for high-quality, MODX-friendly hosting? As of May 2016, Bob's Guides is hosted at A2 hosting. (More information in the box below.)



Comments (0)


Please login to comment.

  (Login)