Launch - Allow fields to use data elements that return an array

[#1]

I can create a Data Element of type javascript variable, or custom code, that references/returns an array.  However, Launch (and DTM) doesn't have any functionality baked in to take advantage of this.  Instead, it ultimately expects a string value returned (and type casts the value to string when parsing %data_element% syntax references to enforce it). 

Meanwhile, you have for example Adobe Analytics hier variable, which would benefit from being able to reference an array.  As of right now you just provide 4 fields and i can reference 4 separate data elements (or hardcode 4 separate values).  But in practice, I can have more than 4 levels in a hier variable. 

I think it should be a pretty easy update to the Launch interface to just have the hier[n] variables be a single field to reference a data element that returns an array, and a field to specify a delimiter (already implemented), and then under the hood, check if the returned data element value is an array and then join by delimiter and call it a day.

This same concept can also then be applied to adding list[n] variables in the AA extension, and also for list prop syntax, and also for.. well, any field, really.  Maybe put a little checkbox next to it to flag to expect an array and then make the delimiter field appear if you check it. 

Seems like an easy win to me?

.josh

[#2]

On the surface this sounds great. I was eager myself to do something similar myself and started digging around the Launch source code to see if it was feasible. Unfortunately there are a few concerns:

1) Any data element can be passed to the configuration of any extensions. This means that if you allow a data element to contain an array, you don't just need to update the launch core to handle it, but all extension providers would need to take into account that they might be passed arrays and offer similar methods of handling it.

2) Launch allows the user to type in multiple data elements in a single field. For example: '%productname% - %modelnumber%' could resolve to something like 'Ceiling Medallion Pro - 2000'. This feature heavily assumes that all data-elements will be reasonable when cast to a string. If arrays were allowed, users would have to know and keep track of which data elements were arrays and avoid attempting to use them this way.

In your specific case, since you're writing custom code anyway, I'd recommend making the variable a string before you return it, for example "return my_arr.join('/');" instead of "return my_arr;" This lets you explicitly make sure the value is exactly what you intend.

[#3]

Hello Cody,

Thanks for the feedback!  Here are my thoughts about your concerns:

1)  Three counter points to this, in no particular order:

I don't think Adobe should have to be stuck or otherwise gimped on not being able to expand functionality of Launch because of trying to cater to Extensions.  Extension providers build from / piggyback off Launch; not the other way around. That's like jQuery saying they won't make a change to their core library because a lot of user-made extensions out there do things a certain way.  It's just not a realistic standard to strive for, nor should Adobe have to.  The middle ground has always been to maintain backwards compatibility for a certain amount of cycles.

Further,  I had also mentioned this in Slack #measure > #adobe-dtm (there isn't a #adobe-launch at this time).  The responses received from Adobe there, is that Launch does not cast returned DE's to strings when passing data to extensions.  DE's are exposed untouched, and it is up to extensions to do what they will with it.  So it is not the core Launch lib casting DE returned values as strings - it is extensions such as AA casting them to string for their own variables/fields.

And to further call out this scenario in particular: as a best practice, extension providers should already be validating the data they receive from external sources.  This is programming 101. So, there shouldn't be any code updates required for extension providers, unless they aren't following best practices to begin with.

2)  Two counter points to this, in no particular order:

All kinds of junk data can be pushed to tags. Being a string value (vs. other type) is largely incidental and has nothing to do with that.  Or put it another way.. it is common to configure DE's from things that aren't solely string values.  Anything from URL param values from a parsed URL, to attributes in an HTML element targeted by some selector, to referencing a property in a larger object.  Throwing arrays into the mix isn't going to change or complicate any of that, because arrays (and other non-string type "sources") are already part of the flow. Ultimately, it is the client who should validate implementation, not Launch.

Having said that, Launch can be updated to help make it easier for clients to keep track of what DE's return what.  For example,  a field can be added for a user to specify expected return types, and Launch can visually show it the DE listing, or as a popup when referencing a DE in a field if default/string type is not specified, etc.

Yeah, as a workaround I could write my own custom code to ultimately return a string.  But... the whole point of Launch (and TMS in general) is to minimize custom coding as much as possible.  "Just use a custom code box w/ your own code" should always be treated as a last resort not-ideal option, not a convenient go-to solution.

By the way, the AA extension (and you can see this in DTM, as well)  already casts array to a string, which by default implodes/joins to a comma. So this "feature" is already effectively implemented - assuming your desired delimiter is a comma. The ask is to more formally expand on it.

[#4]

Thanks for the comment to this question. 

I am simply trying to get multiple data elements into a single data element field.  Specifically, how is this done?

Which data element type should I select?  What should be added to the text field?

Thanks

[#5]

Josh,

Good points overall and I don't have much to disagree with.

You're right of course that extensions should be type checking and flexible, though I think the "launch does not cast DE's to strings" answer you got on the slack was only half true. If you look here: https://developer.adobelaunch.com/guides/extensions/views/#supporting-data-elements​ under the heading "Data element token replacement methodology" it looks like the value is left alone (can be an array, even a function) if a single data element token is used, but if the user enters multiple tokens in any way, they'll always be *stringified*. So your extension should expect that it *can* receive anything, but there are still cases where it will be cast to a string before it gets to the extension.

There isn't a ton launch itself can do to affect what happens when a user configures a data element or uses it in an extension configuration. All of those views are actually iframes and are almost 100% extension code that launch doesn't really try to hijack. However, the default "data element selection window" that pops up when you want to fill in a field with a DE is something provided by the launch library, so that's point of opportunity. Sure, an extension doesn't have to use that pop-up, but most will. And extensions providing Data Element types do have a way to tell launch whether they'll be a string, number, etc.

So... assuming a data element coming from an extension that defined its type well, and an extension using the launch provided "choose a data element" dialogue, that would be a spot where we can do what you mention. Detect elements that may need to be serialized (like array's / objects) and give the user some options. I've changed my downvote to an upvote on this because I think that particular spot is worth looking into. You've won me over. ; )

I do want to take a moment to respond to the one thing I disagree with you on though. This piece of your response:

"Extension providers build from / piggyback off Launch; not the other way around. That's like jQuery saying they won't make a change to their core library because a lot of user-made extensions out there do things a certain way.  It's just not a realistic standard to strive for, nor should Adobe have to."

That standard is actually one Adobe chose for Launch, and I think it was a brilliant choice (and a major reason why I think give Adobe more credit than I usually do when they market Launch as a revolutionary product.) Every Data Element Type, Event, Condition and Action that you string together to build Rules in Launch is provided by an Extensions. Even the "out-of-the-box" features are served up by a "core extension", which is maintained in house, but from an architecture perspective looks no different to "launch core" than any other extension.

Launch itself (in so far as it has a "core") is a tool for configuring these extensions, stringing them together in rules, and building/publishing those rules as libraries (with administration features like which users can approve which changes, etc). To really simplify it, Launch is "tooling provided around extensions". So whenever we talk about how Launch will/should grow and change, we've got to talk about it with an "extension first" perspective. They're not, in fact, piggy-backing on like jQuery libraries. They're the very fabric of what launch does.

[#6]

Thanks for the good conversation around this. joshd7227840, I believe your request concerns the Adobe Analytics extension specifically; nothing in the underlying Launch platform prevents it from happening. Right now the owners of the Adobe Analytics extension could provide a textfield whereby you select a data element whose value is an array and, at runtime, the extension would receive the array (not stringified) and could do whatever it wants with it. Your request should probably be funneled to the Adobe Analytics team so I'll work with someone to take note of this. Thanks for bringing it up.