resource-change – Add ability to change resources of existing frames

[deyan]

Changing a resource should be possible. The behavior should be as you deleted the frame and created a new one (but styling, size, resource should not be changed). If possible, make other options such as controls visibility to be preserved

[deni]

• Add a new operation in ResourceImportLogic - ON_DROP_RESOURCE_OVER_FRAME_CONTENT. If possible, it changes the main resource of the frame to the resource that was dropped.
  • The main idea is to set the following two keys:
    • ResourceFrame.KEY_MAIN_RESOURCE
    • ResourceR4.KEY_KIND (because only image frames can show images, for example, otherwise there will be a lot of problems with the views)
  • The new frame kind can be found using ResourceImportManagers in the following way:

    ResourceImportProvider provider = SimpleResourceImportProvider.getProvider(
    	new ResourceKindMatcher(droppedResKind));
    final String newFrameKind = provider.getImportManager().getFrameKind();
    

• In LibraryTabLogic do not handle the event if the book view is in preview mode, just return false. Handling the event in ON_PAGE_TEMPLATE_DND_IMPORT, for example, causes troubles when trying to change the content of an embedded book frame.

• Remove the StringData from all ResourceDataProviders except HotText. Otherwise when dropping a resource over the content of a text frame, the resource name will be inserted.

• Make sure that FrameViewLogic.ON_DROP_OVER_PADDING operation handles the event (and changes the background) only if image data was dropped over the padding of a frame.
  • Add a simple check whether the ImmPoint event parameter is outside the frame content.
  • The point parameter is currently wrong because of SceneInteractionLogic.SCENE_DND_OPERATION. In order to convert scene coordinates to the element's space, we should use the inverse matrix of the matrix we obtain by calling SceneHelper.getElementToSceneTransform(Scene, SceneElement)

[meddle]

It's OK but two things:

• First use the logic of the keys when getting values from the model. Not frameAccess.open(relRef, null).getRaw(ResourceR4.KEY_KIND);. The right use here is something like ResourceR4.KEY_KIND.get(frameAccess.open(relRef, null));. If in the future the kind become templated key, the first will not take in mind the template.
• I don't like how big the ResourceImportLogic is getting... You can create for example another logic for the DND imports - DNDResourceImportLogic.
• You should add the design changes you made about the chained frames.
• That thing about the StringData, you must give the implementation before the review for hard testing...

[deni]

• In AppViewUtil.getView(VisualElement, ResourceAccess, Class<T>) ensure that no ClassCastExceptions will be thrown. Instead, when the cached result is not of the required type, return null.

• Split the ELEMENT_DELETED event into two new events:
  • DELETING_ELEMENT that is fired before actually deleting an element, so that if the views that depend on the item that will be deleted are notified
  • DELETE_ELEMENT - the logics that handle this event will actually delete the element. It is their responsibility to fire DELETING_ELEMENT beforehand.
  • In ON_DROP_RESOURCE_OVER_FRAME_CONTENT before changing the main resource fire DELETING_ELEMENT event with parameter the frame. This will ensure that head frames will be removed from the chain, the timer of browser frames will be stopped and so on.

• Source code: [8653]

[meddle]

Merged to the trunk at [8659].

You left some commented code, some System.outs, you didn't comment on my note about the big resource import logic...
There was an undocumented method... The code was not a implementation phase code for review...

3p

[meddle]

Closing all the tickets before M Y1