145

SoulBlend –A JSON Template Engine For a smooth search experience on any browser and to generate HTML from the output of different Web APIs Sandeep Ghosh, Sreedipto Bhattacharyya, Kaustav Surai, Lopa Mandal Department of Information Technology Institute of Engineering & Management Kolkata, India [email protected], [email protected], [email protected], [email protected] Abstract—In this tech savvy world when people just cannot a fford to wait eons for their search results and queries answered on their display screens, the present work aims to propose an architecture of a JSON (JavaScript Object Notation) based template engine with increased efficiency, consideration to speed at which things are delivered and also the ease of the interface. SoulBlend, the proposed template engine follows the idea of complete separation of presentation (HTML) and business logic (JavaScript) and is simple, lightweight and versatile. It has been implemented in JavaScript and can run on all the latest browsers. It is compatible with all the latest and popular JavaScript libraries (i.e. jQuery, Mootools, Dojo etc.) so that developers specialized in different JavaScript libraries can use this template engine extensively. The overall footprint is so less that it can be loaded with ease on computers that have slower or flaky internet connection, it is usable dynamically with AJAX (Asynchronous JavaScript and XML) XHR (XMLHttpRequest) so that developers can use this template engine to generate HTML from output of different Web API (i.e. Google AJAX API, Flickr API, Bing API etc.) which nowadays provides JSON as a primary output of their API methods. Furthermore it has been made browser independent and can run in all the latest browsers including recent mobile browsers like Opera Mini.

Programmers and designers love to code independently and separation of logic and display has become an ideal principle. However it is often not the case in practice because of the fear of loss of power. And we often end up entangling the logic and display. II.

EMERGENCE OF TEMPLATE ENGINES

Rendition of a dynamic webpage involves not the mapping of a URL to an HTML file on disk, but the mapping of the URL to a block of code which generates the apt HTML code. The description that follows is about the evolution of Java engines in particular, though all the concepts apply to Perl, Visual Basic, and others. Java began supporting server development with Servlets, which amounted to methods that respond to HTTP GET and POST commands by generating HTML via print statements. For example, here is the core of a simple servlet that generates a page saying “hello” to the URL parameter called name. out.println("");

Keywords- JSON, Template engine, Web APIs, HTML Generation, JavaScript, XML

I.

INTRODUCTION

With the advent of highly interactive sites such as eBay, naukri.com, Amazon.com among others, the need for dynamically generated web pages have assumed great proportions. For example, the job description pages at naukri.com, YouTube search results for a particular music video among others has led to the development of numerous template engines in an attempt to make web application development easier, improve flexibility, reduce maintenance costs, and allow parallel code and HTML development. “These enticing benefits, which have driven the proliferation of template engines, derive entirely from a single principle: separating the specification of a page’s business logic and data computations from the specification of how a page displays such information. With separate encapsulated specifications, template engines promote component reuse, pluggable site looks, single-points-of-change for common components, and high overall system clarity,” writes Terence Parr, University Of San Francisco(2004)[1].

out.println(""); out.println("

Hello Servlet Test

"); String name = request.getParameter("name"); out.println("Hello, "+name+"."); out.println(""); out.println(""); However we find that specifying HTML in Java code is tedious, error-prone, and cannot be written by a graphics designer. To improve the situation, programmers can try to factor out common HTML output elements into Java rendering objects like Table and Bullet List, but they are still embedding HTML all through their servlets. The next stage of evolution was the introduction of Java Server Pages (JSP), which at first glance seemed to be a big step forward. But logically speaking JSP files are just inside-out servlets, HTML files with embedded Java code. JSP files are automatically translated to servlets by the server. The same “hello” page looks like the following in JSP:

IEM International Journal of Management & Technology

January 2011, Vol. 1, No. 1

146

Hello JSP test

Hello, .

always helps us with easy maintenance. Also strictly isolating the model from the view and disallowing control structures, enhances security. Programmers often view strict separation as costing more time and hassle. While this may be true in the small, such as adding a new piece of data to a view, but projects progress much faster in the long run and result in much more flexible, robust code specifically because of the significant benefits listed in this section. III.

JSP files may start out as HTML files with simple references to data, as in this example, but they quickly degenerate into fully entangled code and HTML specifications like Servlets. In practice, graphics designers also cannot modify JSP files. Most importantly JSP encourages bad object-oriented design. For example, an include file is a poor substitute for class inheritance. JSP pages may not be subclassed, which makes it hard for programmers to factor out common code and HTML. While JSP was not the answer, it did put the idea of a template into programmers’ minds. A template is an HTML document with “holes” in it that can be filled with data or the results of simple actions. Unfortunately, just about every template engine repeats the mistakes of JSP; they provide a toolspecific programming language embedded in HTML. As with JSP, then, designers are forced to imagine the emergent behavior of a program rather than looking at a page exemplar. While template engines have fixed some of the annoying issues with JSP, most fail to address the primary reason why JSP is a disaster for large systems. A template should merely represent a view of a data set and be totally divorced from the underlying data computations whose results it will display. If the template language is too powerful, template designers risk entangling template and business logic [1]. The primary goal behind using a template engine is to separate logic and data computations from the display of such data in both thought and mechanism. In the case of web site development, this means roughly that there should be no code in HTML and no HTML in code. The look and feel or the interface of a site is fully contained within templates and, likewise, the business logic is located entirely in the data model. Each specification is a completely independent entity. It gives a lot of freedom to a web designer who can now build the site templates in parallel with the coders’ development efforts. This reduces the load on programmers not only by having a (usually less expensive) designer building the templates, but by reducing communication costs; designers can do anything with the HTML without disturbing a programmer. Just as programmers break large methods down into smaller methods for clarity and reusability, designers too can break up their templates into smaller modules. Entangled templates tend to be difficult to factor and cannot be reused with other data sources. Errors are also reduced because to change a single behavior, we do not have to change in multiple places.. Having a single place to change a single behavior in the model is also important. Logic in the template is avoided. As code changes require recompilations and template changes do not, separating the two

EXISTING APPROACHES

Model-View-Controller Pattern The MVC pattern is the most important aspect on which most of the template engines are based. Model–View–Contr oller (MVC) is a software architecture [2], currently considered an architectural pattern used in software engineering. The pattern isolates "domain logic" (the application logic for the user) from the user interface (input and presentation), permitting independent development, testing and maintenance of each (separation of concerns). The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react. Refer Figure 1. The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A viewport typically has a one to one correspondence with a display surface and knows how to render to it. The controller receives input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and viewport to perform actions based on that input.

Figure 1. Model-View-Controller concept. The solid line represents a direct association, the dashed an indirect association (via an observer for example).

Architectural benefits:  

The presentation logic and the business logic remain totally separated. Enhances productivity by reducing unnecessary reproduction of effort. 

IEM International Journal of Management & Technology

January 2011, Vol. 1, No. 1

147



Enhances teamwork by allowing separation of work based on skill-set (e.g., artistic vs. technical) 

There are some template engine mainly based on XML; Some of these are only libraries for specific programming languages, but some form the basis for command line or shell script utilities for one or more operating systems. Such utilities are either bundled with the libraries or independently maintained, and some are incorporated into other applications, such as database engines and web browsers. Example: XalanJava [3], Saxon [4], Gregor/XSLT [5] which are mainly based on XML and implemented in JAVA, XQSharp [6] is a XML Template Engine based on .NET. But now a days as asynchronous page update is becoming very popular and web developers wants to reduce load on the server and put the processing on the client machine as much as possible, JavaScript is getting very popular and widely used as JavaScript is the only client side scripting language which is supported by almost all the latest browsers and also been standardized by W3C (Current Version ECMAScript 1.4). So demand for template engine based on JavaScript is becoming high, there are only a few like Younicycle, nTPL[7] are there but they are still in developmental process. IV.

MOTIVATION

In this tech savvy world when people just cannot afford to wait eons for their search results and queries answered on their display screens, we have to not only increase efficiency by using the MVC architecture but also look at the speed at which things are delivered and also the ease of the interface [8,9,10]. Falk Hartmann in his 2006 IEEE paper produced a wonderful architecture of an XML based Template Engine [8]. However with the emergence of JSON (JavaScript Object Notation), human readable data interchange have revolutionized and template engine based on XML is giving way to its competitor JSON. Moreover if we can use an efficient technology to implement the interface and an equally lightweight text-based open standard designed for human-readable data interchange then it will be an icing on the cake. Here our aim is to achieve ease and efficiency together with a vision of how the mindset of the people inhabiting a futuristic information highway would be like viz. “the impatience and hunger for informatio n will be the new life”. V. PROPOSED SOLUTION In the present work a simple, lightweight and versatile JSON (JavaScript Object Notation) based template engine has been proposed to be implemented in JavaScript which is expected to run on all the latest browsers. The proposed template engine follows the Model View Controller architecture completely so that representation (HTML) and Logic (JavaScript) remain totally separated. It has been made compatible with all the latest and popular JavaScript libraries (i.e. jQuery, Mootools, Dojo etc.) so that developers specialized in different JavaScript libraries can use this template engine extensively. The overall footprint is so less that it can be loaded with ease on computers that have slower or

flaky internet connection, it can be used dynamically with AJAX (Asynchronous JavaScript and XML) XHR (XMLHttpRequest) so that developers can use this template engine to generate HTML from output of different Web API (i.e. Google AJAX API, Flickr API, Bing API etc.) which nowadays provides JSON as a primary output of their API methods. To manipulate the HTML it uses DOM (Document Object Model) and standardized DOM Scripting rather than DHTML which may be browser specific, so that it can be browser independent and run in all the latest browsers including recent mobile browsers like Opera Mini. Above all, our proposed template engine aims to, which all the template engine developers try to implement, that, be blazing fast for smooth user experience. A. Why use JSON and Not XML? Douglas Crockford was the first to specify and popularize the JSON format (2003). JSON is language independent and used for representing simple data structures and associative arrays, called objects. The JSON format is often used for serializing and transmitting structured data over a network connection. It is primarily used to transmit data between a server and web application, serving as an alternative to XML. When data is encoded in XML, the result is typically larger in size than an equivalent encoding in JSON, mainly because of XML's closing tags. So XML consumes more bandwidth than JSON during transmission. Beyond size, XML lacks an explicit mechanism for representing large binary data types such as image data. JSON can represent them using arrays of numbers (representing bytes, or larger integer units up to the precision of 52 bits including the sign bit), because it can exactly represent IEEE-754 64-bit doubles (as specified in the ECMAScript standard). The difference between XML based implementation and JSON based implementation is shown below with an example: In XML: