Last post May 05, 2012 07:43 PM by francesco abbruzzese
May 05, 2012 03:57 PM|vladnech|LINK
May 05, 2012 04:03 PM|BrockAllen|LINK
you're writing lots of change event handlers to know when the input elements are updated. Imagine then that you have read only parts of the page that need to be updated when the input elements have changed. Writing all of the code to update the UI, handle
change events, and then know if input element A changed that you then have to keep element B in sync... that's all quite a bit of messy code. KO helps manage this by using the MVVM abstraction model -- with observables and their framework for binding the VM
to the UI.
May 05, 2012 07:43 PM|francesco abbruzzese|LINK
The thing you might "hate" is that ko move some "logics" into the html page....so it might appear it breaks the separation of concerns between graphics and logics....Actually separation of concerns is not broken...but the boundary is moved to the client,so
the same Html page is broken in two parts ...logics and graphics. However graphics is separated from logics in ko, and the link between them is done through the ko bindings.
Give a look to Mvc Controls Toolkit
client blocks. They compute automatically ko bindings, so you don't need to put any code in the html page...all code can be put into js files, and bindings...are just computed automatically based on the same name convention used by MVC...maximum of separation.
You need just to apply some click binding ro handle buttons and some ccs and style bindings if you hneed to change the appearence of Html nodes according to the values of data.