Static front end vs data back end

First, let me describe the web of our generation.

This is a HTML5 era, this is a JavaScript independently era, this is a front-end and the back end of the rival era.

Speaking of JavaScript in the front, a lot of people will immediately say, Mvvm,angular,backbone,avalon,react, ...

Yes, these are good JavaScript frameworks that can be independently to make good work. But imagine this scenario: development is a division of labor, the Web interface prototype is provided by the artist, we programmers to static pages to add dynamic content to synthesize the final web content. The surface seems normal, but it is the beginning of an endless egg ache. When we finish a version, the requirements change, add a banner, add a bullet box and so on. Art in the original version of the changes, we follow up the changes, it is quite painful to understand what the artist changed, how each tag,css,js affect page elements and behavior. If I understand, art can worry about ...

Here is a solution to this scenario. The static front end is the artist's responsibility, and the data driven by the programmer. Each page by the programmer only write very little JS to apply the data to the page, you can easily switch back to the original for the artist and then modify. The back-end program only provides JSON-formatted data, same-Origin Ajax, cross-domain use of JSONP, and the page to update the corresponding content after receiving the data. When deployed, static pages are placed in Apache, and dynamic programs are placed in Tomcat or WebLogic, which also balances the load and reduces the pressure on the application server.

That's a good idea, but if you want to play a few rounds, the following one by one discussions:

1. Initializing data

Imagine a product.html?id=123 request sent to Apache, and the static product.html was returned to the browser. When rendering this HTML, a product.do request is automatically sent to Tomcat to get the data. At this time how to know id=123, see request header in the Referer can, of course, to analyze and extract. If you want to keep the waiting time as small as possible, you can take the data while rendering the HTML, and then do a synchronous process back. For example:

2. Internationalization i18n
The message is divided into two categories, the exception displays the information, such practices and the same as the previous use of the server program processing. The normal display of information (for example, label) is done with JS. Write a JS file, such as I18n.js
var i18n = {en: {title: "title", Name: "Name",...}, zh: {title: "title", Name: ",...}}
Write a function that loads i18n
function loadi18n (locale) {var msgs = I18n[locale];  $ (' #title '). Text (msgs.title); $ (' #name '). Text (msgs.name);}
Switch locale, do not need to request data, but need to tell the server, the current language
function Switchlocale () {locale = locale = = ' en '?  ' zh ': ' en ';  $.post (' locale.do ', {locale:locale}); loadi18n (locale);}

3. Page nesting
Before using JSP or Freemaker, with include,import and so very convenient. How is this happening now? There are two ways of
Method One: Jquery.load ()
After the initialization data is loaded, the locale is obtained and then $ (' #target '). Load (' target_ ' +locale+ '. html ')
Method Two: CSS
Method one has to go through two requests and sometimes it feels slow. If you want to hurry up, you can write two versions of both Chinese and English on the first HTML, set style= "Display:none", and use $ (' #target_ ' +locale) after loading the initialized data. Show () shows it.

4. Form submission
The form data must be committed asynchronously, and the server program returns a success flag or error message. If the error message is displayed in the corresponding location, if it is a success flag, use JS to jump to the next page.



This article is from the "Creative Light Front" blog, please be sure to keep this source http://wikiou.blog.51cto.com/11905043/1885796
Static front end vs data back end