PAGE_ELEMENT_GROUPING_R0

[Astea]

wiki page: PAGE_ELEMENT_GROUPING_R0 - effort: 0.5d

[deyan]

For first revision the analysis is enough, but some things are missing - for example the z-order behavior and representation in the resources palette. Seems a little incomplete.

[deyan]

Batch update from file newimport.csv

[deyan]

The group is invalid, not deleting the custom field preserves the ticket from showing on the iteration page. Be careful.

[deyan]

Please add movement behavior for example, how a group will be rotated, etc. Which halos will be present for a group? what is the behavior of each control (specific, for example setting a border)

[kyli]

Starting!

[dido]

analysis 1h

[kyli]

Analysis is finished with the help of dido. Group behavior is still not added in the analysis, because after some discussions we decided, that for now it may be the same as multi-selection behavior, which is to be done in PAGE_ELEMENT_MULTI_MANIPULATION_R0.

[kyli]

done.

[kyli]

This design appeared to be weak. Some of the problems are:

• Renaming PageElement causes too much refactoring and is practically pointless. It is just another name for the same thing.
• Forcing PageElements in the groups to be also resources is bad - so a list of ResourceRefs is not enough for a container.
• createGroup should not be static - this way ot needs to be aware in the currentGroup, which is impossible.
• The currentGroup property should be reconsidered.

[kyli]

Starting design again..

[kyli]

• PageElement will not be renamed.
• An abstract class for PageElement Resources is included in the new design.
• Only deleteGroup will be static now.
• Some other minor things were fixed.

[pap]

• Generally ok but I'm not sure how stable this design will stay.
• You do not mention the user interaction well enough.
• I find the test almost useless. Please next time make sure you write higher quality unit tests when you design.
• Still I find this acceptable for a prototype, especially if it becomes peristable.

[kyli]

done?

[meddle]

The implementation works;

• Code review notes:
  • When you want to create/get ResourceRef to resource that you have and you have it's parent too, use Resource#getChildRef(Resource) method : this.page.addFrame(this.page.getChildRef(this.frame));
  • When you completely change a class remove the old authors names, and put only yours, for example the GroupTest.
  • Write AssertEquals(number, expression), no AssertTrue(number == expression).
  • The second parameter of the ResourceRef#get(Class<? extends Resource>, ProObject) is important when you know the locating object...
  • I think such a way to decide if to show a FrameView Halo is ugly : (pwa.selectedElementViews().get().size() == 1 && pwa.selectedElementViews().get(0) instanceof FrameView) We will have to think of a better way to do it... May be there will be "selectedFrameView" with will be null or something... The same applies for GroupViews and their halos.
  • Bad spacing, random spacing...
• 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.

There are problems deleting some of the resources that's why this bug is acceptable in my view...

3p (4h)

[deyan]

Batch update from file query-obsoleted.csv