Beautiful Hunk of Java

I know, the title reads to some as an oxymoron, especially in light of Java's gnarly syntax requirements for closures. Still, some things are made beautiful partly because of the ugliness of the constituent material. Imagine a sculpture of Jessica Biel made of excised warts.

public enum SubstitutionVariable
{
 AdjusterEstimator("Adjuster / Estimator", new ValueProvider()
 {
     public String get(Database db, OrderRec hdr) throws Exception
     {
         return hdr.selectAdjusterName(db) + " / " + hdr.selectEstimatorName(db);
     }
 }),
 CustomerName("Customer Name", new ValueProvider()
 {
     public String get(Database db, OrderRec hdr) throws Exception
     {
         return hdr.selectCustomerName(db);
     }
 }),
 InsuredName("Insured Name", new ValueProvider()
 {
     public String get(Database db, OrderRec hdr) throws Exception
     {
         return hdr.oInsured;
     }
 }),
 WorkOrderClaim("Work Order / Claim", new ValueProvider()
 {
     public String get(Database db, OrderRec hdr) throws Exception
     {
         return hdr.oWorkOrder + " / " + hdr.oClaim;
     }
 });
 interface ValueProvider
 {
     String get(Database db, OrderRec hdr) throws Exception;
 }
 //
 //...some boring details left out...
 //
 private final String description;
 private final ValueProvider valueProvider;
 public static String substitute(String p, Database db, OrderRec hdr) throws Exception
 {
     for (SubstitutionVariable v : sortedByLengthDescending)
     {
         p = v.replace(p, db, hdr);
     }
     return p;
 }
 //
 private SubstitutionVariable(String description, ValueProvider performer)
 {
     this.description = description;
     this.valueProvider = performer;
 }
 //
 public String getDescription()
 {
     return description;
 }
 //
 private String replace(String p, Database db, OrderRec hdr) throws Exception
 {
     return StringKit.replace(p, "%" + name() + "%", valueProvider.get(db, hdr));
 }
}

Web Non-Framework

I recently finished a project to produce a web site described with PhotoShop for deployment to a content management system. To force myself to focus on interface design, I chose to limit the server-side facilities used to includes only.

Includes Only
While I had already reached the conclusion intellectually, the exercise reinforced my impression there is seldom a good reason to build HTML in server-side code.

HTTP ↑ JSON ↓
I have now built two small applications that do not include any HTML building or any sort of "application model" on the server side. Other than includes used as needed, at the top of each page is enough server-side code to invoke security checks and retrieve data formatted in JSON that will be used in all cases. Retrieval of anything optional is left to ajax invocations. The applications in question include sending e-mail, file uploading, image manipulation, and reporting with PDF, so they're not just sunny-day tests.

Tools
On the client side, I have tools to exchange data among JSON objects, form elements and ajax request parameters, and a facility for presenting error messages from client-side validations. On the server side, I have a persistence kit, a flexible model to map requests to data dispensers and updaters and a tool to deliver messages from server-side validations.

Sample

//I really can't imagine that anyone in my intended audience doesn't already know
//exactly how to code everything I've described, so why bother with a sample?

(Preliminary?) Conclusion
As long as the client-side script is kept in good order, I can't yet see where this approach will break down, while I can definitely say that working with this non-framework feels more enjoyable than with any web framework I've used so far.