Changes between Initial Version and Version 9 of Ticket #340

23.10.2012 04:24:36 (11 years ago)


  • 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. 
     1The (DB attached) object implementations (topics, associations, types) have too much responsibility. 
     2The fetch/store code is encapsulated in the respective objects, that is objects fetch and store itself. 
     3This 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. 
    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. 
     7New concept: 
     8Strip 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). 
    7 GUI: 
    8 The webclient's detail panel should render the list of childs as "sortable" (like the topic type editor does). 
     10Note: this ticket was "Meta model: Child Topic Order", see #346. 
     11It turned out that ticket's task demands for the refactoring addressed here.