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 AntEventEventBus class defines the interrupt level constants - MONITORING=1, VETOING=5, and RESPONDING=10 to + VETOING=1, MONITORING=5, and RESPONDING=10 to help define categories of members. The implied purpose being that:
The data model is mainly defined by the Ant application, - primarily through the Project, Target, and - Task classes.
However, Antidote defines the class - ProjectProxy to act not only as a proxy to the real - Project class, but also as creator of GUI views of - the Project. A view is essentially a flyweight or - data proxy; it provides an orgainizational perspective on the actual - Project structure. For example, to render a - JTree version of the Project, one would call the - method ProjectProxy.getTreeModel(). Similarly, to get a - Document version of the Project, the - ProjectProxy,getDocument() method is used.
- -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.
+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 + org.apache.tools.ant.gui.acs (where "acs" stands for "Ant + Construction Set").
NB: Please submit updates and criticisms to this, particularly areas that were unclear, missing, or difficult to follow.
-All modules must inherit from the AntModule 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 javax.swing.JTabbedPane. +
NB:This goofy way of constructing the main screen will probably + change to something much more general (but not as general as, say + BML).
+That should be all you need to do, at least to get your module plugged in. Check out the source code for