|
Class Summary |
| AddTransaction |
Transaction for adding a SeqFeatureI. |
| AnnotationAddEvent |
AnnotationChangeEvent for add |
| AnnotationChangeEvent |
A controller managed event class which signals when a change is made to
a set of annotations and what type of change occurred. |
| AnnotationChangeLog |
DELETE THIS - replace by TransactionManager - i think i got all references -
test that it works out and delete!
Logs AnnotationChangeEvents which are fired when edits occur. |
| AnnotationCompoundEvent |
|
| AnnotationDeleteEvent |
|
| AnnotationEditor |
A class for performing edits on the annotations. |
| AnnotationReplaceEvent |
This class is temporary in theory. |
| AnnotationUpdateEvent |
|
| AnnotSessionDoneEvent |
This event indicates that the editor is done with a series of edits. |
| ChangeList |
TransactionManager does the real coalescing for saving transactions. |
| CompoundTransaction |
A CompoundTransaction contains a list of Transactions (children). |
| DeleteTransaction |
The transaction class for deleting operation in Apollo. |
| FeatureChangeEvent |
A controller managed event class which signals when a change is made to
a set of features and what type of change occurred. |
| ResultChangeEvent |
A controller managed event class which signals when a change is made to
a set of features and what type of change occurred. |
| Transaction |
Class for keeping track of transactions (changes to annotations or
annotation subparts (transactions, exons)). |
| TransactionClass |
Value class for transaction object classes
Presently used for Transaction. |
| TransactionManager |
|
| TransactionOperation |
Value class for transaction operations - not sure how serializing will work
i think when it deserializes it will have the string but not the final static
which could mess up things(like undo). |
| TransactionSubpart |
Enumeration/value class that captures the subpart of the feature that is
effected by the transaction. |
| TransactionUtil |
Does all the retrieving of subpart stuff - im contemplating subclasses - it would
be a lot of subclasses - or there could be a separate subclass for each type
this is getting slowly phased out for TransactionSubpart subclasses |
| UpdateParentTransaction |
|
| UpdateTransaction |
Transaction class for updating. |
| UserName |
|