Changes between Version 2 and Version 3 of PAGE_ELEMENT_GROUPING_R0


Ignore:
Timestamp:
04/07/09 23:42:35 (16 years ago)
Author:
peko
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PAGE_ELEMENT_GROUPING_R0

    v2 v3  
    4747 
    4848= Design = 
    49  
     49 * Grouping in most applications has the following behavior: 
     50  * Grouping of groups:  
     51   * Grouping some elements creates a group. 
     52   * Grouping some other elements creates another group. 
     53   * Selected the first group and then the second one and grouping them creates one group of the former two. 
     54   * Ungrouping the lastly created group will return back to the state where we have two groups, since it had been created from these two groups. 
     55  * Grouping of groups and elements: 
     56   * If we have a group and several ungrouped elements, select them all and group them, we will end up having a large group of all the elements from the group along with the elements that were previously ungrouped.  
     57   * Ungrouping the former group we will end up having the first group and the ungrouped elements. 
     58 * '''Note: Current design is done on behalf that we group Frames, but it can be changed quickly to support all kinds of page elements.''' 
     59 * For the grouping to behave properly we should define a tree of groups and elements. 
     60  * Define an interface GroupContainer with the following methods: 
     61   * Prop<? extends GroupContainer> parentContainer(), providing the parent GroupContainer of the class implementing it. 
     62   * RwListProp<Group> containers(), all the containers that a class implementing should provide. 
     63  * Define a class Group which will handle grouping and ungrouping of frames. It will implement the GroupContainer. 
     64  * The Page would also implement the GroupContainer interface. 
     65  * The parentContainer of the Group will be a Page. This means that the Group whose parent container is a Page is a root group. It also provides a list of containers that are Groups. The Group class will also contain a list of frames that are grouped in this group. 
     66  * Page will not have a parentContainer. It will be initially set to null. 
     67  * All this will force a parent<=>child relationship that is manually controlled from within the Group class. 
     68  * The Group class should have two static methods which will do exactly what is supposed for grouping of elements: 
     69   * public static Group createGroup(Page page, List<Frame> frames) - which will create a Group of elements and make it the root group (its parent container should be the page). 
     70   * public static void deleteGroup(Group group) - which will ungroup a previously created group. (the examples explained above). 
     71 * There was another design considered => see '''Comments section'''. 
    5072= Implementation = 
    5173^(Implementation results should be described and linked here (from the wiki or the repository))^ 
     
    5476 
    5577= Comments = 
    56 ^(Write comments for this or later revisions here.) 
     78 
     79 * We may proceed by having a parent-child relationship but this will be quite radical, since the Frame has a parent Page while the Page has a parent Book. 
     80  * Having a parent-child relationship will enforce to have something in between the Frame and Page. If the Frame is @Own by something other than the Page it will enforce to change the model so that other things that depend on Page<=>Frame, parent<=>child relationship will require more computations. Besides grouping of frames is only for selecting and editing purposes.