Last post Jul 24, 2012 09:50 AM by francesco abbruzzese
Jun 21, 2012 06:58 AM|Perpetuumsoft|LINK
Jun 21, 2012 07:22 AM|christiandev|LINK
I will check this out..I used the Perpetuum silverlight reports viewer in the past with good success...
Jun 21, 2012 08:41 AM|francesco abbruzzese|LINK
If you use Client Blocks in the Mvc Controls Toolkit knockout bindings are created automatically when you use the normal Html.TextBox..with no need of specific syntax. This way one can use the same View with a knockout or not knockout page...bindings are
strongly typed....one can specify formats with the usual data annotations, validation rules with the usual validation attributres...in other terms EVERYTHING IS DONE as in a normal Mvc application...and ko bindings are created automatically with the right
Jun 22, 2012 08:49 PM|atmonline|LINK
Thanks. I will check out.
Jul 13, 2012 01:57 AM|tyrsius|LINK
Man, I was really excited when I first saw this, but I am horrified after looking at it. executeOnServer? Talking to the server for every function call? Sending the entire viewModel for every function call, in both directions?
of any application using this method.
I can't stress enough how bad of an idea I think this is.
Jul 13, 2012 02:14 AM|Maeleki|LINK
Which of the two solutions used executeOnServer?
Jul 13, 2012 03:18 AM|francesco abbruzzese|LINK
What are you speaking about? Which framework include the executeOnServer function? For sure none of the framework spoken about in this page...please put a link on the documentation you are referring to.
Jul 21, 2012 07:44 PM|prunkster|LINK
For example, in the 'Gift list' example (http://knockoutmvc.com/GiftList), when adding a gift, the entire view model is submitted to your controller (via executeOnServer), the new gift is added
to the model, and finally the serialized json model is sent back to the ui... Same way for the other examples.
I don't want to disrespect your hard work, the idea is pretty good! But i think the current implementation is rather useless when you always have to call your controller in order execute something on your observable(Array), for example to add a new item
or something, as this is knocking out one of the greatest features of knockoutjs (imho).
I wonder whether Script# (http://projects.nikhilk.net/ScriptSharp/) could be used in order to, for example, just add the new item to the observableArray without posting the entire viewmodel
to the controller?
Jul 22, 2012 06:51 AM|francesco abbruzzese|LINK
I agree. There is no need to send the whole viewmodel to perform an action on just one element. A better approach might be associating to each button a couple of actions: one to be performed on the client and the other to be performed on the server. So for
instance in the case of delete, the client action might consist in deleting the element from the client model, and the server action in calling a delete action that perform the actual delete on the server. Obviously the client ation should be performed only
if the server action is successfull.
In other terms sync between server and client can be done more efficiently thansending the whole model. That said, I don't think this is a problem of the framework but just of the way the example is implemented. In fact the execute on server might be passed
simply the id of the element to delete, and the click handler might handle smartly both the client and server actions....Maybe the only thing to change are the way the ko button are implemented, giving them moe customization possibilities.
Anywat Script#...is not a solution...the problem is not translating one language into another but splitting the job between server and client.
Jul 24, 2012 02:08 AM|tyrsius|LINK
Talking to the server just to execute simple functions, or any functions that could be handled client side, is a waste of a request and a response. It's going to be affected by network latency, its going to burden your server with calculations, and its going
to create an experience for the user that is in every way inferior to one that was pure client-side knockout.
functions. It is the framework. The framework is bad. It cripples the very benefits Knockout seeks to create.
It is ill-conceived.
Jul 24, 2012 09:50 AM|francesco abbruzzese|LINK
@tyrsius. I have not seen all examples, but the ko helpers makes sense since they avoid errors in writing names, and sicne they are not based on strings, the code can be easily reenginered
if some name is changed.
For sure sending to the server jobs that do not involve synchronization with the server is a design error.
However, the way to handle synchronization with the server is a complex stuff. The more effficient way is just to send the change set to the server, but this is not always possible. More specifically it is possible just if the whole controllers stuff has
been organized just to receive change sets...but in complex systems often this design patter may introduce too many dependencies between layers. In particular modifying a previously designed controller to receive just a change set breaks separation of concern
between Views and controller, because the controller design is affected by the use of knockout in the implementation of the View...sometime this dependency is acceptable...but other times the modification of the controller may cause also changes in other layers
causing a kind of avalanche effect.
In my knockout based framework (ClientBlocks) I allow both approches: either the use of change sets through the
the use of knockout in a part of a view completely transparent for the reminder of the system: the action method receives an overall ViewModel containing both information coming from normal input fileds and and the information contained in the client side
viewmodel. This enhance modularity and allows the implemntation of controls based on knockout...without forcing the use of knockout for the whole view.
That said for sure sending the whole Client ViewModel to the server doesnt make sense when processing just 1 item, but only in the case of batch processing, when the user performs, items updates, items additions, and deletes....and then send the
Client Viewmodel after ALL MODIFICATIONS, not after each single user operation.