AEMaaC automatically open edit dialog of component when author places the component on a page, also automatically deleted placed component when author closes/cancels the edit dialog instead of saving changes

[DennisAtDept]

Hi all,

For one of our clients there is a criteria where they want to force the content author to fill in all required fields when adding a new component to page.
Currently when adding a component the authoring dialog does not open automatically, we want it to open automatically when a component is placed on a page.

a second criteria is that when the author decides do exit the edit dialog without saving, the newly added component should be removed because it was not configured according to the business rules the client has set up.

The client wants to avoid having empty component cluttering pages on the authoring environment and encourage the authors to always fill in the components properly.


Can we achieve this by adding an additional clientlib?
If so, do we have an example?

Thank you in advance!

Kind regards,

Dennis

[arunpatidar · Accepted solution]

Hi @DennisAtDept 

You can try adding script using EditConfig

http://www.sgaemsolutions.com/2019/01/ootbcustom-cqlisteners-in-cqeditconfig.html

you can use doConfigure and doDelete methods from Granite.author.edit.ToolbarActions

The below clientlibs contains the definition of above functions
http://localhost:4502/libs/cq/gui/components/authoring/editors/clientlibs/core.lc-xxxxx-lc.min.js

[DennisAtDept]

Hi Arunpatidar,

Sorry for the late reply, still experimenting with this.
Regarding the opening of the dialog we opted in going to create our own instance of the

Granite.author.edit.Dialog

object which allowed us to set both the onSuccess and onClose listeners.

as onSuccess is fired before onClose we could determine wether the user saved changed prior before the dialog was closed

We used

Granite.author.DialogFrame.openDialog(dialog)

To open the actual dialog.

Again, thanks for pointing towards Granite.author as it contains everything needed.



On a separate note: We also noticed the google chrome tabs where crashing when having nested components set to REFRESH_PAGE, we mitigated this problem by creating our own

refreshContentFrame

 function which takes the dom from the editable and finds the window it's on.
Then it simply reloads that window which represents the contentIframe