'''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 App''''''Writer'''''' helps you to do this. For example the App''''''Writer'''''' adds all of the following for you (if selected): * '''Command pattern implementation''' - A natural in any application. Yet it is often left out because people tend to not make the up-front investment needed (you ''are'' going to need it!). Adding it later, when the application really starts to get popular and more features/structure are needed, often cost very much. * Scriptable commands -- Commands that can be accessed from a pluggable scripting engine. * Undoable commands * Asynchronous commands -- choose a name: { Background''''''Command'''''' | InterruptibleCommand | Threaded''''''Command'''''' | Worker''''''Command'''''' } * Synchronizing commands -- wait for a collection of asynchronous commands to complete, then execute a command. * '''GUI''' -- If your application needs a GUI, don't spend time building a GUI from scratch, let App''''''Writer provide a default GUI for your kind of application. Leaning towards JavaSwt rather than JavaSwing (I'm glad I didn't have so much time to put into the framework until I saw SWT!). * '''General Application classes''' -- The framework includes a few classes that enables you to concentrate on what your application does right from the start. Avoid re-inventing the wheel. * '''Internationalization - i18n''' -- Read the specs on implementing i18n recently? Thought so, yet it is so simple to make your application usable world-wide. Refactor gets you started. * '''Test framework''' -- ExtremeProgramming ready. Another natural. Will be based on JavaUnit, could be pluggable. * '''Build framework''' -- ExtremeProgramming ready. Will be based on Ant (called JakartaAnt on Wiki). * '''Help framework''' -- Any world-class application needs a built-in help-system. Refactor uses standard JavaHelp to provide full help, including context-sensitive help. Again, App''''''Writer'''''' helps you maintain it. * '''Deploy-ready''' -- Out of the box, the App''''''Writer'''''' application you generate builds to a Jar-file, ready to deploy, complete with JavaWebStart support should you want it. In other words, let the App''''''Writer'''''' 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. * '''Template Application''' -- This is a complete do-nothing application, but with all infrastructure in place. Its main purpose is to be chopped up (probably using an ad hoc program that reads embedded tags, or perhaps we'll just use the C preprocessor) and serve as input to App''''''Writer''''''. * '''App''''''Writer''''''''' -- App''''''Writer serves two purposes: * It is an application generator that writes out a variant of a Template Application, based on user input such as name and type of application (standalone, applet, scriptable, WebServices client etc). * It gives you guidance and checklists on how to enhance your application, for example how to add a new command complete with everything that goes with it: i18n, help, tooltips etc. * App''''''Writer is not implemented yet. It should however evolve together with Template Application, so that App''''''Writer itself has exactly the same architecture as the applications it generates. Will ExtremeProgramming deliver? Let's find out. * '''Java''''''Calc''' -- A 3D spreadsheet in the spirit of DoTheSimplestThingThatCouldPossiblyWork. This will provide a natural example of the three different levels of document models, namely Model (a single worksheet), Document (the 3D combination of sheets) and Project (a collection of Document instances) as well as being suitable for a few View examples. * '''NN''' Your application here? You know it should be Refactored... ;-) 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''' * Please add references here. * Ralph Johnson and Don Roberts: ''EvolvingFrameworks - A Pattern Language For Developing Object-Oriented Frameworks'' available at http://st-www.cs.uiuc.edu/~droberts/evolving.pdf. * Ralph Johnson: ''Documenting Frameworks using Patterns'' available at ftp://st.cs.uiuc.edu/pub/papers/HotDraw/documenting-frameworks.ps ''Patterns'' * Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides: DesignPatternsBook * Philip Eskelin: ''InterruptibleCommand'' available at http://www.eskelin.com/patterns/PLoP98/InterruptibleCommand.pdf * UnidrawFramework, IvTools, CompoundObjectProgramming ---- '''Wishlist''' * Add your wishes here... * Should support pluggable scripting languages to make the applications scriptable. I haven't had the opportunity to research this yet. --''LN'' ---- '''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 Run''''''Script 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 Script''''''Command interface 'public Script''''''Command getScript''''''Command()' in your command class. Script''''''Command 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 Command''''''Manager 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 Default''''''Throwable''''''Handler 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. Default''''''Throwable''''''Handler 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 Default''''''Throwable''''''Handler 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 Ejb''''''Command 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'' ----