From 988d113a16af74081ece5c100c7bc6c6f1dfe019 Mon Sep 17 00:00:00 2001
From: metasim <dev-null@apache.org>
Date: Wed, 24 Jan 2001 19:59:41 +0000
Subject: [PATCH] Updates to reflect some design changes.

git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@268520 13f79535-47bb-0310-9956-ffa450edef68
---
 src/antidote/docs/design-overview.html  | 48 ++++++++-----------------
 src/antidote/docs/new-module-howto.html |  6 +++-
 2 files changed, 20 insertions(+), 34 deletions(-)

diff --git a/src/antidote/docs/design-overview.html b/src/antidote/docs/design-overview.html
index 77e221702..4436afcde 100644
--- a/src/antidote/docs/design-overview.html
+++ b/src/antidote/docs/design-overview.html
@@ -106,21 +106,17 @@ Antidote Component Architecture
     to see an event before others, and in the case of <TT>AntEvent</TT
     objects, keep the event from propogating onward. The
     <TT>EventBus</TT> class defines the interrupt level constants
-    <TT>MONITORING=1</TT>, <TT>VETOING=5</TT>, and <TT>RESPONDING=10</TT> to
+    <TT>VETOING=1</TT>, <TT>MONITORING=5</TT>, and <TT>RESPONDING=10</TT> to
     help define categories of members. The implied purpose being that:
     <UL>
 
-      <LI><TT>MONITORING</TT>: Just listens for events, like a logger
-      or status monitor.</LI>
-
       <LI><TT>VETOING</TT>: Listens for certain types of events, and
       may process them in a non-default manner to determine if the
       event should be cancelled before being dispatched to the
-      <TT>RESPONDING</TT> group. An example of this might be to handle
-      a <I>SaveAs</I> event, whereby a <TT>VETOING</TT> member will
-      check to see if the file exists, and ask the user if they are
-      sure they want to overwrite the existing file. The <I>SaveAs</I>
-      event could then be cancelled before the operation is executed.</LI>
+      <TT>RESPONDING</TT> group. 
+
+      <LI><TT>MONITORING</TT>: Just listens for events, like a logger
+      or status monitor.</LI>
 
       <LI><TT>RESPONDING</TT>: Process events in a default manner,
       knowing that the event has passed any <TT>VETOING</TT> members.</LI>
@@ -190,30 +186,16 @@ Antidote Component Architecture
 
     <H2>Data Model and Views</H2>
 
-    <P>The data model is mainly defined by the Ant application,
-    primarily through the <TT>Project</TT>, <TT>Target</TT>, and
-    <TT>Task</TT> classes.<P> However, Antidote defines the class
-    <TT>ProjectProxy</TT> to act not only as a proxy to the real
-    <TT>Project</TT> class, but also as creator of GUI <I>views</I> of
-    the <TT>Project</TT>. A <I>view</I> is essentially a flyweight or
-    data proxy; it provides an orgainizational perspective on the actual
-    <TT>Project</TT> structure. For example, to render a
-    <TT>JTree</TT> version of the <TT>Project</TT>, one would call the
-    method <TT>ProjectProxy.getTreeModel()</TT>. Similarly, to get a
-    <TT>Document</TT> version of the <TT>Project</TT>, the
-    <TT>ProjectProxy,getDocument()</TT> method is used.</P>
-
-    <P><I>NB: This part of the architecture is not fleshed out very
-    well. There needs to be a discussion of the degree to which the
-    Antidote development should be able to impose changes on the Ant
-    data model, and to what level that model should be mirrored in the
-    Antidote code base. The coupling between them should be kept low,
-    and at the same time changes to one should affect the other
-    minimally. Still, features like property change events and bean
-    introspection (or BeanInfo) may be needed to be added to the Ant
-    data model. Having each view into the data go to the ProjectProxy
-    for its data model may not be the best approach. In other words,
-    lots of thought needs to occur here.</I></P>
+    <P><I>NB: This part of the architecture is not fleshed out very well. There
+    needs to be a discussion of the degree to which the Antidote development
+    should be able to impose changes on the Ant data model, and to what level
+    that model should be mirrored in the Antidote code base. The coupling
+    between them should be kept low, and at the same time changes to one should
+    affect the other minimally. Still, features like property change events and
+    bean introspection (or BeanInfo) may be needed to be added to the Ant data
+    model. Right now the data model is encapsulated in the package
+    <TT>org.apache.tools.ant.gui.acs</TT> (where "<TT>acs</TT>" stands for "Ant
+    Construction Set").</I></P>
 
     <H2>Application Context</H2>
 
diff --git a/src/antidote/docs/new-module-howto.html b/src/antidote/docs/new-module-howto.html
index f73e5262d..db0140847 100644
--- a/src/antidote/docs/new-module-howto.html
+++ b/src/antidote/docs/new-module-howto.html
@@ -26,7 +26,7 @@
     <P>NB: <I>Please submit updates and criticisms to this, particularly
     areas that were unclear, missing, or difficult to follow.</I></P>
 
-    <H2>1) Specialize <TT>org.apache.tools.ant.gui.AntModule</TT></H2>
+    <H2>1) Specialize <TT>org.apache.tools.ant.gui.core.AntModule</TT></H2>
 
     <P>All modules must inherit from the <TT>AntModule</TT>
     class. This will probably irritate some of you, but it essentially
@@ -70,6 +70,10 @@
     for a single property (via a comma delimited list), then each
     module will have it's own tab in a <TT>javax.swing.JTabbedPane</TT>.
 
+    <P>NB:<I>This goofy way of constructing the main screen will probably 
+    change to something much more general (but not as general as, say 
+    <A HREF="http://www.alphaworks.ibm.com/tech/bml">BML</A>).</P>
+
     <H2>Run it!</H2>
     <P>That should be all you need to do, at least to get your module
     plugged in. Check out the source code for