October 25, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Misusing Dynamic Binding When Static Binding Would Do, Part 2

  • November 27, 2001
  • By Brad Cox
  • Send Email »
  • More Articles »

Review Part 1

Strings Might Have More Than One Line

Java imposes such limitations on what can go in a String that it is all but impossible to handle multi-line strings such as HTML text within Java.

JSP solves this problem by letting you write HTML as a .jsp file with Java code embedded in any of several kinds of <% Java escape sequences %>. The .jsp files are compiled into Java servlets at runtime at which time the original multi-line strings (MLS) are converted to plain Java strings.

Java Web Application Architecture (JWAA) takes exactly the same approach except that the conversion is done at compile time. The MLS preprocessor converts long multi-line strings (HTML text) into ordinary .java files that Jikes compiles into .class files. Everything is done at compile time, so MLS eliminates the space and time overhead of JSP's runtime approach.

Template languages like WebMacro and Velocity take the dynamic binding anti-pattern described in Part 1 two steps further. In addition to the inappropriate dynamic couplings we described then, template languages add two more.
Code to template
The Java code in an object's controller binds to the presentation template by naming a template file.
Template to code
Template languages provide varying degrees of support for executable inclusions, conditionals, loops, and so forth. The template language provides ways for this to access a hashtable that is built by the object's controller and through which the template language interacts with the application.

Caution: Dynamic binding is harmful only when abused. The user interface designers (e.g., HTML coders) in your shop might well find the ability to tweak the template/HTML files and reload the page to see them absolutely indispensable. Their favorite HTML editing tool will almost certainly insist on a traditional file-based approach.

I don't use template languages because the file-focused data-oriented tools and designers that they accommodate do not exist in my shop. I use HTML editors only to define a site's overall look and feel and paste the HTML into an application-specific abstract Page class to be automatically applied to every page. The HTML is almost invariably supplemented with dynamically computed navigational menus, time stamps, next/prev buttons, and the like.

In other words, every page is dynamic, so the entirely static pages that HTML design tools support do not exist. The HTML text that does remain (between <body> and </body> tags) is simple enough to edit by hand; mainly table definitions and snippets of text. And I'm so used to typing make after a change that I do it automatically.

I don't find Java class declaration boilerplate objectionable as an HTML coder (and their tools) might, certainly not in comparison with the boilerplate that they do tolerate with JSP. For example, compare this permission-denied page from the JWAA demo (see Resources link below) with the JSP equivalent that follows:

package edu.virtualschool.page;
import edu.virtualschool.jwaa.*;

public class RefusePage extends Page 
{
  RefusePage() 
  {
    super( "DemoRefusePage", Role.Unknown, "RefusePage", "Permission Denied"); 
  }
  public final void controller(Ctx ctx) throws Exception
  {
    ctx.send({{
{{ asTitle(this) }}
Account {{ ctx.getViewer() }} is not authorized to do that.
}});
  }
}

Here is the same page from a comparable JSP application.

<%@ page
  extends="edu.virtualschool.states.Refuse"
  language="java"
  import="edu.virtualschool.exception.*,edu.virtualschool.beans.*,
    [code broken for readability] edu.virtualschool.franchisee.*,
    java.sql.*,edu.virtualschool.types.*"
  info="Access Denied"
  session="true"
  errorPage="error.jsp"
%>
<jsp:useBean id="thisAccount" scope="session" class="edu.virtualschool.beans.Account" />
<jsp:include page="bodyOpen.jsp" flush="true" />
<h2>Permission Denied</h2>
Account <%= thisAccount %> is not authorized to do that.
<jsp:include page="bodyClose.jsp" flush="true" />

Configurations Are Not Files

This is the most common anti-pattern example of all, and the biggest offenders are Apache and Tomcat.

Apache can be excused for its baroque configuration files because it's written in C, which some users won't know. But Tomcat has no excuse for requiring users to learn yet another new language fad (XML) when every Tomcat user knows Java, a perfectly serviceable configuration language that reports errors properly.

Tomcat compounds the problem by simply checking the XML configuration for syntactic validity against the DTD at start-up and blithely assuming semantic validity thereafter. If the configuration is wrong, Tomcat does nothing to diagnose the likely cause and present it in terms the user can understand. The best you can hope for is a stack trace from some part of the runtime that you know nothing about and may not even have the source for. The only alternative I know at that point is to download the source and debug the problem with the (excellent!) VisualAge debugger. Debugging an application's source code to fix a configuration mistake is simply unacceptable. Sigh. There, I feel much better now.

JWAA solves this in the obvious manner, by using Java as the configuration language and avoids dynamic substitutes such as XML, properties files, resource files, and the like, reserving dynamic binding for those rare cases where only dynamic binding will do. For example, to configure an application's servlet, instead of editing a configuration file, you define an AbstractServlet subclass like this:

package edu.virtualschool.page;
import edu.virtualschool.jwaa.*;
import java.io.*;
import java.text.*;
import java.util.*;
import java.sql.*;
import javax.servlet.*;
/**
 * The page servlet for the JWAA demo defines static links that
 * pages can use to access other and inherits a servlet via which
 * the same can be done via browsers.
 */
public class Demo extends AbstractServlet 
{
  private final static Page[] forceLoad = new Page[] {
    AccountPage.instance,
    AddressPage.instance,
    HomePage.instance,
    LoginPage.instance,
    LogoutPage.instance,
    RefusePage.instance,
    RegisterPage.instance,
    AdminPage.instance,
  };

  public Demo() { super(); }

  public final String getContextName() { return Config.getContextName(); }
  public final String getServerName() { return Config.getServerName(); }
  public final String getServletName() { return Config.getServletName(); }

  public final AbstractPage getDefaultPage() 
  { return HomePage.instance; }
  public final AbstractPage getLoginPage() 
  { return LoginPage.instance; }
  public final AbstractPage getRefusePage() 
  { return RefusePage.instance; }

  public final ConnectionPool getConnectionPool() throws PoolFault 
  { return Config.getConnectionPool(); }
  public void init(ServletConfig servletConfig) 
    throws ServletException
  {
    super.init(servletConfig);
    String fileName = "/www/logs/jwaa.log";
    Log.info("Writing log to " + fileName);
    try { Log.setFile(fileName); }
    catch (IOException e) { Log.error("Couldn't write to " + fileName); }
  }
}

Config is an application-specific class that encapsulates the information needed to establish a JDBC connection (dataset name, user name, password, drivers, etc) so that this information doesn't have to be hard-coded into servlets, test cases, and so forth. The version provided here loads this information dynamically, from the jdbc.properties file for the convenience of those who want to install without changing the source code. (As explained elsewhere, I don't normally do this.)

Dynamic Binding Is Harmful Only When Used Inappropriately

Object-oriented old-timers will be familiar with my early work with Objective-C and will probably be surprised at what may seem a condemnation of dynamic binding from me. After all, Objective-C is a language that simply adds Smalltalk-style dynamic binding to C.

This misinterprets the point of this rant. This is not a condemnation of dynamic binding, which can be invaluable when used appropriately. Many problems can only be solved with dynamic binding.

Rather this is a condemnation of those who use it inappropriately for problems that can be solved more straightforwardly, productively, and efficiently with static alternatives.

Summary

JWAA provides statically bound alternatives that the builder that knows how to choose the right tool for the job can use in lieu of the dynamically bound solutions of Web application environments such as JSP.

In shops such as mine where the HTML designers are also programmers, JWAA can replace JSP and/or template languages altogether, accomplishing the same thing with far less overhead in both space and time (70K total versus Tomcat/JSP's approximately 1000K). JWAA even improves deployment server security by eliminating the requirement for an SDK on the deployment server. JWAA applications only need a JRE.

Resources

About the Author

Brad Cox's background and interests are in software engineering and object-oriented software development. The connection with social and organizational learning is discussed in his collection of articles on the social construction of reality. Also see the book, Superdistribution: Objects as Property on the Electronic Frontier. He maintains the Middle of Nowhere Web as a vehicle for the distance education courses he teaches and to experience first-hand the bewildering phenomena that society has not yet mastered the taming of the electronic frontier.






Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel