How do js mvc libraries like spine, trunk, jsmvc integrate into server-based MVC infrastructure like lithium or zend?

Question

My specific question is that I need links to links, so that I can study / research the name of the question, and not raise arguments about features, but which ones are better. I found jsMVC , spine and EJS , but I don’t know what place they store in the MVC template. Don't they just see themselves as they handle rendering? So does this mean that the MVC client looks like an additional template from the V MVC server? Links are useful that provide information and theory on how these client-side libraries work inside / with a traditional server-side structure.

Thanks!

As I wrote this, I am reading this answer , and this type of answer helps, more like link links. It would be great.

Answer 1

The client side of MVC can handle the entire MVC stack. If you use MVC on the server and on the client side, then duplicate your models and routes.

The client side of MVC basically allows you to combine your server and client. Why should the server send submissions? Why not send the json model and load it into the client-side model, and the client will display this view.

You can go further with routing. Why is the router being processed by the server? Customer can do this. Just let the client access your RESTful database and you don't need any server-side MVC.

Of course, if you want to support non-javascript, you need server-side MVC.

Personally, I use setup with a heavy client / heavy server. I use the whole server mvc to load the first page. From now on, the client update itself uses only client MVC if it can with javascript. If he cannot, he will continue to use serveride MVC.

This type of development is greatly simplified thanks to SSJS, so your models, collections and views are a common code base and are only supported in one place.

Answer 2

Using the MVC client environment can be useful for organizing code when working with very large Ajax-dependent applications. Consider a client-side model layer that consistently talks about one or more services provided by individual applications in a service-oriented architecture. Individual service providers can implement their services using MVC or not, but there is an advantage in that client models will consume this data.

Keep in mind that the Javascript frameworks - be it jQuery, Mootools, Node.js - are going to implement an event-driven management process where one event can trigger callbacks that are cascaded into other callbacks. Typically, on the server side, at least where the HTTP request-response loop is executed, we want to create discrete, atomic tasks that generate a quick and responsive response and can trigger or trigger another asynchronous event on the server, since the response blocks the user from execution another request and continue its workflow. Not so for client side Javascript.

Adding full client MVC to the stack when you are already using the MVC server platform can be overwhelming and can lead to duplication of effort. This can be done correctly. Specialize your server code for access control and CRUD operations by returning JSON instead of HTML representations. Specialize your client code for event processing and processing using lightweight models that expect JSON data to be stored with regular ReST-ful routing. Use them for what they are both good to get maximum mileage.