Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Short answer: There's not really a <em>nice</em> and <em>easy</em> way to implement this.</p> <p>Long Answer: ...</p> <p>I would recommend creating a new xtype that adds these additional UIs. There's a lot of junk snippets on there to get it to work within the dialog XMLs however I would not recommend having JavaScript within your XMLs. I won't write the code for you but I'll provide the technical approach in which I hope would contribute to a better practice for dynamic components in the CQ field. <strong>This will require some intermediate JavaScript skills and familiarity of CQ's variant of ExtJS 3.4.</strong></p> <ol> <li><p>Write a new xtype in a new JavaScript file that contains both you're checkbox and dropdown. Its gonna have lines similar to the following: </p> <p><code> var MyCustomXtypeObject = CQ.Ext.extend(CQ.Ext.Panel, { ... </code> </p> <p><strong>and</strong></p> <p><code> CQ.Ext.reg('XTYPE_NAME', MyCustomXtypeObject); </code></p></li> <li><p>Add an <code>CQ.Ext.form.Checkbox</code> and <code>CQ.Ext.form.ComboBox</code> to <code>MyCustomXtypeObject</code>. When you add the configs to these items, you can have both widgets talk to each other by setting an <code>id</code> and using the <code>CQ.Ext.getCmp()</code> method. The first argument expects an ID and returns the instance of the widget. Set event listeners to both widgets so you can program your business logic needs. ExtJS 3.4 documents is going to be your friend throughout the whole process. Also take a look at CQ's existing custom xtypes for examples and setup. (Use CRX DE to find examples or package up <code>/libs</code>, download/unzip on your file system and use your IDE's search mechanism)</p></li> <li><p>Create a client library with the JS file included. Have the category set to <code>cq.widgets</code>. This is the easiest implementation to get it on the CQ JavaScript end but there are better practices for the sake of organization.</p></li> <li><p>On the dialog, add the xtype in with a <code>primaryType</code> as <code>cq:Panel</code> (since it's an Ext.Panel) E.g.: <code> &lt;myTestCmp jcr:primaryType="cq:Panel" xtype="XTYPE_NAME" /&gt; </code></p></li> <li><p>Test!</p></li> </ol> <p>I would recommend you prototype in CRX DE and incrementally prototype since the wrath of troubleshooting is going to make you give up with the constant build/deploy process.</p> <p>Also CQ follows Ext's 3.4 guide on forms, so if you need data to persist, its simply using generic <code>name</code> attribute on tags. The JSON coming in should provide it data (if not, you can pull the <code>Ext.data.Store</code> from the wrapper component instance and prepopulate the form elements manually).</p> <p><em>There's definitely a lot of domain knowledge needing the implement this way but it'll save headaches in the long run when your requirements change but your XML configs are limited. This method is unit testable and more performant than streaming it through configurations on limited methods. I have had a lot of experiences working with custom dialogs and this is the best way to implement custom CQ components (and is also the same way the CQ core devs implemented administration/foundation widgets)</em></p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload