Question

我一直在争论反对在JavaScript代码中嵌入服务器端标签，但今天被一个看起来不相信的开发人员放在了现场

有问题的代码是一个遗留的ASP应用程序，虽然这在很大程度上并不重要，因为它同样适用于ASP.NET或PHP（例如）。

有问题的例子围绕使用他们在ServerSide代码中定义的常量。

'VB
Const MY_CONST: MY_CONST = 1
If sMyVbVar = MY_CONST Then
    'Do Something
End If

//JavaScript
if (sMyJsVar === "<%= MY_CONST%>"){
    //DoSomething
}

我反对的标准论点是：

脚本注入：服务器端标记可能包含可以破解JavaScript代码的代码
单元测试。更难以隔离代码单元以进行测试
代码分离：我们应该尽可能地保持网页技术的分离。

这样做的原因是开发人员不必在两个地方定义常量。他们推断，因为它是一个他们控制的价值，所以它不受剧本注入的影响。这减少了我（1）“我们试图保持标准简单，并定义例外情况会让人感到困惑”的理由“

单元测试和代码分离参数也没有用水，因为页面本身是HTML，JavaScript，ASP.NET，CSS，XML的可怕混合......你说出来，它就在那里。没有任何代码可以进行单元测试。

所以我发现自己觉得自己觉得有点迂腐，坚持认为代码是根据情况改变的。

是否有任何进一步的论据可能支持我的推理，或者我，实际上在这种坚持中有点迂腐？

Answer 1

脚本注入：服务器端标记可能包含可以破解JavaScript代码的代码

因此，请正确编写代码，并确保在引入JavaScript上下文时正确转义值。如果您的框架不包含JavaScript“引用”工具（提示：您可能只需要JSON支持），请写一个。

单元测试。更难以隔离代码单元以进行测试

这是一个很好的观点，但如果服务器必须将内容放入页面以供代码使用，那么这是必要的。我的意思是，有时候必须这样做。一个好方法是让页面包含某种最小的数据块。因此，页面上的服务器端JavaScript实际上不是要测试的“代码”，它只是数据。 .js文件中包含的真实客户端代码可以查找数据并使用它。

因此，该页面可能包含：

<script>
  (function(window) {
    window['pageData'] = {
      companyName: '<%= company.name %>',
      // etc
    };
  })(this);
</script>

现在，“。js”文件中包含的精美封装的纯JavaScript代码只需检查window.pageData，就可以了。

代码分离：我们应该尽可能地保持网页技术的分离。

同意，但事实上有时服务器端数据需要驱动客户端行为。为了存储数据和满足你的规则而创建隐藏的DOM节点本身就是一种非常难看的做法。

编码规则和美学是好事。但是，一个人应该务实，并把所有事情都放在眼里。重要的是要记住，这些规则的上下文并不总是完美的神圣创造，在HTML，CSS和JavaScript的情况下，我认为这个事实非常清楚。在这样一个不完美的环境中，强硬的规则会迫使你进入不必要的工作和实际上难以维护的代码。

编辑 - 哦，这是我刚才想到的其他内容;妥协。 jQuery帮派利用他们的“微模板”设施（部分）推广的“伎俩”（对于实际上首先遇到此问题的网络天才道歉）是使用<script>标签，这些标签是“绝对的” ：

<script id='pageData' type='text/plain'>
  {
    'companyName': '<%= company.name %>',
    'accountType': '<%= user.primaryAccount.type %>',
    // etc
  }
</script>

现在浏览器本身甚至不会执行该脚本 - “type”属性不是它理解为代码的东西，所以它只是忽略它。但是，浏览器做使这些脚本的内容可用，因此您的代码可以通过“id”值找到脚本，然后通过一些安全的JSON库或本机浏览器API（如果可用）解析表示法并提取它所需要的东西。这些值仍然需要正确引用等等，但是你在XSS漏洞中更安全，因为它被解析为JSON而不是“实时”完整的JavaScript。

Answer 2

The reason for doing this was so that the developer did not have to define the constant in two places.

对我来说，这是一个比你可以反对它的任何争论更好的论据。这是DRY原则。它极大地增强了代码的可维护性。

每一个极端的风格指南/规则都会导致反模式。在这种情况下，您坚持技术分离会破坏DRY原则，并可能使代码难以维护。即使DRY本身如果被置于极端也会导致反模式：softcoding。

代码可维护性是一个很好的平衡。风格指南有助于保持这种平衡。但是你必须知道这些导游什么时候有帮助，什么时候他们自己成为问题。

请注意，在给出代码的示例中，代码不会破坏语法hilighting或解析（甚至stackoverflow hilights它正确），因此IDE参数不起作用，因为IDE仍然可以正确解析该代码。

Answer 3

它变得难以理解。你必须仔细看看划分不同的语言。如果JavaScript和混合语言使用相同的变量名称，情况会变得更糟。对于那些不得不看别人代码的人来说，这尤其困难。
许多IDE在重混文档的语法突出显示方面存在问题，这可能导致自动完成功能丢失，语法突出显示正确等等。
它使代码不再可用。想象一下执行常见任务的JavaScript函数，比如回显一系列事物。如果将JavaScript逻辑与其迭代的数据分开，则可以在整个应用程序中使用相同的函数，并且对此函数的更改只需执行一次。如果它迭代的数据与JavaScript输出循环混合，你可能最终会重复JavaScript代码，因为混合语言在每个循环之前都有一个额外的if语句。

反对在JavaScript代码块中包含服务器端脚本的争论是什么？

3 个答案: