11

我们有一个选项卡式界面，其中一个选项卡内是一个隐私表单。这种隐私表单，以及在其大部分工作中使用外部 JavaScript 文件，还使用内联 JavaScript，因为它目前依赖于动态代码（在服务器端语言中）。

formTabs 包装器（没有回调函数的 ajax 选项卡）

...
<script type ="text/javascript">
    var messagingTabset = ProjectName.Tabset.init({
        'tabID': 'preferences-tabset',
        'ajaxUrl0': '<%=Url.Action("PreferencesMainForm", "Profile")%>',
        'ajaxUrl1': '<%=Url.Action("ProfileImageForm", "Profile")%>',
        'ajaxUrl2': '<%=Url.Action("InterestsForm", "Profile")%>',
        'ajaxUrl3': '<%=Url.Action("PrivacyForm", "Profile")%>',
        'ajaxUrl4': '<%=Url.Action("PasswordForm", "Profile")%>',
        'ajaxUrl5': '<%=Url.Action("CustomUrlForm", "Profile", new {userId = Model.UserId})%>',
        'defaultAjaxUrl': '<%=Url.Action(Model.PartialName, "Profile")%>'
    });
</script>
...

privacyForm 视图（更多带有服务器端代码的内联 javascript）

...
<script type = "text/javascript">
    var preferencesPrivacyForm = new ProjectName.AJAX.Form({
        "ajaxFormID": "preferences-privacy-form",
        "actionUrl": '<%= Url.Action("SavePrivacy","Profile") %>',
        "dataReturnType":"json"
    });
</script>
...

后端开发人员：“此表单的配置 JavaScript 代码应保留在 privacyForm 视图中”

前端开发人员：“嗯，我确定我已经读过这不是执行此操作的方法 - 不可靠，所有 JavaScript 都应该在包含选项卡包装器的 HTML 页面内，在该选项卡加载的回调函数内. 你真的应该 a) 为我提供逻辑，让我在 tabs-wrapper 中获取动态数据，或者 b) 让我通过 DOM 遍历获取这些动态变量”

后端开发人员：“这两种方法都需要做大量工作却没有真正的回报！第一个例子很糟糕，因为这意味着我将不得不改变它的构建方式（并且工作正常）。这可能会意味着重复。第二个例子是狡猾的，因为标记可能会改变，所以处理代码的人可能会忘记编辑选项卡包装器中的 DOM 遍历方法。这是我们不需要的另一个抽象级别。如果你提供我有一些证据说明为什么这真的很糟糕，然后我会检查一下，但否则我无法证明投入时间是合理的”

前端开发人员：'好吧，我已经浪费了几天时间，通过将 AJAX 加载的 JavaScript 放在其包装器的回调中来解决问题，但是现在你想一想，关于这类事情的一个很好的参考真的是很好，因为您是对的，目前，该应用程序正在运行，没有任何问题。

这是整个大型应用程序中使用 Ajax 加载内联 JavaScript 的众多示例之一。

我应该说服后端开发人员我们应该使用回调，还是我错过了什么？

4

4 回答 4

5

我建议阅读戴尔·卡内基的《如何赢得朋友和影响他人》。

开发人员似乎经常陷入这种情况，他们知道什么是最好的事情，但他们没有得到其他开发人员或管理层的支持。

这本书绝对值得一读；绝对必须阅读这个职业。

于 2010-06-16T08:23:19.533 回答
5

只要它服务于某个目的（例如，它从其他网站（如 WordPress 仪表板）加载内容），它并不是真的“坏”，但是除非你绝对必须这样做，否则对服务器进行所有额外的调用是一种资源浪费做。

通常，最简单的答案是最正确的答案。在这种情况下，这意味着不添加所有额外开销以避免稍微重新编码后端。

于 2010-06-16T15:16:11.993 回答
1

这就是为什么不显眼的 Javascript (UJS) 是好的争论的核心。我从不理解它的优点，因为我不知道如何在没有内联 Javascript 的情况下解决问题。我终于学会了。

首先，UJS 很好，因为它将你的前端代码分开如下：

  1. HTML - 纯 HTML 用于构建您的信息。
  2. CSS - CSS 用于设置文档样式和布局。
  3. Javascript - Javascript 用于定义页面的行为。

为了使它们一起工作，HTML 文件加载外部 CSS 文件来定义样式和外部 Javascript 文件来定义行为。此外，您的 HTML（例如 id、类名和标签）、CSS（id 和类规则）中需要众所周知的符号，以便您的 Javascript 可以根据实现的行为来操纵结构、布局和样式。

使用 jQuery 等 Javascript 框架，您可以将 javascript 处理程序动态绑定到各种 HTML DOM 对象上的事件。这使您可以避免在 HTML 中内联执行它。

我曾使用过清晰分离的代码（结构、样式/布局、行为）和 HTML、CSS 和 Javascript 的狗早餐代码，包括使用 ERB 动态生成的 HTML/JS 代码。由于不同的原因，两者都难以理解。第一个很难，因为我必须理解每个文件中的内容，而混合代码很难理解，因为我必须弄清楚什么是 JS、什么是 HTML、什么是 CSS、什么时候初始化以及什么生成了。然而，一旦我踏上了学习曲线，进化干净分离的代码就更少了，也更容易测试。

对于生成的 Javascript（例如，使用 ERB），您通常可以在您拥有由某些用户特定或上下文特定数据驱动的静态 javascript 的位置构建代码。正如前人所建议的那样，您可以在 HEAD 部分中设置该数据的值，然后使用静态 Javascript 文件。您还可以使用 AJAX 调用从服务器获取相同的数据。

从短期业务的角度来看，后端人员是对的。如果它有效，请不要修复它。从中期来看，如果您不将 HTML、CSS 和 Javascript 与 UJS 完全分开，您的团队将花费更多来发展和维护您的代码。从您的业务角度来看，您将很难像现在一样维护和发展代码。从后端人员的业务角度来看，如果他做的不是今天的工作，他会付出更多的代价。即，您的团队领导和架构师需要平衡各种业务观点，以确定构建代码的方式。

于 2010-06-24T14:33:58.857 回答
0

从示例中不清楚为什么首先需要 AJAX。为什么不直接放

<script type ="text/javascript">
    var userId = "<<<<= userId >>>>"
</script>

直接进入HTML头？它对用户来说更快，在服务器上更容易，并且您避免了对失败请求的计时和错误处理的各种痛苦。

于 2010-06-21T19:12:19.043 回答