template-editing-frame -- Frame template editing in separate window

[deyan]

Behavior:

• Double click should open the template for edit
• Resources palette should show the book resources
• Dragging a resource to the frame should change the frame content or background
• Dragging a resource out of the frame should do nothing
• Dragging a frame template over the frame should apply the template to this one
• Dragging a page template over the frame should do nothing
• The page that contains the frame should be with the size of the book
• The page should be white (or transparent) by default, however - page appearence halo should be present. The page appearence should be changeable, but these changes should be only for this view and should not be persisted
• Page preview palette should show only the first page. Note that the user may create an autochain and turn pages via links, that is OK as long as it works correctly, with no exceptions
• Following items should not be available
  • File
    • Save
    • Save as
    • Save as template
    • export
  • Edit
    • Cut (should work only for text)
    • Copy (should work only for text)
    • Paste (should work only for text)
  • Insert menu - should not be available at all
  • Book extras tab
  • Page structure palette
  • Page turning controls
  • Delete frame halo
  • Z-order halos
  • Add frame as template halo

[deni]

I find the explanation complete and clear.

[deni]

• Main idea:
  • On double click in the 'Frame Templates Palette' create a dummy page in the current book and add the frame template as the only sub-element of this page.
    • Do not copy the frame in the new page, just create an ActivationChannel for it. Otherwise changes done through the dummy page would affect the local copy and not the template itself.
  • Open the dummy page in a SinglePageBookDocView.
  • After closing the doc view, delete the page.

• Open frame templates in a separate window: same as opening page templates. All changes are in FrameTemplatesPalette.

• Delete the temporary page when the window is closed:
  • Add a new property in SinglePageBookDocView which indicates whether to delete the page on closing the window. Set it to false when editing a page template and to true when editing a frame template.
  • Add a new operation in DocumentsLogic - ON_CLOSE_SINGLE_PAGE_BOOK_DOC_VIEW that deletes the page if necessary. It should have a higher sort-key than ON_CLOSE and should not handle the event.

• Hide or disable some controls:
  • In BookViewOptions add a nested enum class BookEditLevel with options BOOK, PAGE and FRAME, indicating that the BookDocView should show controls for editing the whole book, a single page or a single frame, respectively.
    • Editing the whole book means that all halos and menu items should be visible and active.
    • Editing a single page means that controls editing book properties should be invisible or inactive. For example, page resize halo, save book menu items, book properties menu item, etc.
    • Editing a single frame means that controls editing book or page properties should be invisible or inactive. For example, insert menu, z-order halos, remove frame halo, etc.
  • Make all halos, menu items and some logics (for example, dnd pre-import) respect the book edit level.

• Unresolved issue: if the user saves a book while there is an open frame template editing window, the temporary page will be persisted.
  • A possible solution is to make ResourceModelPersister build a schema depending on the resource kind and search for an appropriate persister for every child of the persisted resource. Thus we will be able to persist different resources in different ways. In this case, a new resource class extending PageR4 (with a different kind) will be created, as well as a persister for it. The persister will actually do nothing, so the temporary page will not be persisted. However, changes to ResourceModelPersister should be discussed with (and probably implemented by) mira.

[meddle]

• The unresolved issue
  • In ResourceR4 put a new key of type boolean KEY_TRANSIENT.
  • While persisting
    • If this key has a value in the model and it is true in the very beggining of the persist method of the ResourceModelPersister return. This way the resource and its children will be not persisted. The children key persist itself calling the persister recursively so there shouldn't be problem.
  • When rendering resources in the ResourcePalette. The resources that are transient will be filtered.

• AutoActions
  • All new auto actions MUST be top level classes in the respective "actions" packets.
  • The messages are in public string constants!
  • You should declare at least five AutoActions of the current ones that you are going to took out into the "actions" packages at the design phase. You forgot that.
  • You forgot all of that already???

3.5p

[meddle]

And I forgot:

• Write a good ModelTestBase testing that the transient resources are not persisted!
• Try with deep hierarchy and plain one.
• It is important to pass this task. This thing should be written test driven.

[deni]

• Surrounded getting the children in ElementView.elementView() in a try-catch block, so that if an element cannot find its children, its view will have an empty list of sub-views.

[meddle]

Merged to the trunk at [9184].

• The way you use compare to decide stuff for the BookViewOptions BOOK/FRAME/PAGE enum is strange to me.
• We had some problems (server/text)
• This ticket fixes #2453.

4p

[meddle]

Closing all the tickets before M Y1