DROOLS-5511: Focus test scenario grid when collection editor is saved…

[jomarko]

… and closed

For more details see https://issues.redhat.com/browse/DROOLS-5511

[jomarko]

The coverage needs to be provided, then draft will be transitioned to regular PR.

[jomarko]

Jenkins please retest this

[jomarko]

Jenkins do full downstream build

[yesamer]

@jomarko Not related to your changes, but it could be an improvement. Currently if you press Close button the launched actions are:

• destroyResources()
• gridLayer.batch()
• gridPanel.setFocus(true)
• collectionEditorDOMElement.stopEditingMode()

While, for the Save button, the actions are:

• flush() (with contains the destoyResource() logic)
• gridPanel.setFocus(true)

Not sure about the effect of calling gridLayer.batch(), but I suspect we should at least call collectionEditorDOMElement.stopEditingMode(); after Save Button is pressed. Most probably the current behavior could lead to a bug, if the state of editing mode is wrong. Can you please check it?

[jomarko]

The reason this is so tricky is the CollectionEditorSingletonDOMElementFacotry extends a class that was not designed for editors/popups with such complexity (buttons for saving, scrolling, switching two modes).

Other gird popups/editors are all saved by pressing TAB, ENTER (if it is not multiline text area) and canceled by ESC.

If we would able to redesign collection editor to not have any special buttons for saving, cancelling, then I think (not tried manually) we would simply remove this part of code and appformer framework would handle everything.

    protected void commonCloseHandling(final CollectionEditorDOMElement collectionEditorDOMElement) {
        destroyResources();
        gridLayer.batch();
        gridPanel.setFocus(true);
        collectionEditorDOMElement.stopEditingMode();
    }

    @Override
    public void registerHandlers(final CollectionViewImpl widget, final CollectionEditorDOMElement widgetDomElement) {
        widget.addCloseCompositeEventHandler(event -> commonCloseHandling(widgetDomElement));
        widget.addSaveEditorEventHandler(event -> {
            flush();
            gridPanel.setFocus(true);
        });
    }

However such rewriting is not much probable from my point of view, so back to your comment.

I think adding batch will not harm - documented here

collectionEditorDOMElement.stopEditingMode(); is not needed. The save handler call flush() what leads to invocation of CollectionEditorDOMElement.flush() where we already stop editing mode. It is expected, otherwise right now in business central we would see cell in edit mode even when collection editor is saved.

[yesamer]

@jomarko Thank you for your exhaustive comment.

[jomarko]

Jenkins do full downstream build

[jomarko]

Jenkins do full downstream build

[jomarko]

failed tests:

org.jbpm.process.workitem.mavenembedder.MavenEmbedderWorkitemHandlerTest.testCleanInstallSimpleProjecSynctWithCLOptions
org.jbpm.process.workitem.camel.karaf.itests.CamelWorkitemIntegrationTest.testSingleFileWithHeaders
org.jbpm.process.workitem.camel.karaf.itests.CamelWorkitemIntegrationTest.testSingleFileProcess
org.jbpm.process.workitem.mavenembedder.MavenEmbedderWorkitemHandlerTest.testCleanInstallSimpleProjectAsync

[jomarko]

Jenkins do full downstream build

[yesamer]

Jenkins do full downstream build

[jomarko]

Jenkins do full downstream build

[sonarcloud]

SonarCloud Quality Gate failed.

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

66.7% Coverage
0.0% Duplication

The version of Java (1.8.0_202) you have used to run this analysis is deprecated and we will stop accepting it from October 2020. Please update to at least Java 11.
Read more here

[jomarko]

Jenkins do full downstream build

[jomarko]

@jstastny-cz builds passed, PR is ready for your review when you have a moment.

[jomarko]

@kiegroup/gatekeepers please merge