Exactly why I advocate PVC for anything beyond aping a web app. I wouldn't say there's _no_ reason to ape a web interface, but I hope I pointed out the drawbacks. I think we're in violent agreement. FWIW, I think you'll see backbone integration with Roweis, but it'll be easy to transition from (¬M)VC to PVC. We're deliberately trying to make Roweis easy to migrate, so having written the above, you ought to be able to switch to a proxy with ease.
Now for your points. You say that making two HTTP requests is less than ideal. Well, that's exactly the point of decoupling the RESTful server and the application. If you control both, of course you can create a single RESTful call that delivers both sets of data. In which case both PVC and (¬M)VC can make one request instead of two.
Caching is as an example of the strength of PVC. I'd also add things like long polling. Let's say we poll for updates to an institution. A change to its name ought to be reflected in a list of institutions along with any page or pages showing the details of the institution, plus any other entity that refers to the institution by name.
A model or proxy for a model resource can handle long polling and all of the appropriate views can listen to it for changes so they can update themselves accordingly. (¬M)VC cannot handle that case at all.
Violent agreement, indeed. Can you talk a little about the nature of the application that you're extracting Roweis from? Is there something about it that makes it especially well suited to the (¬M)VC style?
This is a client project, and the client has professed a strong desire to build additional applications working with the domain data, and possibly even to migrate the UI portion of whatever we build to a different web application platform that plays nicely with their existing management tool chain.
This suggested building a simple RESTful domain logic server that will support the development of independent applications, and a separate application server that can be deprecated if need be. The client's IT team are comfortable with Javascript, so we decided to build the application side in Javascript. One choice was node.js, another was to push the UI down into the browser.
As it happens, there is no requirement for more UX than a web application would deliver, so we are essentially delivering the "application server" inside the browser. We can obviously do a lot in the browser that can't be done with an application server, but we want to be 100% sure that they can port the application interface to a web platform if they wish.
Thus, the cargo cult mentality of making a JS app that works just like a web app. We're building it specifically to be understood by a programmer with web development experience.
Our genuine hope is that making it easy to port back to an application server will also make it easy for the client to extend and modify just the way it is. If integration with something like backbone is easy, they might just find themselves adding the kind of functionality you espouse on their own.
Comments
Exactly why I advocate PVC for anything beyond aping a web app. I wouldn't say there's _no_ reason to ape a web interface, but I hope I pointed out the drawbacks. I think we're in violent agreement. FWIW, I think you'll see backbone integration with Roweis, but it'll be easy to transition from (¬M)VC to PVC. We're deliberately trying to make Roweis easy to migrate, so having written the above, you ought to be able to switch to a proxy with ease.
Now for your points. You say that making two HTTP requests is less than ideal. Well, that's exactly the point of decoupling the RESTful server and the application. If you control both, of course you can create a single RESTful call that delivers both sets of data. In which case both PVC and (¬M)VC can make one request instead of two.
Caching is as an example of the strength of PVC. I'd also add things like long polling. Let's say we poll for updates to an institution. A change to its name ought to be reflected in a list of institutions along with any page or pages showing the details of the institution, plus any other entity that refers to the institution by name.
A model or proxy for a model resource can handle long polling and all of the appropriate views can listen to it for changes so they can update themselves accordingly. (¬M)VC cannot handle that case at all.
Violent agreement, indeed. Can you talk a little about the nature of the application that you're extracting Roweis from? Is there something about it that makes it especially well suited to the (¬M)VC style?
This is a client project, and the client has professed a strong desire to build additional applications working with the domain data, and possibly even to migrate the UI portion of whatever we build to a different web application platform that plays nicely with their existing management tool chain.
This suggested building a simple RESTful domain logic server that will support the development of independent applications, and a separate application server that can be deprecated if need be. The client's IT team are comfortable with Javascript, so we decided to build the application side in Javascript. One choice was node.js, another was to push the UI down into the browser.
As it happens, there is no requirement for more UX than a web application would deliver, so we are essentially delivering the "application server" inside the browser. We can obviously do a lot in the browser that can't be done with an application server, but we want to be 100% sure that they can port the application interface to a web platform if they wish.
Thus, the cargo cult mentality of making a JS app that works just like a web app. We're building it specifically to be understood by a programmer with web development experience.
Our genuine hope is that making it easy to port back to an application server will also make it easy for the client to extend and modify just the way it is. If integration with something like backbone is easy, they might just find themselves adding the kind of functionality you espouse on their own.