Help with an odd (complex?) nested editor situation

Support
#1

So I have a normal editor, let’s call it main editor. main editor is like I said a normal editor of a fairly normal entity - an invoice. On main editor I have a button that when clicked opens, using screenBuilders.editor(...).editEntity(getEditedEntity())... , a screen (second editor) which (as the code shows) edits a portion of the same instance of the same entity that main editor is editing.

This is necessary because the fields that second editor is editing are only editable by a small subset of users (we use a Specific Permission to control this), and the edit flow of these fields is fairly controlled and a separate, modal dialog is needed.

This all works fine, except for when second editor returns, main editor does not “see” the changes that second editor made. Said changes are “there,” meaning, if one “Oks” on main editor and then goes back in from the browser, the changes show, but they need to show (and be accessible in code) right after second editor returns.

Now I have that working now, but I suspect the way I fixed it is a very bad kludge and there’s probably a better/more standard/more accepted way. What I’ve done is added an afterCloseListener to the screenBuilders.editor() call and in that listener, I:

        getScreenData().loadAll();
        Invoice invoice = dataManager.reload(getEditedEntity(), "invoice-edit-view");
        setEntityToEdit(invoice);
        invoiceDc.setItem(invoice);
        getScreenData().loadAll();
        log.info(">>>> Invoice {}, resp is {}", invoice.getNumber(), invoice.getResponsibility());

The duplicate gSD.loadAll()'s are just remnants of other attempts to fix the problem, and the logging is there so that I could see that second editor's changes are “visible” via code as well as on-screen.

Is there a better way to handle this case?

#2

Hi @jon.craig,

I don’t know if that is the case, but have you considered Input Dialogs for this second editor? If you prefer XML over programmatic creation, it is available as well (InputDialogFacet).

Are you reloading the entity using a different view in this second editor? I think you are updating a diffent object in this second screen (even though they are the same entity in Cuba), that’s why the changes are not available for the caller screen (and you need to implement the afterCloseListener).

Either way, I would try to use only one invoice-edit-view with all needed fields, and restrict access to these additional fields (the ones you are using the second editor) based on user roles permissions (entity attributes permissions).

Regards,
Peterson.

#3

I’ll have to have a look at that on Monday.

It does use a different view, yes.

It needs to be a separate (modal) screen as it would introduce too much clutter otherwise, and it’s a “directed” flow.

Is how I’m fixing the issue presently dangerous in any way? It seems to work fine - it just feels very kludgy.