2014-04-30 7 views
6

Ho un componente CQ5 con un pulsante di cancellazione nella vista di modifica della modalità autore. Ora ci sono due possibili modi per includere questo componente in una pagina:Nascondi il pulsante Elimina nella barra di modifica in base a Parsys

  1. staticamente tramite una cq: comprendono tag
  2. dinamicamente tramite un componente PARSYS

Come si configura CQ5.5 solo mostra il pulsante Elimina nella barra di modifica quando il componente è mostrato all'interno di un parsys. Quando il componente è staticamente incluso tramite un cq: includere il pulsante Elimina non dovrebbe essere mostrato in quanto non è possibile eliminare il componente dalla pagina in quel caso.

Qualche idea?

ho trovato solo la seguente documentazione CQ5 come rimuovere generalmente il tasto di cancellazione dal editbar: http://dev.day.com/docs/en/cq/5-5/developing/components/edit_config.html#cq:actions

Anche il tasto di cancellazione è correttamente mostrato e nascosto se non si utilizza l'editbar di layout:/

+0

Ciao Markus Non ho una risposta esatta e giusta a questo, ma quello che penso è che potresti avere in qualche modo scavalcare il cq: editConfig, ecco un blog http://andypowell.org/category/cq5/ che mostra come sovrascrivere la modifica di configurazione come tale per visualizzare la finestra di dialogo quando il componente viene visualizzato sulla pagina. Spero che questo aiuti e dare una direzione. –

risposta

0

Potrebbe essere possibile utilizzare ComponentContext.BYPASS_COMPONENT_HANDLING_ON_INCLUDE_ATTRIBUTE per ottenere ciò. Controlla Set a CQ5 component to editable or not editable. Dovresti impostarlo prima dell'elettricità statica, quindi rimuoverlo subito dopo in modo che il pulsante di eliminazione sia utilizzabile nelle parsys. Ma poi si perderebbe anche il pulsante di modifica, che potrebbe non essere desiderabile.

Un'altra opzione è creare un secondo componente che utilizza il primo come supertipo (sling: resourceSuperType). Tutte le funzionalità (finestra di dialogo, JSP) saranno ereditate tranne che per la modifica di configurazione. Dovresti cambiare le opzioni di modifica di modifica per il 2 ° componente e usarlo per l'inclusione statica, mentre il 1 ° componente rimarrebbe disponibile nel Sidekick per l'uso nel parsys.

0

La soluzione di Shawn rimuove completamente la barra di modifica (anche se in un modo folle di hacker), ma molti di noi ancora desiderano modificare il componente senza un'opzione di eliminazione.

È diventato un tema molto comune in CQ che le cose non sono semplicemente possibili, quindi passiamo così tanto tempo a trovare gli hack e le soluzioni alternative folle finché non troviamo la "soluzione meno orribile che possiamo trovare". Molte configurazioni sono definite in modo pessimo. Questo è uno di questi, ed è considerato una delle più potenti funzionalità di AEM (la barra di modifica). Anche l'altra caratteristica di punta (parsys) è rotta in molti modi, dato che hanno costruito l'intero/etc/designs solo per definire quale tipo di componenti possono vivere in un parsys, senza fornire alcun modo pulito per eseguire nested parsys e forzare i tipi di contenitore a essere definiti staticamente. Onestamente potrei passare ore a parlare di tutti i pazzi modi in cui CQ ha implementato le cose, ma ho già detto troppo.

La mia soluzione: copia il componente, incollalo, cambia leggermente nome, rimuovi l'opzione di eliminazione dalla barra di modifica. Disordinato come diamine? Sì. Verranno fuori sincrono, a prescindere da quanto chiaramente comunichi e documenti il ​​codice. Ma devi chiederti, è peggio di writing your own custom sling component filter? Um ... no, non lo è :)

3

Non esiste un modo OOTB per configurare dinamicamente editConfig in base al contesto, quindi la soluzione più semplice sarebbe quella di creare un nuovo componente estendendone quello originale che sovrascriverebbe solo il nodo cq:editConfig . Così si finisce con due sapori dello stesso componente: uno per il parsys, e un altro per l'inclusione statica, ma senza alcuna duplicazione del codice, poiché l'altro sarebbe un override 'superficiale'.

Copiare il componente originale ad uno nuovo, rimuovere tutti i file nel nuovo componente, tranne .content.xml e _cq_editConfig.xml in cui è necessario rimuovere DELETE da cq:actions.

Ad esempio, se il componente originale ha un resourceType di /apps/mysite/myoriginalteaser, poi nel nuovo componente è necessario impostare 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: Se si dispone già di contenuti di produzione con la tipo di risorsa originale, quindi sarà necessario migrare il tipo di risorsa per il componente con il comportamento 'nuovo'. È possibile eseguire (1) manualmente in CRXDELite, (2) utilizzando lo strumento Bulk Editor o (3) tramite Resource Type Updater da ACS AEM Tools.