Refactor Application Framework

Motivation

I have seen too many worthy projects built on loose sand. Let's give every project a good start in life.

CategoryProject

The purpose of the framework

Moved to http://refactor.sourceforge.net/article.php?sid=3&mode=&order=0

Goals

This framework attempts to build a simple but high-quality general-purpose application framework, with all supporting infrastructure. The first framework is for Java and is being built as an OpenSource project. The infrastructure of a new Refactor application includes a strong foundation that's easy to use -- it must be easy and fast to start a new application based on Refactor, yet the application must be based on an architecture that is strong enough to take it to being a world-class application. This means a lot of things that are usually quite painful to add are already there for you -- you just need to maintain them as you go. The Refactor AppWriter helps you to do this. For example the AppWriter adds all of the following for you (if selected):

In other words, let the AppWriter provide you with the start, add the functionality of your application on top of it.

Methodology

The framework is being built from scratch using a methodology close to the one described by Ralph Johnson and Don Roberts in Evolving Frameworks - A Pattern Language For Developing Object-Oriented Frameworks available at http://st-www.cs.uiuc.edu/~droberts/evolving.pdf.

Starting from scratch, Three Examples (see Evolving Frameworks) are being written.

So you've read EvolvingFrameworks and think this is not right. Where are the real applications? They will be there in time. For now, I just rely on my OO application-writing experience - and yours, if you would like to share your thoughts. I certainly hope you will.

--LeonardNorrgard

Where is it?

You can find Refactor at http://refactor.sourceforge.net/. A project overview document is to appear there shortly. If you are interested in this project, please join the Refactor mailing lists using the web page at http://sourceforge.net/mail/?group_id=33745

Relevant research and other references

Patterns

Wishlist

Discussion goes below this line or on the project mailing lists, see above.

The name Refactor Application Framework might be a bit misleading. It's not a framework for writing refactoring applications, it targets application development in general. Sorry for any confusion this might lead to. --LN

Q What kind of applications does this support? Would you use it to build a compiler? A robot? A web site? Probably not. So, you should be able to describe its domain of applicability a little better. Some of it is fairly general (testing and building) but a Command framework probably assumes a human operator, as does the "default GUI". Some applications have no GUI, and this framework might not be appropriate for them. I bet the generic name is a sign that you haven't defined the domain of applicability narrowly enough.

A [long] Think "black-box framework". The answer is that not all applications define a GUI, or they can be run in both a GUI and a "headless" mode. HeadLess? (no GUI) mode can be used for running applications that supports scripting as batch jobs for example, or as a server. For a very successful example of a scripted application see TheGimp. Scripting can of course be used with a GUI as well, for example a macro definition in an editor is a kind of script and by implementing a RunScript command a user or customer can automate repeating tasks and extend the command set implemented in the application by its creators. Upcoming versions of Java now support HeadLess? mode, so you can use for example Java2D (JavaTwoDim?) to create graphics applications to run on servers without having to install the X Window System on the server.

A, contd. Extending a command to support scripting should be easy -- implement the template method 'public boolean isScriptable()' to return true and implement the ScriptCommand interface 'public ScriptCommand getScriptCommand()' in your command class. ScriptCommand needs to define the command name and possible argument structure as well as help suitable for display in an interactive script command window (or why not use the ordinary help system if there is a GUI session available). A pluggable scripting language engine can then query a CommandManager for available script commands. A, contd. At first it doesn't seem a good idea to build a compiler on top of Refactor -- not much use for the Command infrastructure there. However, using just the Refactor classes Application and DefaultThrowableHandler to catch Throwables in your application you already have a compiler command that makes it easy to submit bug-reports and you have i18n support for diagnostic messages and the bug-report dialog. DefaultThrowableHandler presents the user of an interactive application with a dialog that lets the user (1) save the backtrace log(s) for later analysis or (2) e-mail it to the application bug database. Example compiler main class: 

 // not pair-programmed, not refactored
 public class MyCompilerApp? extends DefaultApplication? {
 //...


     public void main (String args[]) {
         DefaultThrowableHandler? dth = new DefaultThrowableHandler? ();
         MyCompilerApp? myCompilerApp = new MyCompilerApp? (args);


         try {
            myCompilerApp.run ();
         } catch (Throwable t) {
            if (t instanceof ThreadDeath) {
                throw t;
            }
         dth.handleThrowable (t);
         }
     }
 }
A, contd. An application could make use of just these two Refactor classes, if the author so chooses. The Application class in the above example is needed because it provides the i18n capabilities and the resource interface so that the DefaultThrowableHandler can get the e-mail address of the bug database server. It is thus reasonable to build a compiler frontend on top of Refactor. Another example project would be to implement a compile farm server, or why not a linker -- the GNU linker 'ld' is another scriptable command line application.

A, contd. A robot, say an automatic stock market trader, is very appropriate. Unfortunately, undo functionality tends to be unavailable in that domain for the commands that need it most.

A, contd. A web site server or 3rd tier server is possible, but you would have to ask yourself if that is reasonable from a performance and scalability view. If you needed scalability in a Refactor application, you could define an EjbCommand class that delegated processing to an EJB server. See IBM's encapsulation of EJBs in ordinary JavaBeans for inspiration. If a web UI factory class was defined for Refactor I do not see a reason why a Web application couldn't be based on Refactor and servlets, for example. (For a nicely done web UI in C, see the internal web server implementation of CUPS -- CommonUnixPrintingSystem? at http://www.cups.org -- or WebMacro for a high-performance one in Java, WebMacro already has its own ModelViewController framework).

A, contd. In summary, I don't want to restrict applicability by carelessly introducing arbitrary dependencies. The framework should be black-box in the spirit of the standard Java class libraries; just because a Document class is defined in an application must not demand a corresponding View class. --LN

I just found out about a site called http://www.refactor.com who by no small coincidence is into building components-based application frameworks! I've just a minute ago sent them a mail to make contact (their site is "under construction", so no further information is available at this time - whois provides a clue to criticalpath.com, though). No luck with contacting them -- maybe when they have configure their mailserver correctly; not even postmaster@... worked. --LN

EditText of this page (last edited September 25, 2007) or FindPage with title or text search