微软在 jQuery 中数据链接的提案。 征求反馈。
微软 向 jQuery 项目提交了他们的第二个提案，概述了一个允许在对象中将属性彼此链接的插件。 称为“数据链接”，这个新插件将允许对一个对象属性的更改影响到第二个对象的属性的更改。 插件利用 jQuery 的“特殊事件”API 创建一个新的事件，当绑定对象属性发生更改时将触发。 这将允许开发人员以以下方式链接属性
var person = {};
$(“#name”).linkTo(“val”, person, “name”);
$(“#name”).val(“foo”);
alert(person.name); // foo
// … 用户更改值 …
alert(person.name); // 用户输入的值
该提案已通过 jQuery 论坛提交，微软正在积极征求社区反馈
http://forum.jquery.com/topic/proposal-for-adding-data-linking-to-jquery
数据链接的原型可通过 Github 获取以供审查
http://github.com/nje/jquery-datalink
我们很高兴看到微软对我们开源社区的持续贡献，并请您提供反馈意见，以指导这项工作的进行。
这太棒了。 我一定会试一试。
哇，我一直在想这样的东西在我的当前项目中会多么有用。 干得漂亮，微软。
好吧，我写了另一个插件，现在可以丢掉了。 :]
哇... linkBoth 让我很开心！ 安迪，我和你一样 - 我现在可以丢掉我写的一个插件了。 这个比我写来完成类似事情的垃圾要好得多。
人们如何看待这个被使用？ 它可以接受函数而不是属性来回调吗？ 这可能对挂钩 AJAX 请求很有用，但更改事件也能做到这一点。
我通常尝试避免状态保存在多个地方，这似乎鼓励这样做。 但它可能有助于提高性能，因为人们不必在 DOM 中查找这些值。
它涉及到为 jQuery DOM 修改器发送特殊事件的潜在有用想法。
我喜欢这个想法，语法对我来说很有效 - 我可以清楚地看到它的用途，并且很乐意立即在当前的一个或两个项目中使用它 - 但想知道为什么它是核心库的一部分，而不是微软托管的 jQuery 插件？
很棒的补充，这在开发中肯定会派上用场。
这确实很有帮助。
请继续努力…
我认为我会支持这个扩展。
如果没有为它定义 ConvertFn 的能力，我会不太感兴趣，但是有了它，它看起来非常有用。
我唯一担心的是它是否会因为它对数组等的监控而增加过多的负载。
我唯一想做的改变是能够直接提供转换器代码，而不是必须注册转换器函数。 例如...
var person = {};
$(“#name”).linkTo({
sourceAttr: “val”,
target: person,
targetAttr: “favoriteColor”,
converter: function(value, settings) {
return settings.map[ value ] || value;
},
map: { red: “#FF0000”, blue: “#0000FF” }
});
$(“#name”).val(“red”);
alert(person.age); // #FF0000
否则，我认为我喜欢它。
@Justin Meyer
简单的例子是使用 JSON 的 AJAX 调用。 想象一下，在提交时不必处理值，想象一下您的数据（JSON 对象）随着表单的更改而更改（当用户输入时）。 在那里，不需要将表单数据处理成 JSON。
（当然您可以直接序列化表单，但嘿，一旦您将表单输入挂钩到您的数据（JSON）对象，您甚至不需要序列化一次）
好想法。 尤其是在使用 AJAX 的 MVC 应用程序中，拥有这个功能会很棒。
怎么样一个 unLink（或 removeLink）方法？ 此外，getLinks 可能会很有用。
听起来很适合 View = View 模型绑定！
我在过去几年中构建了许多项目，本来可以在这上面使用它。
我想看到是否可以传递一个表单或其他 jQuery 标识符，让插件匹配所有现有字段。 假设我的数据对象和 HTML 表单都包含具有相同名称的属性/字段，那么让整个表单与数据对象同步。
大卫,
那就是我预期的用例，但在我看来，序列化表单是更好的方法。 你没有将状态放在两个地方，你也没有这个对象在周围闲逛。 然而，它的声明式本质更容易理解，并且代码更少（这就是人们喜欢绑定变量的原因）。
@Keith - 实际上，您可以直接传递一个函数作为转换器，其他几个人也提到了这一点。
@Dave Hulbert - unLink 当然 _应该_ 可用，但它在原型中没有实现。
当然，GitHub 的一大优点是它很社交，随意 fork 并加入您的想法，每个人都可以参与！
我觉得这很棒。除了表单之外，还可以考虑其他用途。比如，您有一个包含拖放和可调整大小元素的界面。您可以将它绑定到位置，并轻松地使用它来存储当前配置，并将该配置发送回服务器，以便在用户下次访问时保存它。
这样可以节省在保存时遍历 DOM 收集所有数据的过程，这是一个可能很长的过程。
对于包含多个字段的表单来说，这将是一个福音。条件字段之间的链接将变得更加清晰。
我喜欢它 - 我还没有下载代码，也许代码里有，但我希望第三个参数可以可选地接受一个函数，用于更复杂的绑定场景。例如
$(“#name”).linkTo(“val”, person, function() {
return person.firstName + ‘ ‘ + person.lastName;
});
我认为序列化与数据链接是一个不好的用例，因为无论如何序列化表单都是一个不错的选择。
但是，正如您所说，将会有两个来自同一个源的数据对象。因此，理论上，如果一切顺利，实际上只有一个数据状态，但有以不同格式/形式存在的多个访问点。
为了进一步说明表单示例（我希望我没有在构建另一个用例），想象一下在客户端验证表单。我们可以将表单输入数据链接到一个对象，而不是使用大量的 $(‘#id’)，$(‘.class’) 调用，并使用 validate() 函数来验证该对象。
简而言之：从一个数据源（因此只有一个数据状态），我们可以提取不同形式的多个数据对象（在这种情况下，是一个 JavaScript 对象），并根据上下文执行不同的操作。
我更愿意将表单输入数据链接到一个对象，然后验证该对象，而不是直接验证表单输入。
最终，我们试图做的是获取表单，验证它并提交它。获取表单、验证表单和提交表单的方式有很多种。可以是自然提交、AJAX 调用或任何其他方式。能够以不同的格式访问表单数据至少可以说是一种优势。
或者，您可以选择不使用数据链接 ;) 问题应该是
数据链接是否重要到足以包含在 jQuery 核心库中？我当然会这么说，因为我做的绝大多数 jQuery 工作都与数据绑定和验证有关！
从 Rey Bango 前几天在 Twitter 上宣布以来，这个提议一直困扰着我。我喜欢数据链接的想法，但我发现建议的语法不符合 jQuery 风格。该库的目的是尽可能地抽象掉复杂性，但方法签名迫使我考虑如何才能在之后更新数据以使其正常工作。
调用是否可以像下面这样（其中“obj”是 jQuery 对象，或者可能是对 DOM 元素属性的引用，而“var”是任何有效的、作用域内的变量引用）？
$.link(, [, ]);
我还没有尝试编写代码，所以不知道实现起来有多难，但这似乎更符合该库的精神，即简化开发人员需要链接的任何内容的链接。例如，为什么不能让我将文本输入链接到选择列表，或者将两个变量链接到彼此？
如果我错了，或者遗漏了什么明显的东西，请告诉我！
哦，让我再试一次方法签名
$.link( obj|var , obj|var [, pre-processor function ]);
我觉得 “linkTo” 这个名字对于一个具有三个参数的函数来说并不直观。
-> 因此我们可以更改参数数量、更改名称，或者两者都更改。
关键是找到最直观、简单、符合 jQuery 风格的方法。
我不知道 attr() 函数在这一点上能做什么，但这可能是一种很酷的方法。
$(“#name”).attr(“val”).linkTo(person.attr(“name”) [, pre-processor function]);
一定会尝试一下，这个想法本身很棒
怎么样一个 unLink（或 removeLink）方法？ 此外，getLinks 可能会很有用。
拜托，把微软从我们可爱的 $ 代码中赶出去吧！
众所周知，他们会毁掉一切美好的东西！
我相信很多很多开发人员会怀念 jQuery。
Web 开发人员几乎要花费 40% 的时间来调试和优化我们可爱的 IE。
在 IE9 的最新主题演讲中，他们听起来像是“他们”通过提供新的工具和设定 Web 开发的基调来了解开发人员。我们都知道，如果不是因为 IE，如今的 Web 会发展得更快！您怎么看？他们会有一天改变吗？
John，请重新考虑您与微软的合作关系！
我们试图解决什么问题？维护对存储在表单中的值的别名？在 JavaScript/jQuery 中引入指针类似物？
保留同一个状态的两个副本是一种糟糕的编程实践。在这个示例中，如果某些代码更新了 person.name 会发生什么？
如果它只是一个插件，那么只需发布它，让用户自己决定是否使用它，但它不应影响 jQuery 本身。
我对这个“数据”解决方案也很感兴趣。我认为它需要进行一些可用性测试。它看起来更像是分离的，而不是直观的。任何技术都需要一定程度的培训，但就像 @Magnus 所说，您试图解决什么问题？我喜欢 Flex/Actionscript 中的数据绑定。如果您想要的是数据绑定，那么这是您的目标。如果您想要的是数据存储，那么它看起来很分离。很容易看出您做了什么，但问题再次出现……这是数据绑定、数据存储还是其他什么？
众所周知，他们会毁掉一切美好的东西！
我相信很多很多开发人员会怀念 jQuery。
Web 开发人员几乎要花费 40% 的时间来调试和优化我们可爱的 IE。
@Adardesign: 嗯，我相信您也知道，如果没有 MS 和 IE，您就不会拥有 AJAX。
事实上，这场讨论让我想起了另一件 MS 除了 XmlHttp 对象之外还创建的东西。它是对 XML“数据岛”的客户端数据绑定。
基本上，您可以将客户端上的 XML 对象绑定到表单，当用户更新表单时，绑定到每个输入元素的 XML 字段也会更新。
我记得用它来验证 XML 而不是表单元素……
我发现自己经常编写不同类型的持久性代码，以至于不能忽视这样的功能，如果它不会导致性能问题，它可以节省时间。
这似乎是一个很棒的想法，而且真的很简单。迫不及待地想看到它进入 JQuery。
应该会减少编码工作量，并大幅缩短原型设计时间。
http://www.javerter.com
Dave 和 Tony
就像 Justin 一样，我不明白它如何简化表单验证等操作。
如果你缓存所有表单元素，正如你应该做的那样，那么你基本上已经拥有了这里所拥有的相同内容，除了你必须使用 .val() 来获取值，但你所做的比插件少得多。
它不仅必须绑定到每个表单元素才能工作，而且还需要收集表单的值才能保存它。这与我们遍历缓存元素对象并获取其值时所做的事情完全一样。
使用此插件进行表单验证会增加内存使用量，以及增加函数调用和创建的元素数量。
对某些人来说很好，但我不会说它对性能有益。
Adardesign，如果这是一个好主意，那么谁提出的并不重要。如果它的实现为开发者节省了时间，它就值得我们关注。这关乎实用性。并非 M$ 所做的一切都是错误的。此外，此提案在公开场合发布是为了征求开发者的反馈意见。
“微软”（实际上是其发言人）陈述了很多事情，开发者们对此感到有趣或生气，但没有人能指望微软通过简单地将他们排除在外来学习如何改进他们的方式。这难道不是我们自己的“垄断”例子吗？在开源世界中，任何人都可以提出功能。然后，开发者决定是否实现它。jQuery 开发者在这里寻求反馈。这公平得很。
我不明白它有什么用，事实上我认为尝试维护多个状态副本是一个糟糕的主意。它看起来像意大利面条，都被包在一个插件里。我宁愿它不被包含在核心代码中。除非有人能向我们提供一些此功能的实际应用，而替代方案更糟糕：使用和不使用此功能提供一个示例，以展示它如何有用。