Forward Support in Launch for DTM's _satellite.getVar("window.

[#1]

In DTM,  _satellite.getVar will honor the "window." prefix in the first argument.

In Launch, this is not supported.

For example :

_satellite.getVar("window.digitalData.page.pageInfo.pageName")

It is fairly common practice in DTM to use the above as it will fail gracefully if any part of the nested object is undefined.

The same problem exists for "param.", "event.", "rand", and "target." prefixes

These may present migration hurdles for some DTM implementations.

The DTM to Launch Migration Assessment at https://www.searchdiscovery.com/solutions/partners/adobe/adobe-launch/dtm-launch-assessment/  presently flags these cases as issues that will need to be fixed when migrating.

[#2]

I agree that this would be a good feature, especially if it was working in DTM.

But for this example case I would create data elements pointing to the datalayer anyway. With the ContextHub Extension and a custom JSON Schema this is rather comfortable to do and as far as I know there it also fails gracefully.

[#3]

Agreed, there are many ways to skin a cat.  I had logged this as an issue in launch-beta a long time ago, but it didn't get any response. I logged this here as an idea since _satellite.getVar has been on the list of DTM functions that are meant to be forward compatible to Launch.  I'd expect the function to work as it did in DTM and have deprecation notices if being used in a way that is not intended for long-term support. 

[#4]

Whoa, I didn't know this was an option in DTM.  This is such a streamlined way to interact with data layers without having to utilize a new data element or making sure you are being really defensive in your coding.

Thanks for bringing this up Stewart - a great feature/idea that I wish I knew back with DTM