Quick question We have one of our team who likes t...
# suitescript
m
Quick question We have one of our team who likes to write templates this way:
Copy code
let template = "";

      template += '<?xml version="1.0"?>';
      template +=
        '<!DOCTYPE pdf PUBLIC "-//big.faceless.org//report" "report-1.1.dtd">';
      template += "<pdf>";
      template += "<head>";
      template +=
        '<link name="NotoSans" type="font" subtype="truetype" src="${nsfont.NotoSans_Regular}" src-bold="${nsfont.NotoSans_Bold}" src-italic="${nsfont.NotoSans_Italic}" src-bolditalic="${nsfont.NotoSans_BoldItalic}" bytes="2"/>';
      template += "<macrolist>";
      template += '<macro id="nlheader"></macro>';
      template += '<macro id="nlfooter"></macro>';
      template += "</macrolist>";
      template += '<style type="text/css">';
      template += "* {font-family: NotoSans, sans-serif;}";
Is that pattern common?
admiral akbar 1
d
Hi, is this a customized xml that build inside Suitelet?
m
Yes
Usually I write a template on the front-end, and render the template from the Suitelet. But just wanted to know if this pattern is common.
d
I see ... I dont think thats common tbh. Because it is really hard to maintain the code in such a way, especially for that "template+=" for each line. Would prefer to have an xml file that contains the template, then render this xml file in the Suitelet.
t
Same, best to maintain it in the advanced PDF template rather than the code for allow for seperation
d
assuming you are using SuiteScript2.1, I'd say refactoring to instead using multi-line template string literals would make more readable at least https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals
☝️ 1
m
Thanks ❤️, just wanted to make sure before I ask him to consider changing it.
1000000 1
b
you build the string if you never plan on touching it again
its especially bad if you have a syntax error in it somewhere since strings wont give any help finding it
m
@battk You mean it could make sense if I know it won't be too much struggle developing it this way, and kind of package it with the script without the hassle of connecting them every time you deploy it?
b
its a hard to maintain mess that only makes sense if you wont be the one making changes to it later
m
Hmm, will keep that in mind too, thanks.