Remember when I wrote about how I blog? How I mentioned the empty note called “Hierarchical Data Elements”, and couldn’t remember what I had intended to write?
As usual, I found a snippet of text the day the article went live, and so I am now able to return to my normal schedule and proudly present: Hierarchical Data Elements!
But when you use code, any code, the DRY principle applies: don’t repeat yourself!
DRY is a fundamental best practice or principle in coding. It says that if something is important or needs thinking or coding, it should not be repeated in multiple places. Instead, it should be contained in some unit and then re-used.
Well, a) you are much less likely to mess something up if you do it in one place as opposed to all over the place, and b) if you ever want to change it, how likely are you going to forget one of the places? Yeah, very likely.
So, DRY it is, and that raises an important question for us: Can I adhere to DRY with DTM?
My take is that with Rules, I can. Between Web Properties, I currently cannot, but who knows, Launch might change that one day.
How about Data Elements?
Say I have one called
Sitesection, and another called
Pagename. On my blog, the
Sitesection DE is “blog”, and a
Pagename might be “blog/hierarchical_data_elements”.
Even my under-developed, half-forgotten, rudimentary dev skills scream at me to re-use the
Sitesection Data Element when I calculate the value for
The technical answer to the problem is surprisingly simple.
The trick is to create the
Pagename DE as a “Custom” DE, then inside the code editor, calculate the page name, then append it behind the section, which comes straight out of the
return _satellite.getVar("Sitesection") + "/" + pagename;
Super easy, isn’t it?
And that’s it for today. All I wanted to tell you is that
- You can read a Data Element value using
- You should do so
Now go and do good!