https://appframework.dev.java.net/servlets/ReadMsg?list=users&msgNo=1015
I tried to keep the note very simple and concise. I could have written some very flowery sentences about compound documents, but I decided to not do that for a first E-Mail. The full text is here:
Content-Type: multipart/alternative; boundary=Apple-Mail-1--818406117
From: Thornton Green
Date: Mon, 17 Sep 2007 22:27:54 -0600
Subject: Suggestions for enhancing JSR-296
Hi,
To quote the appframework web page:
"So we're looking for feedback at this point. Constructive feedback
would be great; ranting and raving is OK too, particularly if it's
funny. We're not looking to adopt an existing framework or even for
code contributions however if there's an existing Swing application
framework you're fond of, then feedback of the form: "framework X has
a feature that JSR-296 lacks and the reason X is important is ...",
would be great."
And hence I hereby submit my suggestions. In my case, "framework X"
is Verdantium as described here:
http://verdantium.blogspot.com/
And with code posted here under GPL:
http://sourceforge.net/projects/verdantium/
http://sourceforge.net/projects/jundoruntime/
http://sourceforge.net/projects/meta/
This is an opening precis about features in Verdantium that do not
exist in JSR-296. The reason why these are important? If anybody
has questions about these items I can address them on a case-by-case
basis. Here is a partial list of features:
* Built-in Print / Print Preview / Page Setup Support
* Support for changing page size for printing (e.g. A4 versus Super-B)
* Built-in support for Printable interface
* Support for macro recording and playback
* Model-View-Controller separation of application from GUI (i.e. the
application isn't a frame).
* Better Multi-level undo. The Swing APIs implemented undo based on
the inverse-command pattern. Inverse commands are almost impossible
to write for a lot of applications. Undo really needs to be data-
driven to work across all application domains (similar to temporal
undo in JUndo).
* Visual embedding of one application within another to produce
compound documents. This allows applications to leverage each
other. I think this is very important, and it really takes advantage
of the strengths of the Java language and its ClassLoader APIs.
* Ability to embed applications directly in online help pages. This
simplifies the process of creating certain kinds of online help.
* Data oriented application loading. Framework looks at the file
being opened, and the selects the most appropriate application to
open the file.
* More support for reading and writing files in multiple formats,
including binary formats and XML.
* Better support for versioning of persistence formats.
* Larger set of lifecycle states. For instance, an embedded
application inside a container with multi-level undo can exist in
"hidden but not deleted" states that currently part of appframework.
* Support for running in MDI (e.g. JDesktopPane), as opposed to only
running in a JFrame.
* Remote loading of applications.
* More example programs. For instance, one of the applications in
Verdantium that could be used for example code is
verdantium.standard.DrawApp a drawing/container application that
support multi-level undo. I think it is important to provide several
examples of full application that provide support for container
embedding, multi-level undo, macro recording, printing, etc.
I'll stop here. I might think of more later. If you want to see
more detail, the source code for the complete framework is on
Sourceforge. I understand that you don't want to adopt a framework,
but perhaps we can find a way to cooperate.
-- Thorn
