Changes between Initial Version and Version 9 of Ticket #340
- Timestamp:
- 23.10.2012 04:24:36 (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #340
- Property Status changed from new to accepted
- Property Area changed from Data Model to
- Property Summary changed from Meta model: Child Topic Order to Refactor object fetch/store code
- Property Complexity changed from 8 to 13
- Property Type changed from Enhancement to Task
-
Ticket #340 – Description
initial v9 1 Association Definitions involving "Many" childs should specify weather the childs have a defined order. 1 The (DB attached) object implementations (topics, associations, types) have too much responsibility. 2 The fetch/store code is encapsulated in the respective objects, that is objects fetch and store itself. 3 This has proven problematic: 4 - Objects are constructed with incomplete models which causes difficult situations. 5 - Extending the meta model and reusing fetch/store code becomes cumbersome. 2 6 3 Meta model: 4 An Association Definition (both, Composition Definition and Aggregation Definition) should provide an "Ordered" flag. 5 There should be methods to control the child order programmatically. 7 New concept: 8 Strip the fetch/store code from the object implementations and collect it in its own class. This class establishes a high-level storage layer above the existing (low-level) storage layer (DeepaMehtaStorage). This high-level storage layer is responsible for fetching and storing sole models (topic models, association models, type models). Construction of actual (DB attached) objects is up to the application layer (DeepaMehtaService). 6 9 7 GUI: 8 The webclient's detail panel should render the list of childs as "sortable" (like the topic type editor does).10 Note: this ticket was "Meta model: Child Topic Order", see #346. 11 It turned out that ticket's task demands for the refactoring addressed here.
