Sunday, 27 July 2014

Adobe AEM/CQ - extjs multifield + compositefield with multiple textfields

Suppose we have a form (name: 'formName') with a multifield as follow:

var multifield = new CQ.form.Multifield {
    fieldLabel : 'Multiple: ',
    orderable : false,
    name : 'multifieldExample',
    fieldConfig : {
        xtype : 'compositefield',
        layout: 'form',
        items : [{
          xtype: 'textfield',
          fieldLabel: 'field1: '
        }, {
          xtype: 'textfield',
          fieldLabel: 'field2: '
        }]
    },
    width: 650
}

Here is how we can retrieve the value of the first instance of field2:

formName.getForm().findField('multifieldExample').findByType('compositefield')[0].items.itemAt[1].getValue();

We can retrieve the items under a component via .items.itemAt[i]


Monday, 16 June 2014

Adobe AEM/CQ - ACS dispatcher flush rules

We use this to flush associate paths for a given node.

E.g.
When an activation occurs for path /content/abc, we can configure with this ACS package to also flushes the dispatcher cache for path /content/xyz.

Read more about this add-on here:


Configurations:

/system/console --> ACS dispatcher flush rules










/etc/replication/agents.publish.html






Tuesday, 10 June 2014

Adobe AEM/CQ - bulk editing

http://localhost:4502/etc/importers/bulkeditor.html

This can be use to bulk edit multiple nodes that have been created in the CQ repository.

Thursday, 10 April 2014

Adobe AEM/CQ - Repository Inconsistency

http://helpx.adobe.com/experience-manager/kb/RepositoryInconsistency.html

My current project is running into some IndexNotFound exceptions which is caused by repository being inconsistent.

I ran the ConsistencyCheck as per the article in the link above but it came back with 699 unrepairable nodes.

I used the query-builder to search for one of the complaining missing node and it turns out that the culprit node(s) were from CQ itself:
1. Access http://[host]:4502/libs/cq/search/content/querydebug.html
2. Search with:
path=/content 
uuid=[complaining-missing-node]
Results:
  • /content/catalogs
  • /content/catalogs/jcr:content
  • /content/campaigns
  • /content/campaigns/jcr:content
  • /content/dam
  • /content/dam/rep:policy
  • /content/dam/rep:policy/allow
  • /content/dam/jcr:content
  • /content/dam/mac
  • /content/dam/hierarchy

So we decided to re-index the repository:
1. Stop the CQ instance
2. Rename the index directory in
- crx-quickstart/repository/repository/index
- crx-quickstart/repository/workspaces/crx.default/index
3. Start the CQ instance

The repository inconsistent related errors were gone initially, but it returned to haunt us again. So far this haven't impact any functionality or performance, but it is still a risk that it might become worst.

We are leaving it for now as we have ran out of ideas, I'll keep myself posted here.

Update 1:
Change of events, apparently the way I search the uuid in querybuilder is incorrect. The correct query to be use should be:
path=/content
property=jcr:uuid
property.value=[complaining-missing-node]

And it returns nothing from that query...

Battle continue...