Any self respecting MVC framework would have some sort of view manipulation. Almost all those sever centric frameworks have some sort of view manipulation. You create your views in your templating engine of choice (Velocity, Smarty, ERB, ASP, JSP or whatever). The views are processed by the server and the rendered result is sent to the browser. Some templating and view technologies go an extra step further an enable you to use cached copies of the compiled view templates.
Of particular interest where the SpringMVC and the RubyOnRails frameworks. Both provide means for view handling. And both provide hooks for custom view handlers. Which would lead to the interesting question.
What's wrong with the current view handlers?
All these handlers operate in the classical web application linked pages model (Web 1.0). With the eager move to Single Page Applications (Web 2.0) we need to add these abilities to current frameworks (or create new frameworks?)
How can we acheive this?
Instead of sending complete pages. The server should send to the client data only. And this data should only be view data with no control data. The view control data should reside completely on the client. So instead of responding to a list_items request with a rendered html page with the items required we will only send the data required. To be parsed and rendered by the client browser.
And data format?
Although it seems natural that we use XML for data sending. In a web browser environmnet it is more fit to use a more Javascript friendly approach. JSON (which is very XML like but in native Javascript) can be used as a data interchange medium. JSON will easily be parsed into live Javascript objects. Passed easily to templates (Javascript Templates from trimpath). And used to store model cache if needed (keeping the cache in the native Javascript format rather than XML is crucial for performance).
Template Engine?
As mentioned above. The Javascript Template from www.trimpath.com act as a very good alternative to its server side cousins. It has Smarty, Velocity like syntax. And it is very extinsible. The only draw back is that it is lacking an include mechanism (though this is partially solved by using its Macros)
And the result?
Adding web 2.0 application capabilities to the current tried and true web application frameworks. Making it easy to move even current apps to the user friendly era of web 2.0. I will be working soon in the Spring to JStemplates interfaces and I might delve into a RoR implementation as well (this would be very easy I believe, might envolve overriding a method or two in the action controller). The only thing that is missing is standardizing the client side controller code.
Of particular interest where the SpringMVC and the RubyOnRails frameworks. Both provide means for view handling. And both provide hooks for custom view handlers. Which would lead to the interesting question.
What's wrong with the current view handlers?
All these handlers operate in the classical web application linked pages model (Web 1.0). With the eager move to Single Page Applications (Web 2.0) we need to add these abilities to current frameworks (or create new frameworks?)
How can we acheive this?
Instead of sending complete pages. The server should send to the client data only. And this data should only be view data with no control data. The view control data should reside completely on the client. So instead of responding to a list_items request with a rendered html page with the items required we will only send the data required. To be parsed and rendered by the client browser.
And data format?
Although it seems natural that we use XML for data sending. In a web browser environmnet it is more fit to use a more Javascript friendly approach. JSON (which is very XML like but in native Javascript) can be used as a data interchange medium. JSON will easily be parsed into live Javascript objects. Passed easily to templates (Javascript Templates from trimpath). And used to store model cache if needed (keeping the cache in the native Javascript format rather than XML is crucial for performance).
Template Engine?
As mentioned above. The Javascript Template from www.trimpath.com act as a very good alternative to its server side cousins. It has Smarty, Velocity like syntax. And it is very extinsible. The only draw back is that it is lacking an include mechanism (though this is partially solved by using its Macros)
And the result?
Adding web 2.0 application capabilities to the current tried and true web application frameworks. Making it easy to move even current apps to the user friendly era of web 2.0. I will be working soon in the Spring to JStemplates interfaces and I might delve into a RoR implementation as well (this would be very easy I believe, might envolve overriding a method or two in the action controller). The only thing that is missing is standardizing the client side controller code.
Comments (0)
Post a Comment