As an enhancement to the dockLocationsButton feature:
Some of our panels do some work to set up how the panel works.
notice how some side Panels change the tab color to Gray when there's unsaved edits
notice how one project's applications panels change the tab title to add color icons and data counts
That customization and event handling gets lost when the panel is removed / added back to the scaffold.
There's probably several ways to address this... but the one I think provides the most flexibility (assuming the framework allows it) is the following:
Add a config option to the configuration like the following:
dockLocationButton: true,
handleDockLocationChange: ({scaffold, location}) => { /* should handle changing the panel location */ },
Alternately, but maybe a bit more complex than the above and not necessary we could separate out the delegate methods for ad/remove:
dockLocationButton: true,
handleAddPanelOnDockLocationChange: ({scaffold}) => { /* delegated add panel action */ },
handleRemovePanelOnDockLocationChange: ({scaffold}) => { /* delegated remove panel action */ },
The handler functions would be optional – and when not present, the scaffold would just do the remove/add like it already does in this PR.
But when present, the scaffold would NOT do any remove or add... but would instead call this functions and expect the developer implemented something appropriate to handle each one.
Reference: 11868
As an enhancement to the
dockLocationsButtonfeature:Some of our panels do some work to set up how the panel works.
notice how some side Panels change the tab color to Gray when there's unsaved edits
notice how one project's applications panels change the tab title to add color icons and data counts
That customization and event handling gets lost when the panel is removed / added back to the scaffold.
There's probably several ways to address this... but the one I think provides the most flexibility (assuming the framework allows it) is the following:
Add a config option to the configuration like the following:
Alternately, but maybe a bit more complex than the above and not necessary we could separate out the delegate methods for ad/remove:
The handler functions would be optional – and when not present, the scaffold would just do the remove/add like it already does in this PR.
But when present, the scaffold would NOT do any remove or add... but would instead call this functions and expect the developer implemented something appropriate to handle each one.
Reference: 11868