Overview

Great software requires a fanatical devotion to beauty.
- Paul Graham

The important things about WEB4J are: Graphic

In the interest of not wasting your time, we also include a listing of its drawbacks.

If you can accept the above, then WEB4J is often the best tool for the job of creating browser interfaces to databases. Because of its deep simplicity, it allows markedly faster delivery of applications.

WEB4J Has a Clear Philosophy

WEB4J stands aggressively for the following:

WEB4J stands aggressively against the following :

WEB4J is Small

One measure of complexity is size. Here is a listing of the number of documented classes in various tools :

NameNum ClassesRelative Size
WEB4J 95Graph
Servlet/JSP API 133Graph
Rails 674Graph
Struts 704Graph
Tapestry 1,091Graph
Rife 1,154Graph
JEE 1,188Graph
Spring 2,312Graph

As you can see, most tools have a size that might be described as "rather large". Note that WEB4J has the smallest surface area of any tool in its class. It's 14% of the size of Ruby on Rails, which is widely lauded for its ease of use. Correspondingly, it takes a shorter time to learn WEB4J, and to implement features with it.

Not only is WEB4J compact, but, more importantly, applications built with WEB4J are compact as well. Here are some typical line counts per feature, taken from a cross section of several features in one of the example applications. (Documentation comments are included in the line counts.)

ItemAvg LinesRelative Size
SQL file (.sql)25Graph
Presentation (.jsp)108Graph
Total133 
Model (.java)111Graph
Action (.java)144Graph
DAO (.java)46Graph
Total301 

In general, your code will only be roughly twice the size of the non-code elements of your application.

(DAOs are often short and simple, consisting only of a few single-line methods. In such cases, it's recommended that those methods be moved into the Action class.)

WEB4J Requires A Minimal Toolset

You use the following tools when building a WEB4J application: In short, you use existing, well known tools appropriate for each layer. In addition, there are no other dependencies on third-party tools, other than widely used items published by Oracle.

WEB4J Uses Convention Over Configuration

Convention over configuration is used to reduce the effort needed to create and maintain your application. It's used in the following ways:

WEB4J Application Classes Are Usually Simple

The quality of a framework can be measured by examining the concrete classes which use it. Questions to ask of a such a class include:

WEB4J performs well in this regard. Here are some examples of typical implementations:

Model Objects:

Data Access Objects (DAOs):

Actions:

WEB4J Has Nice Building Block Classes

Your application's model objects are built out of simpler classes such as Integer, BigDecimal, and so on, which WEB4J refers to as building block classes. The framework supplies building block classes appropriate to most web apps. Included among these are several custom building block classes designed to make your life easier: The other building block classes are simply taken from the JDK:

WEB4J Enables Package-By-Feature

The package-by-feature technique is a powerful method for organizing your code. It has many advantages, and is superior to the package-by-layer style so often promoted by other tools.

All items related to a single feature can usually be isolated in their own directory/package - Action, Model Object, DAO, plain text SQL statements, and even the JSP. This gathering together of all items related to a single feature (and only that feature) is extremely satisfying. It allows the following goodness:

WEB4J Forms Use Plain HTML

Forms are an important part of web applications. Most frameworks implement forms with a large set of custom tags, that are different for each framework. These are meant to replace the existing, well known HTML controls such as <INPUT>, <SELECT>, and so on. That style is suctorial, since it forces you to learn a new set of tools to do something you already know how to do - build an HTML form. This is neither necessary nor desirable.

In WEBJ, the typical form looks like this: 

<form action='MemberEdit.do' method="post">
 <w:populate using="member">
 <input name="Id" type="hidden">
 <table align="center">
 <tr>
  <td><label>Name</label> *</td>
  <td><input name="Name" type="text"></td>
 </tr>
 <tr>
  <td><label>Is Active?</label></td>
  <td><input name="IsActive" type="checkbox" value="true"></td>
 </tr>
 <tr>
  <td align="center" colspan=2>
   <input type="submit" value="Add/Edit">
  </td>
 </tr>
 </table>
 </w:populate>
</form>
The population of the form is done by wrapping a normal HTML form with a single <w:populate> tag - that's it. There are no custom tags for the various kinds of form controls. The WEB4J mechanism is the simplest possible way of populating forms.

WEB4J Has No Custom XML Files

The only XML file required by WEB4J is the deployment descriptor, web.xml. Whereas many other tools force you to spend significant time coding in XML, WEB4J was explicitly designed to let you avoid it.

In a WEB4J app, you implement features using JSPs, Java, and text files containing SQL statements. That's it. If you are looking for "XML hell", you won't find it here.

WEB4J Doesn't Use Object Relational Mapping

When building DAOs, you may use either WEB4J's data layer, or any other persistence tool of your choice. By design, WEB4J's data layer doesn't use object-relational mapping (ORM). For the majority of cases, implementing a DAO method with WEB4J's data layer will be more compact than an ORM implementation. The minority case in which an ORM tool may result in less coding effort and increased elegance is that of building an extensive object graph.

However, building an extensive object graph is the exception, not the rule. The majority of pages in a typical application relate not to relatively complex views of data, but to relatively simple ones. The reason for this is that it matches how people think, and how they work - on one specific thing at a time. Yes, large summary pages are very often part of an application, but such pages are usually the exception, not the rule.

There are some serious drawbacks to object-relational mapping:

In addition, ORM tools are sometimes invasive, in the sense of restricting the implementation of your Model Objects in certain ways, such as: These restrictions don't exist for the benefit of your Model Object. Rather, they exist because the implementation of the ORM tool needs them in order to function. That is, they represent "leaks" of the ORM tool into your data model. These restrictions are particularly annoying since they may not allow you to design your own classes as immutable objects. This is a serious defect since immutable objects have so many compelling benefits.

If you choose to use WEB4J's data layer, then these restrictions don't exist. The only restriction for WEB4J Model Objects is that the constructor must throw a ModelCtorException, and that restriction has nothing to do with persistence. Rather, it's related to an important problem each Model Object should solve: the problem of validating state, and communicating related errors to the caller.

WEB4J Uses Plain .sql Text Files

The WEB4J data layer uses regular SQL statements, stored in ordinary .sql text files. Here is an example showing the basic idea. This style has many benefits.

WEB4J Has Minimal Configuration

WEB4J has no .xml configuration files, other than the familiar web.xml file (used for a number of initialization settings). In addition, it requires the application programmer to supply concrete implementations for several interfaces. Default implementations are supplied for most of these items (no reasonable defaults are possible for the others). See BuildImpl for details.

WEB4J Doesn't Impose Thread-Safety Constraints

Some tools force some application classes to be thread-safe. In Struts 1, for example, Action classes must be thread-safe. Forcing such a requirement on an application programmer is inappropriate: WEB4J makes no requirements of thread-safety on the application programmer.

WEB4J Simplifies Multilingual Apps

WEB4J translation tools allow the implementation of a multilingual application to look almost the same as that of an ordinary single language application. All Actions, Model Objects, and DAOs are exactly the same in both cases.

The only differences are in JSPs - and even there, the differences are relatively minor. The markup retains the overall look of a single language application. It remains legible, and appears natural to the eye. This is because the WEB4J translation tags are designed explicitly to be non-invasive. For example,

WEB4J Allows Applications To Assist In Their Own Translation

The WEB4J translation mechanism can be backed by a database (recommended), or by any other means, including properties files. If a database is used to store translations, then applications can assist in their own translation.

The general idea is that, during development, all user interface items needing translation can be collected simply by exercising the application. This is done with a Translator implementation that records items having missing translations. Translations for such items can then be added later, through the browser, using screens created for that purpose, just like any other data. (Please see the WEB4J Fish & Chips Club example app for further illustration of this useful technique.)

WEB4J Protects You From Common Hacks

WEB4J has tools to protect you from common hacks:

WEB4J Has Example Applications

WEB4J has 3 example applications, of varying size:

The example applications are provided as both a starting point and as a guide. It's recommended, though not required, that your applications be created by starting with an example app, and changing it gradually. If any items are undesired, then they can usually be removed simply removed by deleting directories (and any links from menus). This is only possible because of the package-by-feature style recommended by WEB4J. (See the User Guide for more information.)

This approach is consistent with the following:

In any case, the classes in the example applications are always effective guides.

Other WEB4J Features