Automatically generate HTML and javascript from server side code

Automatically generate HTML and Javascript from server-side code. You write code in a standard server-side language like Java, or a custom language like that used in Backbase, and it's converted to HTML and Javascript. Depending on the framework, you might not need to code directly in HTML or Javascript at all. Since you're unlikely to create such a framework yourself, this pattern relies on a certain category of publicly availably Ajax Framework.

In the case of all code being autogenerated, the code is something like a conventional desktop application. Widgets and event-handler are defined, and the browser generates the appropriate HTML, along with XMLHttpRequest Calls and general Javascript handling. As well, the framework will often generate Ajax Stubs to deal with incoming calls and pass them to appropriate application code.

In other frameworks, the approach is more mixed. The framework might let you create a Slider with just a single tag, for example. But in the tag, you'll specify a Javascript function to be called whenever the slider value changes.

There are several arguments for Server-Side Code Generation:

• Developers don't have to know HTML and Javascript. One nasty thing about the web paradigm is that developers usually have to learn HTML, CSS, and Javascript on top of any server-side languages. Along with the raw language, each of these languages has its own conventions, patterns, and libraries to get familiar with. It's not surprising that few people master both sides. Server-Side Code Generation allows developers to focus their attention only on the server-side language.
• The framework can, in theory, handle graceful degradation transparently. In other words, it can free the developer of worrying about browser portability, Javascript or cookies being turned off, or XMLHttpRequest Calls timing out.
• The framework can, in theory, deliver multiple platforms simultaneously. A single code base can be used to generate a web application (Ajaxian or not), standalone desktop application, and maybe even a mobile application.

However, code generation does comes at a cost to usability. Look at it this way: anything you could generate from the server, a skilled developer could also hand-code. The reverse is not true; given enough time and talent, it's always possible to build a custom solution that's superior in terms of usability. So, to be worthwhile, the framework must add enough value in terms of productivity and support for non-experts, to compensate for the drop in usability. Whether this can be achieved really depends on two things: how much users will gain from a custom-built application; and how much of a boost the framework will give you. On the second point, consider a few counter-arguments to the benefits above:

• The first point, about developer's not having to learn HTML and Javascript, has traditionally been the most compelling. Server-side developers have produced minimal satisficing, rather than optimal, interfaces, allowing them to focus on the server side. It's not uncommon to see advice against anything relatively complex being performed on the server-side. But as Ajax becomes more prominent, this argument becomes less compelling. As discussed in Fat Client, Javascript is undergoing a renaissance - developers will learn about it, tools and libraries will evolve, patterns will emerge. All of this reduces the argument for isolating developers from HTML and Javascript.
• A server-side framework may well be able to handle graceful degradation and browser versions transparently. But to the extent that's possible, a browser script can also achieve the same effect, as discussed in Cross-Browser Component.
• The dream of transforming a single code into a variety of different user-interface styles has been around for a while. Certainly, many modern UI toolkits are cross-platform, running on different operating systems from the same code base. However, can a single code base lead to both a web application and a desktop application? It's possible in theory and in proof-of-concept demos. But, in practice, users expect applications to follow the conventions of the platform and that's difficult to achieve with a single generation. It might, however, work if the framework allows for platform-specific tailoring.

Full-featured frameworks will likely be more prominent on intranet applications, where new functionality is often more critical than usability, and users can be trained to work around problems. Hand-coded HTML and Javascript is more likely for public dot-coms where alternatives are abundant and the pressure of competition means its critical to optimise the user-interface. In those environments, there is still some role for Server-Side Code Generation, but mainly as a helper for very specific tasks and with some flexibility, rather than as the overarching architectural style.

Get more information

Tags: ajax, ajax patterns, design, http, javascript, generate html, server side code, developers, java, ajaxian, web application, xmlhttprequest, server

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com