AmpScript Functions Outputline & Output. Only usable with inner function (concat,v)?

Question

Ampscript:

%%[
Output('1<br/>')
OutputLine('2<br/>')
Output(Concat('03<br/>'))
OutputLine(Concat('04<br/>'))
Output(v('05<br/>'))
OutputLine(v('06<br/>'))
]%%

Output

03
04
05
06

1 and 2 are not printed because of no Concat or v function. It does not matter if you use " or ' the output is always the same.

• Why do i have to use concat inside Output and Outputline to print a text?
• Is this supposed to work this way?
• Does anybody know the reason why 1 and 2 are not printed?
  • Do these functions change the Object / Wrap it in some kind of way?

Quote from Adam Spriggs and Elliot Harpers AMPScript Guide:

NOTE: This function will only return a result from nested functions. It will not return a result if only a variable is used as an argument.

Still think that this is should work different. Therefore i would call that a bug.

Answer 1

This function will only work with a nested function, as described in the documentation and in Adam and Eliots AMPScript guide, as you mentioned.

The purpose is really just to push variables or other code blocks into content on the email/webpage. This is not designed to work like Write in JS, which works with raw strings as well.

The general use cases are for pushing out variable declarations while preventing the need to break code blocks to push content into the email.

For instance:

%%[

SET @myVar = Lookup(....)

OUTPUT(CONCAT('myVar = ', @myVar))

]%%

or

%%[

  SET @myVar = 'myVar'

  OUTPUT(v(@myVar))

]%%

I generally use OUTPUT() and OUTPUTLINE() for debugging - to remove unecessary breaks in the script tags and it makes it easier to search and remove them when finished.

e.g.

Use

%%[ 

  SET @myVar = Lookup(...)

  OUTPUT(v(@myVar))

  SET @myVar2 = 'stuff'

  OUTPUT(CONCAT('<br />', @myVar2))

]%%

instead of:

%%[ 

  SET @myVar = Lookup(...)

]%%

<p>%%=v(@myVar)=%%</p>

%%[

  SET @myVar2 = 'stuff'

]%%

<p>%%=v(@myVar2)=%%</p>

I also want to note that just because something doesn't work the way you feel does not make it a bug - especially when the documentation explicitly says it does not work like that. People use the word 'bug' too often in development to cover ignorance or user error - which can severely slow down production and efficiency as it forces developer resources to investigate 'red herrings' instead of improving or maintaining it.