Mosquitoes don't serve any useful purpose; they should be eradicated from the planet!
I've heard this or similar feelings expressed since I was a child. I've even felt this way myself after a particularly bad night outdoors leading to hours of painful itchiness. As annoying as they are, carrying dreadful disease, killing a great number of human beings every year, surely it would be a better world without mosquitoes buzzing around trying to find some blood to suck. Even a number of scientists argue that eradicating them may have some collateral damage, but assert that life would find a way to fill the gap left behind.
But who likes collateral damage, especially uncontrolled? No one really knows what the true scope of that damage would be without taking what boils down to an unnecessary risk. Considering the controversy, difficulty, high-cost, and unpredictability of trying to eradicate what we don't like, the best alternative in my estimation, is arming ourselves with knowledge against the known threats.
How Conditionals are like Mosquitoes
I've proudly expressed my disdain for using conditional tags or filters in MODX content since before MODX was founded. But, like carefully considering the consequences of eradicating our friend the mosquito, several experiences collaborating with MODX users on optimization projects made me realize they can be very useful tools. I also started to realize most of my objections to them were in the way they were being used in the presentation layer, leading to unnecessary performance problems.
So now, instead of just continuing to hope for their expedient eradication, I'd like to share some explicit details on how you can best use them, and why. Armed with a little knowledge of their potential pitfalls, you can make effective use of conditionals in your presentation layer while maintaining performance of the Resources you use them in.
Practical Protection from the Blood Suckers
Since we are not going to send a fleet of aircraft to spray toxic chemicals on our site to rid it of the annoying conditionals, making ourselves sick in the process, we must first identify what the actual threats of co-existing with them are. The disease conditionals most often bring to our sites is called performance degradation.
While this may seem like a potentially fatal disease, especially in sites that might already suffer similar ailments from other sources, there is actually a fairly easy way to avoid it's symptoms. It boils down to one simple concept that takes advantage of the MODX parsing engine's strengths, while avoiding it's weaknesses.
Build Tags As a Result of a Conditional, Not in Conditional Results
Yep, it's as simple as that.
Often times I will see content in MODX that contains the use of conditionals and cringe when I see it. Why? Because more often than not, there will be a complete tag located in both the then and else results. And why is this bad? Because regardless of which result is selected by the conditional assertion being made, MODX will still process the tags in both conditional paths before even considering the the result of the logical comparison.
This may not sound that bad, and in some cases it causes no real noticeable problem. But in too many cases, this can severely reduce performance without leaving any clues as to why. I first realized the potential scope of the problem when trying to provide default content for Resources through a Template Property.
[[*content:default=`[[+defaultContent]]`]]
Because the default output filter is not applied until after embedded tags are processed, every Resource using this Template always evaluated the defaultContent property regardless if the content field was empty or not. Since my defaultContent contained some Chunks that included Snippets and other MODX Tags, all of those got parsed too, even if the filter conditions failed. The resulting parsed output of the property was then discarded, and the content field was finally returned to be processed.
Luckily, after considering this recurring problem with a little more intensity, I finally realized that this problem is completely avoidable. By approaching conditionals armed with the knowledge of the threat, it is quite easy to avoid any performance degradation when using conditionals in your MODX presentation layer. Just do not embed MODX tags as results for your conditional expressions. Instead, construct MODX tags from the result.
Let's look at an example using conditional filter expressions that have multiple conditional paths. Here is a simple conditional that can quickly become a drain on performance because of the order of parsing:
[[*field:is=`0`:then=`[[!SomeScript]]`:else=`[[$SomeChunk]]`]]
Guess what happens when MODX parses this tag?
- Each of the tags contained in the then and the else conditional paths are parsed,
- The *field tag itself is parsed and
- Finally, the conditional filter is applied.
In other words, regardless of the result of your conditional comparison, everything in both conditional paths is executed recursively to it's logical end. How big of an unnecessary burden this becomes depends entirely on the nature of the tags involved. But you can see how it can quickly get out of control when many conditionals are involved.
The brilliantly simple way to avoid this problem? Just return what's between the MODX tags and have the result of your conditional build what is going to be parsed next by MODX.
[[[[*field:is=`0`:then=`!SomeScript`:else=`$SomeChunk`]]]]
That's it. Don't give MODX the chance to take your tags and run with them when embedded as results in conditional paths. Make it wait until you've evaluated your condition to do anything about it.
Better than a laser zapper, I can tell you that.
Accepting the Things I Cannot Change
It feels good to no longer wish for the eradication of something I've regarded as a pest for so long. Sometimes a little deeper consideration than we are willing to give an idea can reveal a lot about how we should best deal with it. Consider the mosquitoes!