In the second example, you are referring to a function that has to be in the global scope (i.e. a property of the window object).
In the first example, you are referring to a property of the current view model.
Yes, it's a subtle distinction, but it is an important one. If you use on-event attributes you can only refer to things that exist in the global scope. This means you have to put everything you want to access in the global scope, which leads to very messy code.
If you use declarative bindings, the exact meaning of the bindings instead depends on the context.
It helps to think about the HTML markup as more coincidental. What you are really looking at is structured access to the view model. Think of with and forEach as nested contexts and of the other bindings as their attributes. The relationship between the declarative bindings and the underlying HTML suddenly feels more like working with XSLT.
The two examples look very similar. But the underlying concepts are vastly different and are what makes data binding so powerful and on-event attributes so obnoxious.
The reason on-event attributes are frowned upon isn't just that they mix logic with structure. It's that they're a weak attempt to bolt arbitrary JavaScript code to HTML elements which prevents proper encapsulation of application logic. On-event attributes are low-level "hooks", bindings extend the behaviour of elements.
All that said, it is likely possible to do the same horrible things people have done with on-event attributes by using declarative bindings. The difference is in what else you can do with them. You shouldn't always judge technologies by how they can be abused -- we're all adults here.
Your only using one part of MVVM - specifically the View - in that code example you gave above. The reason to use Knockout (or any other MVVM library) is to make it easy to bind your views to a Model - a View Model - thus allowing you stop writing a lot of boilerplate code just to return values from your view.
I see a lot of wonky javascript/jquery code where people go and use something like this:
var ex = {
some1: $('#textbox1').val(),
some2: $('#textbox2').val()
};
The problem with this is that it is literally littered throughout the web application and it becomes extremely tedious to maintain. I know with Knockout, whenever my View is updated, my View Model will be updated as well.
It's not needed for every application, and you shouldn't use it just because it's whats "cool" to use. There obviously needs to be a reason to use it, my example above is one reason and im sure there are more.
发布评论
评论（2）
这是对您的问题的更直接的回答。
在第二个示例中，您引用的函数必须位于全局范围内（即
window对象的属性）。在第一个示例中，您引用当前视图模型的属性。
是的，这是一个微妙的区别，但它是一个重要的区别。如果您使用事件属性，则只能引用全局范围内存在的事物。这意味着您必须将想要访问的所有内容都放在全局范围内，这会导致代码非常混乱。
如果您使用声明性绑定，则绑定的确切含义取决于上下文。
将 HTML 标记视为更巧合会有所帮助。您真正关注的是对视图模型的结构化访问。将
with和forEach视为嵌套上下文，并将其他绑定视为它们的属性。声明性绑定和底层 HTML 之间的关系突然感觉更像是使用 XSLT。这两个示例看起来非常相似。但底层概念却截然不同，这也是数据绑定如此强大而事件属性如此令人讨厌的原因。
事件属性不受欢迎的原因不仅仅是它们将逻辑与结构混合在一起。它们是将任意 JavaScript 代码固定到 HTML 元素的尝试很薄弱，从而阻碍了应用程序逻辑的正确封装。事件属性是低级“钩子”，绑定扩展了元素的行为。
尽管如此，通过使用声明性绑定，很可能会做出人们对事件属性所做的同样可怕的事情。区别在于您还可以用它们做什么。你不应该总是根据技术如何被滥用来判断技术——我们都是成年人。
Here's a more direct answer to your question.
In the second example, you are referring to a function that has to be in the global scope (i.e. a property of the
windowobject).In the first example, you are referring to a property of the current view model.
Yes, it's a subtle distinction, but it is an important one. If you use on-event attributes you can only refer to things that exist in the global scope. This means you have to put everything you want to access in the global scope, which leads to very messy code.
If you use declarative bindings, the exact meaning of the bindings instead depends on the context.
It helps to think about the HTML markup as more coincidental. What you are really looking at is structured access to the view model. Think of
withandforEachas nested contexts and of the other bindings as their attributes. The relationship between the declarative bindings and the underlying HTML suddenly feels more like working with XSLT.The two examples look very similar. But the underlying concepts are vastly different and are what makes data binding so powerful and on-event attributes so obnoxious.
The reason on-event attributes are frowned upon isn't just that they mix logic with structure. It's that they're a weak attempt to bolt arbitrary JavaScript code to HTML elements which prevents proper encapsulation of application logic. On-event attributes are low-level "hooks", bindings extend the behaviour of elements.
All that said, it is likely possible to do the same horrible things people have done with on-event attributes by using declarative bindings. The difference is in what else you can do with them. You shouldn't always judge technologies by how they can be abused -- we're all adults here.
在上面给出的代码示例中，您只使用了 MVVM 的一部分 - 特别是视图。使用 Knockout（或任何其他 MVVM 库）的原因是为了让您可以轻松地将视图绑定到模型（视图模型），从而允许您不再编写大量样板代码只是为了从视图返回值。
我看到很多奇怪的 javascript/jquery 代码，人们在其中使用类似这样的代码：
问题在于，它实际上散布在整个 Web 应用程序中，并且维护起来变得极其乏味。我知道使用 Knockout，每当我的视图更新时，我的视图模型也会更新。
并不是每个应用程序都需要它，并且您不应该仅仅因为它使用起来“很酷”而使用它。显然需要有一个使用它的理由，我上面的例子就是一个原因，我确信还有更多原因。
Your only using one part of MVVM - specifically the View - in that code example you gave above. The reason to use Knockout (or any other MVVM library) is to make it easy to bind your views to a Model - a View Model - thus allowing you stop writing a lot of boilerplate code just to return values from your view.
I see a lot of wonky javascript/jquery code where people go and use something like this:
The problem with this is that it is literally littered throughout the web application and it becomes extremely tedious to maintain. I know with Knockout, whenever my View is updated, my View Model will be updated as well.
It's not needed for every application, and you shouldn't use it just because it's whats "cool" to use. There obviously needs to be a reason to use it, my example above is one reason and im sure there are more.