Hide Delete Button in Editbar depending on Parsys

Question

I have a CQ5 component with a delete button in the author mode's edit view. Now there are two possible ways to include this component in a page:

1. Statically via a cq:include tag
2. Dynamically via a parsys component

How do I configure CQ5.5 to only show the delete button in the editbar when the component is shown within a parsys. When the component is statically included via a cq:include the delete button should not be shown as it's not possible to delete the component from the page in that case.

Any ideas?

I only found the following CQ5 documentation how to generally remove the delete button from the editbar: http://dev.day.com/docs/en/cq/5-5/developing/components/edit_config.html#cq:actions

Also the delete button is correctly shown and hidden if I do NOT use the layout editbar :/

Aerography

Hi Markus I do not have exact and right answer to this, but what I think is you might have to somehow override the cq:editConfig, here is a blog andypowell.org/category/cq5 which shows how to override the edit config as such to display the dialog box when the component is displayed on the page. Hope this helps and give some direction. – Berkey

Answer 1

There is no OOTB way to dynamically configure the editConfig depending on context, so the easiest solution would be to create a new component extending the original one which would override only the cq:editConfig node. So you end up with two flavours of the same component: one for the parsys, and another for static include, but without any code duplication, since the other one would be a 'shallow' override.

Copy the original component to a new one, remove all the files in the new component except .content.xml and _cq_editConfig.xml in which you need to remove DELETE from cq:actions.

For example, if your original component has a resourceType of /apps/mysite/myoriginalteaser, then in the new component you should set in .content.xml:

.content.xml:

<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0"
    jcr:primaryType="cq:Component"
    sling:resourceSuperType="mysite/myoriginalteaser"/>
                             ^^^^^^^^^^^^^^^^^^^^^^^

_cq_editConfig.xml:

<jcr:root xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0"
    jcr:primaryType="cq:EditConfig"
    cq:dialogMode="floating"
    cq:actions="[text:My Fixed Teaser,-,EDIT]"
    cq:layout="editbar">

NB: If you already have production content with the original resource type, then you will need to migrate the resource type for the component with the 'new' behaviour. This could be done (1) manually in CRXDELite, (2) using the Bulk Editor tool, or (3) via the Resource Type Updater from the ACS AEM Tools.

Nawrocki

Answer 2

You may be able to use the ComponentContext.BYPASS_COMPONENT_HANDLING_ON_INCLUDE_ATTRIBUTE to accomplish this. Check out Set a CQ5 component to editable or not editable. You'd have to set it before the static include, then remove it just afterward so that the delete button would be usable in the parsys. But then you'd lose the edit button as well, which may not be desirable.

Another option is to create a 2nd component that uses the 1st one as its super type (sling:resourceSuperType). All functionality (dialog, JSP) would be inherited except for the edit config. You'd change the edit config options for the 2nd component and use it for the static include, while the 1st component would remain available in the Sidekick for use in the parsys.

Snowy

Answer 3

Shawn's solution removes the editbar completely (although in a crazy hackish way), but many of us still want to edit the component without a delete option.

It has become a very common theme in CQ that things are simply not possible, so we spend so much time finding crazy hacks and workarounds until we find the "least horrible solution we can find". Many configurations are defined in a very bad way. This is one of them, and is considered one of AEM's most powerful features (the edit bar). The other flagship feature (parsys) is broken in many ways also, due to the fact that they built the entire /etc/designs just for the sake of defining what type of components can live in a parsys, without providing any clean way to accomplish nested parsys, and forcing container types to be statically defined. Honestly I could spend hours talking about all the crazy ways CQ implemented things, but I've already said too much.

My solution: copy the component, paste it, change the name slightly, remove the delete option from the editbar. Messy as heck? Yes. They will get out of sync, no matter how clearly you communicate and document the code. But you gotta ask yourself, is it worse than writing your own custom sling component filter? Um... no, it's not :)

Cairns