Announcement - New Forum in the Saloon

by Jason Menard - Programming Diversions Bartender

Return to Top

Programming Diversions Puzzle

by Jason Menard

As a new feature of the JavaRanch Newsletter, and to go along with our new Programming Diversions forum, we will be offering a monthly programming puzzle. Here we now present to you the first of hopefully many such puzzles. Enjoy!

WordSearch

Given any N X N grid of letters (where N > 0, N <= 100), and any set of words which may be found in the grid, write a program to find and display the starting and ending grid coordinates for each word. The top left corner of the grid is [0,0] (row 0, col 0), and the bottom right corner of the grid is [N,N].

You may input the grid of letters and the words in the manner of your own choosing. Words in the grid may be found oriented in any direction within the grid (vertical, horizontal, reverse-horizontal, reverse-diagonal-up, diagonal down, etc...).

Use the following grid and list of words to test your code.

xbcbdjwgpmpcfsh
avijureeroltfha
bdsheriffnamnev
lsuraibvoikoist
iakpffrsngtoshr
zhdanosourzsrea
eicnuludnexerwn
rednetrabvasbec
mldoarahcdwyvrh
auyjvroosendetl
pkypuiaciornede
sitemapvitralsv
rafnopekaminiui
umlksreyejmlpir
pgetwdmpevitood


javaranch
moose
bartender
sheriff
drivel
reviews
uml
threads
jdbc
roundup

Return to Top

by Frank Carver

Abstract

This article is the third of a series which laments the bloated and unmaintainable state of so many J2EE web applications and looks at ways to keep web applications small, simple and flexible. The series uses the author's Friki software as a case study, and discusses ways to design and build a powerful, flexible and usable web application in less space than a typical gif image.

This article continues the coding process begun last time, and finally starts working on real user requirements. On the way it helps take the effort out of rebuilding and re-running tests whenever anything changes.

Introduction

If you've read the first and second articles, you should be aware that the aim of this project is to develop a small, simple and understandable "Wiki" (editable web site) application. We've considered and decided to defer the relatively heavy decision of how to store and retrieve pages by introducing a Java interface, decided on and implemented a simple "template" system to display pages, and are building a supporting test suite as we go along.

Before we continue, I'd like to remind everyone of what our "customer" wants. For the purposes of this article, our customer says we will be "done" when we have a Java web application in which:

1. each page may be viewed using it's own unique URL
2. page content may contain links to other pages by name
3. links to nonexistent pages will be marked with a "?"
4. page content may be created and edited using just a browser
5. at least 100 different pages can be stored

What do we write next?

By now, you should know that we start each new feature by writing a test for it, so the questions should perhaps rather be "what do we test next?". Whichever way you look at it, this is still a tough choice. If we want to make real progress toward our customer's goals, we need to start delivering software which meets those goals. So far, all we have is a repository interface and a template engine, neither of which is mentioned in the list.

There are lots of ways of deciding what to do next. Perhaps simply do them in the order they are written in. Maybe do the hardest first so we learn the most. Maybe ask the customer which is most important. I'm sure you can think of many more. In this case I'm going to recommend that we start by choosing the easiest to test. The idea behind starting with the easiest is that the customer goals are all tangled together. The more we can remove from the tangle, the simpler the rest will become. With any luck, by the time we get to the hard tasks, so much will already have been removed that they will be easier, too. The idea behind starting with the easiest to test is that until we have written a test, we can't start writing code, and I want to start writing real code as soon as possible.

Using this approach (often known informally as "pick the low-hanging fruit") can be suitable at the start of a new project or large single change, where there are several inter-related requirements which all need to be met for anything to work at all. Beware, though! This approach can become dangerous as soon as something has been delivered which the customers/users can try themselves. At that point it is usually better to pick whichever the customer wants the most, and see how that affects the remaining ones. It is also important to resist the temptation to keep adding more "vital" features which delay this first delivery. The sooner we can get real priority decisions from the customer, the better.

We have decided to go for the easiest to test. Which one is it?

Goals one and four look like we would need to set up a web server of some sort. To make it work would in turn mean building our software into something which can be deployed to the web server. The tests would maybe try to fetch pages from different URLs and see what they get. Sounds a lot of work before we see any results. Goal five looks like it would need us to build that repository we keep putting off. Goals two and three look as if they can be tested in a similar way to the way we tested the template engine, which seemed pretty easy. I think I'll choose to do goal two first, as completing it might help make goal three easier.

First task: "page content may contain links to other pages by name"

Let's start with a nice simple, "empty" test to make sure we have everything working. Even with this, we still need to think about how we would use the code we are going to write. One of the simpler ways is to think of it in terms of a formatting process. Some "raw" text from a stored Page will be "formatted" into "processed" text containing links where neccesary.

AllTests.java

package tests;

import junit.framework.*;

public class AllTests extends TestCase
{
    public static TestSuite suite()
    {
        TestSuite ret = new TestSuite();

        ret.addTest(new TestSuite(EmptyTest.class));
        ret.addTest(new TestSuite(TemplateTest.class));
        ret.addTest(new TestSuite(LinkTest.class));

        return ret;
    }
}

LinkTest.java

package tests;

import junit.framework.*;

import friki.PageFormatter;

public class LinkTest extends TestCase
{
    public void testEmpty()
    {
    	PageFormatter formatter = new PageFormatter();
    	assertEquals("", formatter.format(""));
    }
}

PageFormatter.java

package friki;

public class PageFormatter
{
    public String format(String input)
    {
        return input;
    }
}

Just as with the TemplateEngine, the first test and the first implementation can feel a bit like cheating. But remember, all of this is part of the design process -- we have already designed how to use the formatting code, now we have to make it work for more cases.

Next, though, a major design turning point. We know that "processed" page names will need to appear as HTML links, but how should we represent the names of pages in the "raw" text? This is an important decision, users of the system will have to type one of these names in to the browser every time they want to link to another page. The answer is not obvious, either. There are Wikis which use patterns of upper-case and lower-case letters, and automatically recognize things like FrankCarver and FrikiServlet. There are Wikis which use any group of characters wrapped in end characters like [[Frank Carver]] or {:Friki}. There are Wikis which use any alphabetic or alphanumeric word which starts with a special symbol, like @FrankCarver or ~Friki. There are even Wikis which check every word in the text, in case it might be the name of a page, and need no special delimiters at all.

This decision is so important, it needs the involvement of the customer. The job of the developers is to explain the options and answer questions to help the customer choose the right compromise between desired features and cost. In this case, our customer grumbles a bit, and settles for the word-starting-with-symbol approach, using '@' as the symbol. He says he may change his mind later, but we knew that already!

With this knowledge we can add some more tests to our LinkTest class:

    public void testNonLink()
    {
    	PageFormatter formatter = new PageFormatter();
    	assertEquals("hello", formatter.format("hello"));
    }

    public void testEmbeddedLinkSymbol()
    {
    	PageFormatter formatter = new PageFormatter();
    	assertEquals("friki@javaranch.com", formatter.format("friki@javaranch.com"));
    }

Both these tests pass with no extra code. Excellent. However, just as with the TemplateEngine test case, we now have the same setup code appearing in three places. It's time to remove the duplication and create a setUp fixture.

LinkTest.java

package tests;

import junit.framework.*;

import friki.PageFormatter;

public class LinkTest extends TestCase
{
    PageFormatter formatter;

    public void setUp()
    {
    	formatter = new PageFormatter();
    }

    public void testEmpty()
    {
    	assertEquals("", formatter.format(""));
    }

    public void testNonLink()
    {
    	assertEquals("hello", formatter.format("hello"));
    }

    public void testEmbeddedLinkSymbol()
    {
    	assertEquals("friki@javaranch.com", formatter.format("friki@javaranch.com"));
    }
}

Now we get to add a test which fails:

    public void testLink()
    {
    	assertEquals("<a href='view?hello'>hello</a>", formatter.format("@hello"));
    }

As usual, the next step is to write the simplest solution. Maybe something like:

PageFormatter.java

package friki;

public class PageFormatter
{
    public String format(String input)
    {
    	if (input.startsWith("@"))
    	{
            return "<a href='view?" + input.substring(1) + "'>" + input.substring(1) + "</a>";
    	}

        return input;
    }
}

Good, That works. It's a bit messy, and I can see some duplicated code in there, so lets refactor it to tidy it up. Don't forget to re-run all the tests after every change to make sure nothing has broken.

PageFormatter.java

package friki;

public class PageFormatter
{
    private String symbol = "@";

    private String makeLink(String name)
    {
        return "<a href='view?" + name + "'>" + name + "</a>";
    }

    public String format(String input)
    {
        if (input.startsWith(symbol))
        {
            return makeLink(input.substring(symbol.length()));
        }

        return input;
    }
}

You can probably guess where we go next. We've done just enough testing to test that we can generate a link, but it's pretty obvious that a Wiki page with just one word is not very useful, even if it is a link to another page. So we need to test that the PageFormatter can find and convert page references wherever they appear in a page. So, we add another test:

    public void testLinkInPage()
    {
    	assertEquals("You say <a href='view?hello'>hello</a>, I say goodbye.",
    		formatter.format("You say @hello, I say goodbye."));
    }

After the last test passed, we refactored the code to be simpler and neater. Now is a chance for a second sort of refactoring, the kind you can do before a change, to make the change itself simpler. I'm pretty sure we'll still need to be able to convert a word to a link if it starts with the special symbol, so let's extract that code as a method, which we can call from the "smarter" code we are about to write.

PageFormatter.java

package friki;

public class PageFormatter
{
    private String symbol = "@";

    private String makeLink(String name)
    {
        return "<a href='view?" + name + "'>" + name + "</a>";
    }

    public String formatWord(String word)
    {
        if (word.startsWith(symbol))
        {
            return makeLink(word.substring(symbol.length()));
        }

        return word;
    }

    public String format(String input)
    {
        return formatWord(input);
    }
}

Our new test still fails, of course, but now we have a clean place to put the new code. Of course there will be other changes to this class, but it's often a good idea to "clear the decks" before adding anything major.

PageFormatter.java

package friki;

import java.text.CharacterIterator;
import java.text.StringCharacterIterator;

public class PageFormatter
{
    private char symbol = '@';

    private String makeLink(String name)
    {
        return "<a href='view?" + name + "'>" + name + "</a>";
    }

    private boolean startsWith(String word, char symbol)
    {
    	return word.length() > 0 && word.charAt(0) == symbol;
    }

    public String formatWord(String word)
    {
        if (startsWith(word, symbol))
        {
            return makeLink(word.substring(1));
        }

        return word;
    }

    public String format(String input)
    {
        StringBuffer word = new StringBuffer();
        StringBuffer ret = new StringBuffer();

        CharacterIterator it = new StringCharacterIterator(input);
        for(char c = it.first(); c != CharacterIterator.DONE; c = it.next())
        {
            if (c == symbol || Character.isLetter(c))
            {
            	word.append(c);
            }
            else
            {
                ret.append(formatWord(word.toString()));
                word.setLength(0);
                ret.append(c);
            }
        }

        ret.append(formatWord(word.toString()));

        return ret.toString();
    }
}

It looks like we've finished one of the user's goals. Hooray!. There are, of course, a few things to note about this code:

First, although that "formatWord" method is still there, it has changed a little. The variable "symbol" is now a char rather than a String to make things easier in the "format" method. This restricts future expansion a tiny bit, but that doesn't matter. If anyone really ever wants to use a multi-character word prefix, there isn't much to change. The thing that irritates me most is that I can't use the built-in and nicely descriptive String.startsWith method any more, as there is no version for asking if a String starts with a char. Sigh.

Second, the structure of the "format" method looks strangely similar to the TemplateEngine.expand method we developed last time. Bear this in mind, and if we see an opportunity, we should consider refactoring the whole system to remove this duplication.

Making Rebuilding Simpler

Are you getting fed up with all that typing "javac ..." and "java ..." yet? I know I am. Even if you use an IDE or a command-line history mechanism which hides it, there's still a lot of repetition. We owe it to ourselves and to our customers to stamp this out. The solution I suggest for this is to use a "build tool".

A build tool is a program which reads a pre-defined set of instructions and relationships, and uses them to build software for you. A build tool is a kind of specialized scripting language, indeed you can get a long way using just the scripting abilities built in to your system (DOS .bat files, Unix shell-scripts etc.). In this case I recommend the Ant build tool from the Apache project. If you are not already familiar with Ant, you may want to look at Thomas Paul's March 2002 newsletter article, and install Ant as directed.

Ant is flexible and powerful, and we will be using some of its more interesting features in later articles. For now, though, we just want to get it to compile and test our code. Before we leap into scripting, we need to understand what we want Ant to do, and we also need to be able to test (even if only by inspection) that it has done it right.

The first step is to set up a sensible directory structure for our project, and copy our source files into it. The structure I recommend follows the common Ant pattern of separate directories for separate operations. In particular, note that source code and classes for the delivered application are kept completely separate from the test code. We will likely have more test code than application code by the time we have finished, and we want to keep the delivered application as lean as possible. So we keep test code separate to avoid the risk of delivering any of it.

                   friki
                     |
         +-----------+----------+
         |                      |
        src                   build
         |                      |
   +-----+------+           +---+---+
   |            |           |       |
delivery      tests      delivery tests
   |            |           |       |
 +-+---+      +-+--+        |       |
 |     |      |    |        |       |
java files  java files   classes classes

1. Copy PageFormatter.java and TemplateEngine.java into friki/src/delivery/java/friki
2. Copy AllTests.java, EmptyTest.java, LinkTest.java and TemplateTest.java into friki/src/tests/java/tests
3. Create a new file friki/build.xml and put the following into it:

build.xml

<project name="friki" default="build" basedir=".">

 <path id="classpath">
   <pathelement location="build/delivery/classes"/>
   <pathelement path="${java.class.path}"/>
 </path>

 <path id="testclasspath">
   <pathelement location="build/delivery/classes"/>
   <pathelement location="build/tests/classes"/>
   <pathelement path="${java.class.path}"/>
 </path>

 <target name="clean">
   <mkdir dir="build"/><delete dir="build"/>
 </target>

 <target name="compile-delivery">
   <mkdir dir="build/delivery/classes/"/>

   <javac srcdir="src/delivery" destdir="build/delivery/classes" debug="on">
     <classpath refid="classpath"/>
   </javac>
 </target>

 <target name="compile-local-test">
   <mkdir dir="build/tests/classes"/>
   <javac srcdir="src/tests/java" destdir="build/tests/classes" debug="on">
     <classpath refid="testclasspath"/>
   </javac>
 </target>

 <target name="compile" depends="compile-delivery,compile-local-test"/>

 <target name="test">
   <junit fork="yes" haltonfailure="yes" printsummary="yes" dir="build/tests">
     <jvmarg value="-Djava.compiler=NONE"/>
     <test name="tests.AllTests"/>
     <classpath refid="testclasspath"/>
     <formatter type="plain"/>
   </junit>
 </target>

 <target name="build" depends="compile,test"/>
</project>

This may look complicated, but mostly it's just a way of configuring Ant to understand the directory structure we are using. Each target is equivalent to a public method or function definition, and the final "build" target brings them all together

Now, open a command-line, change to the top friki directory, and type ant. As specified on the first line of the build file, if no target name is specified it runs the default "build" target. You should now see a series of messages finishing with something like:

test:
    [junit] Running tests.AllTests
    [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.156 sec

build:

BUILD SUCCESSFUL

If you get any complaints from Ant, double-check the directory structure and the build.xml file. If you see any failures or errors reported by junit, look in the file friki/TEST-tests.AllTests.txt for more details. If it all works, celebrate!

How are We Doing?

We still haven't made a Wiki yet! But we have met one of the five user goals. We have continued expanding our test suite to cover everything we have done so far, and have created a directory structure and build script to enable the whole project to be built and tested using a single, simple command. We are poised on the edge of producing a real web application.

Next session we'll add more customer features to our Wiki and extend our build script to automatically create a deployable "web application archive" (war) file. Why not try and guess which of the remaining customer goals will be next on the list...

Return to Top

The Coffee House

by Solveig Haugland

Brenda and Lacey Explain Dating Design Patterns

Solveig Haugland is an independent writer and trainer based in Colorado. She has a lot of different projects going--outdoor sports footwear, OpenOffice.org and StarOffice, patterns, Java, and dating. And Java and dating.

Her projects are usually well behaved, sitting in their separate directories and waiting patiently to be brought up again, but occasionally they get bored and start checking each other out. Occasionally the projects even have rowdy parties in the middle of the night and wake up in the wrong directory in the wrong clothes, which is how dating design patterns thing happened. See additional results of this improper intermingling of patterns and dating logic at www.datingdesignpatterns.com.

You can contact her through her OpenOffice.org training and books Web site, www.getopenoffice.org, or via solveig@getopenoffice.org.

Return to Top

Top 10 Ways You Can Get to Know and Love OpenOffice.org

by Solveig Haugland

So, you know you should be using OpenOffice.org, it's free, it's the Right Thing to Do, but like switching from Hostess Cupcakes to high-fiber cereal, it's hard to break the habit of MS Office and switch to OpenOffice.org. Here are a few things to help make the transition less traumatic and more fun.
 

1. Get a book. Because Germans don't do usability. You can do a whole lot in OOo but easily find the options to do everything is not one of them. To create a background in OOo's Powerpoint equivalent, for example, you need to click on either Slide Design or choose View > Master > Drawing. Actually making the background is really easy and you have a lot of power and flexibility but getting there isn't obvious. The mantra of OOo users is "It's easy when you know how."


"My "OpenOffice.org Resource Kit" has the CD in it, if you don't want to wait for the download. Michael Koch also has a book on StarOffice 6.0 which you can use for OOo.

For a simple download page (the openoffice.org site is a bit labyrinthian), go to www.getopenoffice.org/download.html

2. The datasource connection is pretty cool. Easier than last time and more useful, the premise is that you can connect to any database you want, including a bunch of open source databases. You just get to choose your means of connection: ADO, JDBC, ODBC, etc. You can also just create a plain delimited text file or spreadsheet and use that as your data source.
3. Take a look at the Stylist. (Choose Format > Stylist.) You've got a bunch of built-in styles, and as you've probably been told by upstanding technical writers, using styles makes your life so much easier. The Stylist is one of the easiest and most effective tools in the program. Just format text how you want it and click the New Style From Selection to create a new style. Want to update the style? Just select that same text, change it, and click Update Style. It's pretty straightforward.

4. Spend some time in Draw. Get to know the connector lines. It's like a mini-Visio. The lines stay connected to the objects no matter where you move them.

5. Spend some time in Draw with the 3D features. You will probably be surprised. You get spheres, toruses, cubes, half spheres, etc. Rotate the shapes around and you'll see the frame rotating as you turn it.

6. Spend some time in Draw with the text. AutoText has some pretty cool stuff for curving text to preset lines or your own line.
 
7. Check the conversion of your MS documents. Feed them through the converter (File > AutoPilot > Document Converter). The wizard makes an OOo copy of each of your MS documents, so you can see how they did. This is an easy way to tell how much work you'll need to do on the OOo end to tweak formatting, and what you'd have to do after switching to OOo to work with people who do straight MS files.
8. Choose Tools > AutoCorrect/AutoFormat and turn off everything under every tab. This is how you turn off nearly everything annoying like word completion.
9. Note that in the latest version of OOo, you can print straight to PDF, and you can also export Impress (Powerpoint equivalent) presentations to Flash as well as HTML.
10. All files are compressed XML. Unzip any OOo file and you get styles.xml, content.xml, and so on. Open the XML file in Textpad or your favorite editor and you can change any of the source (providing you don't goof up the XML, of course). This is particularly useful for editing broken graphics links or getting rid of the 2000 extra styles you somehow got when you converted from Word.

Compressed XML also means the files are very very small.

You can contact Solveig through her OpenOffice.org training and books Web site, www.getopenoffice.org, or via solveig@getopenoffice.org.
 
 
 
 
 
 

Return to Top

JavaRanch at JavaOne 2003

by Jessica Sant

If you're attending JavaOne, be sure to check out your fellow JavaRanchers!

BOF-3061: Certification Roundtable with Michael Ernest and Jessica Sant

This informal session offers help, advice, and guidelines for anybody who wishes to start or is following the Sun certification process. This session is not a technical Q&A forum, but rather an interactive forum where the panel answers questions and offers advice in the way of reading lists, tips for study, and tips for the exams.

The panel includes Sun certified JavaTM technology platform technologists at all levels, with the added bonus that they help run the JavaRanch Web site, one of the largest independent Java technology communities on the Internet with a strong focus on the certification programs.

BOF-2955:JavaTM Technology in the Classroom: Teaching Finance Using Java Technology with Mark Herschberg and Jon Gadzik

Finance is a field traditionally taught through books and lectures. However the application of the knowledge is often illustrated through executing actions through software. Harvard Business School has sought to revolutionize the teaching of finance by having a game-based lesson model. Software, written to mimic trading applications used on Wall Street, is used extensively to teach each lesson throughout the semester long course. This session discusses how we were able to employ JavaTM technologies to quickly and easily create a such a game, and how these Java technology-based games may enhance the educational experience.

BOF-1672: Design Patterns and Best Practices for JavaTM Technology-Based Mobile Applications with Michael Yuan and Ju Long

Mobile commerce requires sophisticated enterprise backends and pervasive user interfaces. Due to the limitations of mobile devices and wireless networks, some unique design and implementation issues must be addressed when developing end-to-end mobile commerce applications. In this presentation, we discuss design patterns and best practices in mobile application development. We focus on two crucial aspects: smart mobile client and seamless client-server integration. We use several concrete mobile JavaTM technology-based applications, including the Sun Smart Ticket blueprint, as examples.

Smart mobile client must take advantage of the performance, reliability, and rich UI benefits offered by thick client technology. At the same time, it must be light enough to fit into and run smoothly on small handhold devices. We discuss the benefits and implementation of MVC and variant patterns, background thread and gauges, cache for performance, reliability, and security.

On the integration front, the diversity of mobile applications calls for a variety of integration schemes. We discuss important integration techniques, including Remote method call, asynchronous messaging, binary-over-HTTP, XML, SOAP Web services, SyncML, and session tracking.

After this talk, you have a better understandings of the unique challenges facing mobile application development; get familiar with common approaches; be able to judge which pattern is the best based on application circumstances; learn other people's approaches from discussions. This is an intermediate to advanced level session. Prerequisites: Working knowledge on design patterns, client-server model, MIDP, XML, Java technology stream I/O, SOAP Web services, and HTTP.

Return to Top

Jenny the db code generator

This program reads a database and generates java source which provides strongly typed access to the database.

by Paul Wheaton and Marilyn de Queiroz

Why was Jenny created?

1) There are slight differences in SQL, drivers, app servers, database access, etc. that make it clear that a facade is needed. The facade would provide access to the database in plain java (not SQL). All of the implementation specific code is concentrated in one small area instead of spread out all over your application. The DBFacade class fixes this problem.

2) For any database change, it takes a great deal of discipline to find all of the table names and column names used throughout your code that now functions differently. Even the slightest lack of discipline results in a bug that might not be discovered until run time. Strong typing eliminates this problem. This program (Jenny) provides the strong type checking.

For each table and view in a given database, Jenny will create a java source class file. Each of these classes will provide a collection of general purpose methods for working with the table/view. They will also provide a list of all the column names, the table/view name and an inner class called Row that can be used to manipulate a single row in the table.

Many tables have a primary key that is a non-nullable integer called "tablenameID" or sometimes "ID". If Jenny finds this, she will add extra methods to the generated source for working with the primary key.

• Simplicity: Accessing the database needs to be as simple as possible. I decided that this meant using static methods for the table level methods. All connections, statements, result sets and all other objects that need closing are generally managed for you so you don't have to worry about it - thus eliminating about 70% of the code required for typical JDBC access.

• Unit Testing: I want to auto-generate a Mock class for every table class to facilitate unit testing. This means that I need to have something I can override. Since static methods cannot be overridden, I need an inner class that the static methods use that I can override for my mock classes. This also means that I need to hide all of the Row constructors so a mock object can be returned. This allows unit testing without having to provide SQL in the unit tests or to have a database server running during the testing.

• Flexibility:I want to be able to allow alternate connections, or to make several database calls with one connection, so every database access method allows me to pass in a connection object. I also want to allow multiple ways to get to the same database; support multiple databases on one database server; support the use of multiple servers being used from one application.

• Functional Testing: I want to allow for functional testing (sometimes called integration testing - kinda like unit testing, but with more than one class and sometimes the actual database) so I allow all classes to replace the connection source at the facade level.

• Clear Division of Labor: I want to work with the idea that the database is managed by a DBA and business logic is managed by software engineers. So fancy database stuff is done by the DBA in the database (i.e. joins are handled within views by the DBA). In most big software shops, the software engineer will be accessing data in an existing database that is managed by a DBA that has far more experience with the database than the engineer. Anything that cannot be done through the facade probably needs to be done on the database side.

• Complexity Reduction: I want to avoid having complex relationships defined in an XML document or embedded in the code. Good engineering is making complicated business logic look SIMPLE! My experiences with object databases, object to relational mapping, CMP and similar tools is that they promise simplicity, but when you get right down to it, it becomes horribly complicated!

• Self Discipline Not Required! Many solutions similar to Jenny require human engineers to have the discipline to make sure that any changes in one place are reflected in other places. If your table name in your database does not match the table name in your java code, you have a problem! With this solution, you don't need that discipline. Therefore you have more reliable code.

What does Jenny do?

      Row getRow()
      Row getRow( String column , String searchText )
      DBResults search( String column , String searchText , String[] dataColumns )
      Row[] getRows( String column , String searchText )
      Row[] getAllRows()
      DBResults search( String[] dataColumns )
      void update( String column , String searchText , Map data )
      void delete( String column , String searchText )
      void insert( Map data )
    

      Row getRow( int id )
      void delete( int id )
    

       void update()
       void delete()
       void insert()
    

       int getEmployeeID()
       void setEmployeeID( int employeeID )
       String getLastName()
       void setLastName( String lastName )
    

       // pass in an employee ID and get back the number of tax exemptions that the employee claims
       private int getEmployeeExemptions( int employeeID )
       {
           return EmployeeTable.getRow( employeeID ).getExemptions();
       }
    

How do I use Jenny?

Make sure your classpath includes jr.jar and then at the command prompt type:

                java com.javaranch.db.Jenny db.properties
      

where db.properties is a properties file that describes how Jenny should find your database. There is a sample properties file complete with in-line documentation inside jr.jar at /src/com/javaranch/db/soup.properties.

Bring up the class in your ide and tell it to Run.

Of course, you have to have jr.jar in your IDE's classpath; you have to define the "Main Class" (a.k.a "Target" or "command") as <path>/com.javaranch.db.Jenny; you have to define the "Program Parameters" as db.properties (where db.properties is a properties file that describes how Jenny should find your database. There is a sample properties file complete with in-line documentation inside jr.jar at /src/com/javaranch/db/soup.properties); and you have to tell it which is your "working directory" (a.k.a "Start in" or "initial folder")

She's still maturing

Note that development of Jenny is on-going and she's currently available as a beta release. Take 'er for a spin, and stop by the JDBC forum in the Big Moose Saloon to participate in her growth.

Return to Top