Last modified 13 years ago Last modified on 06/23/09 13:56:10

Error: Macro BackLinksMenu(None) failed
compressed data is corrupt

Error: Macro TicketQuery(summary=PAGE_ELEMENT_GROUPING_R0, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|) failed
current transaction is aborted, commands ignored until end of transaction block



Every book view has a work area related to it. It must contain the corresponding page, as well as the book extras, attached to it. Pages can contain frames or groups of frames. Extras probably will have similar abilities in the near future.

  • The groups should be a method for organizing frames and other groups for easy manipulation - for example, we can group several frames to move/resize them together, change their background, etc. If we go further, groups should contain frames and/or other groups. (There is tree structure here) Also moving, rotating and resizing one group should effect the entire group. All of the children of a group should preserve their relative position, rotations and sizes. Visual result should be like they are stuck together.
  • Grouping 2 elements (groups an/or frames) together means making a group, containing both of them.
  • Ungrouping of group is detaching its top-level elements from each other.
  • Groups should not contain both frames and stickies (for example), so it would be better if book extras were at the same grouping level as the page itself.
  • A page element (frame, sticky, etc.) can be in only one group at one time.
  • Create and break a book could be done in following way after selecting a element or elements.
    • Halo buttons.
    • Short keys
      • ctrl + g for creating a group
      • ctrl + b for braking a group
      • Double click on group for edit her
    • From the edit menu should be section for groups with create, edit, and break buttons.
    • NOTE: If user selects for example 2 groups and 2 frames and press ctrl + b. This action will break(grouping) the 2 groups but won't have effect over the frames.
    • Every group of page elements (not for book extras) has a timeline.

Task requirements

  • Define how grouping should be introduced in the model.
    • Groups must be persistable along with the book.
    • Groups must not conflict with the current template model.
    • A group cannot contain both frames and extras.
    • If a group is loaded it should be represented as selected elements in the view.
  • Create a halo button that will create a group of elements from the currently selected ones when clicked in the view.
  • Create a halo button for ungrouping if a group of elements is selected in the view - it should ungroup the elements.
    • Ungrouping should be done in reverse order of grouping. If a group is firstly is constructed of two groups, ungrouping should divide the elements to those groups used in the beginning. This means that ungrouping is not dividing the group to separate elements but to previous state of the elements(grouped or separate).
  • Z-order issues could be postponed for the "main" revision.
  • Provide short cuts and menu buttons for manipulation(create, edit, break) over the groups.

Task result

  • code

Implementation idea

  • Get into the current group model, get familiar with its negatives.
  • Watch this video, see the new design ideas for the grouping.
  • Use the current tests written for grouping.
  • In order to make a group persistable, it would be best to be implemented as a resource.
    • It may contain different properties that are common for the group like background(for background supported elements), border color, border size etc.
    • It may have a size and position. This is the bounding rectangle for the elements in the group.


How to demo

  • Open sophie2.
  • Select several elements by clicking them.
  • Click the group elements halo button.
  • Click elsewhere.
  • Clicking on an element from the group should select all the elements.
  • Save the book.
  • Open the book.
  • When clicking on a element that is part of the previously created group the whole group should be selected.
  • Ungroup the group.
  • Clicking on an element should select only that element.


  • Make implementation ResourcePageElement of the PageElement interface, which extends Resource.
  • Define an interface ElementContainer which contains ResourcePageElements. It will have the following methods:
    • ElementContainer getParentContainer(), providing the parent ElementContainer of it.
    • RwListProp<ResourceRef> elements(), all the ResourcePageElements this container owns. They can be other groups, frames, etc.
  • The Page will implement ElementContainer - it will have elements. Page will not have a parent container. Rename the property Prop<ResourceRef>frames() to Prop<ResourceRef>elements(), refactor the logic that uses the property first.
  • The Frame will implement ResourcePageElement - it will have parent ElementContainer.
  • Define class Group which will handle grouping, ungrouping and group navigation. It will implement the ElementContainer and ResourcePageElement. Its parent container will be the same as getParent(). The Group class should also have:
    • public Group createGroup(List<ResourcePageElement> elements) - which will create a Group from given elements. They should be first children of the given one.
    • public static void deleteGroup(Group group) - which will ungroup a previously created group.
  • Create class GroupView, which has a corresponding sceneElement. The sceneElement will consist of composition of the contained elements.
  • Clicking on either frame of a group should select all the group. For this, create a property currentGroup() in the PageWorkArea and watch for it in the PageElementLogic.
  • In the PageElementLogic, when selecting a frame, we should actually select the first group below the current one, which contains this element(if such exists).
  • The actual grouping control will be done through the HaloButtons created for this.
    • Selected elements will be able to be grouped.
    • Selected group will be able to be ungrouped.
    • Both halo buttons will appear on selecting more than one frame.
  • Group navigation must be present:
    • Navigating one level up.
    • Going down one level.
  • For the first revision, the only group action available will be "Move".

Test are already written, they will need to be refactored during the implementation phase.


Not done for this revision:

  • addFrame adds a frame directly to the page, not to the currently selected group.
  • Methods requiring resource copy (createGroup, deleteGroup) need to be refactored since template copying is not correct. There are currently 2 helper methods, which must be removed after refactoring of the templates.
  • Copying each resource in order to change its parent and calling fixTemplate() method is very slow. Since the children of a group are also templated, we need to call these methods recursively, which makes the whole process too slow. Furthermore, testing this structure is not an easy task, since our orignal elements are deleted - our new group practically does not contain the passed elements. So, copying resources could be error prone. However, for now, this is the only way to change a resource's parent.
  • Making a copied resource requires deleting the old one. This resource functionality is currently almost not working, since deleting a resource with children causes too much exceptions(delete a page from the resource palette, for example). Deep deleting of a resource is also not implemented. Implementing such method in Group is not enough, since we only know that a group contains resources. So, the side effect of this is that when we create/delete groups, it is possible to see multiplying frames in the AllResourcesPalette.
  • Group move does not work correctly with lock-positioned frames - it moves them.
  • It is currently hard to indicate the current group - this should be fixed the next revision.


[3206], [3207], [3208], [3209], [3210], [3211], [3212], [3213], [3214], [3215], [3216], [3218], [3219], [3220].

Merged to the trunk in [3487].


There was an issue with group copying: the appropriate method in ResourceSpace copies all subresources of a resource and the group copy method does the same. This problem was resolved by removing the copying features from the Group class. But this way, the elements() of a group are re-created each time a group is copied. So, the zOrder inside a group is not expected to work properly at this time.
Another issue is that because of the Page model is changed, books persisted until now cannot be open. In their xml files for the pages, "frame" must be replaced with "element".
New changeset: [3354]



Known bugs :

  • When you have two frames in a group, you enter the group and delete one of them, the group stays and it's visible in the AllResourcePalette. Fix it for the next revision. -- meddle
  • Grouped frames are not persisted with "export as.. pdf" function. --kyli
  • Page's frames() property must be reconsidered - it is actually obsolete and maybe should not be used. Think about refactoring during the next revision. --kyli
  • Think about every PageElement having location relative to its parent element, not to the page. This could solve issues about templating and group manipulation. --kyli