Chuyển đến nội dung chính

[COMPONENT] Maintaining Visibility of CQ Editables (Overwrite Editbar)

Maintaining Visibility of CQ Editables


Content elements such as multi-tab content controls and collapsible content sections are prevalent on modern websites.  In an Adobe CQ5 authoring environment, a common business requirement is to allow the authoring of such elements in place.  Such requirements necessitate the elements of the CQ authoring environment (edit bars, drop areas for paragraph systems, etc) to be hidden and shown as the content which they represent is hidden and shown.
In building a CQ component which requires the hiding and showing of authorable content (such as the multi-tab content control component seen in figures 1 and 2) you may notice the editables associated with the content being hidden / shown do not follow the content's lead in terms of visibility.  While your experience may be slightly different the result of hiding authorable content typically is all editables associated with the content jumping to position 0, 0 since they no longer have anything to anchor to on the page (fig 1). Further, editables associated with content which is hidden on page load (for instance, content in tabs other than the first tab of your tab component), may not be properly initialized.
fig 1 - notice the editables floating in the top left.  These are the drop areas for hidden paragraph systems as well as the edit bar from the first content tab. Also notice, in comparison to fig 2, EditBars are missing under the tabs, because they were not initialized fully.

To alleviate this, you can tap into the observe functionality which is tied to common editables such as the CQ.wcm.EditBar and the CQ.wcm.EditRollover.  CQ uses the editable's observation mechanisms to attempt to keep the authoring environment up to date such that it appropriately reflects the underlying content.  The observe method for editables registered as observable is run regularly (based on the frequency tied to the observation) and performs functions such as updating the position of an editable. Using CQ.Ext.override and self-executing functions, you can override an editable's observe member, augmenting its original functionality with observation of and reaction to the visibility of the underlying content. I've provided some sample code to this effect below as a starting point for your viewing pleasure.
fig 2 - nice and clean after applying visibility observation

How the visibility of the underlying content is determined will be based on what mechanism you are utilizing to actually hide / show the content in the first place.  In the code below I am using jQuery's .is( ":visible" ) logic which, for the project this code was developed on, made sense since we were already using jQuery hide() and show() calls to perform the hiding and showing of content.

Content elements such as multi-tab content controls and collapsible content sections are prevalent on modern websites.  In an Adobe CQ5 authoring environment, a common business requirement is to allow the authoring of such elements in place.  Such requirements necessitate the elements of the CQ authoring environment (edit bars, drop areas for paragraph systems, etc) to be hidden and shown as the content which they represent is hidden and shown.
In building a CQ component which requires the hiding and showing of authorable content (such as the multi-tab content control component seen in figures 1 and 2) you may notice the editables associated with the content being hidden / shown do not follow the content's lead in terms of visibility.  While your experience may be slightly different the result of hiding authorable content typically is all editables associated with the content jumping to position 0, 0 since they no longer have anything to anchor to on the page (fig 1). Further, editables associated with content which is hidden on page load (for instance, content in tabs other than the first tab of your tab component), may not be properly initialized.
fig 1 - notice the editables floating in the top left.  These are the drop areas for hidden paragraph systems as well as the edit bar from the first content tab. Also notice, in comparison to fig 2, EditBars are missing under the tabs, because they were not initialized fully.
To alleviate this, you can tap into the observe functionality which is tied to common editables such as the CQ.wcm.EditBar and the CQ.wcm.EditRollover.  CQ uses the editable's observation mechanisms to attempt to keep the authoring environment up to date such that it appropriately reflects the underlying content.  The observe method for editables registered as observable is run regularly (based on the frequency tied to the observation) and performs functions such as updating the position of an editable. Using CQ.Ext.override and self-executing functions, you can override an editable's observe member, augmenting its original functionality with observation of and reaction to the visibility of the underlying content. I've provided some sample code to this effect below as a starting point for your viewing pleasure.
fig 2 - nice and clean after applying visibility observation
How the visibility of the underlying content is determined will be based on what mechanism you are utilizing to actually hide / show the content in the first place.  In the code below I am using jQuery's .is( ":visible" ) logic which, for the project this code was developed on, made sense since we were already using jQuery hide() and show() calls to perform the hiding and showing of content.

/*
* Override the observe method of CQ.wcm.EditBar adding
* an observeWidth (implemented in 5.5) and
* observe visibility to support hiding and
* showing of editables
*/
CQ.Ext.override(
 CQ.wcm.EditBar,
 {
   /**
    * Call the originally defined observe function for
    * the EditBar
    * along with visibility and width observations
    * @private
    */
   observe : function( originalFunction ) {
     return function() {
       this.observeVisibility();
                        
       originalFunction.apply( this );
                        
       this.observeWidth();
                        
     };
   }( CQ.wcm.EditBar.prototype.observe ),
              
   /**
    * Note - observeWidth is unnecessary if you are
    * running
    * CQ5.5+
    */
   observeWidth : function() {
     var barWidth = this.el.getWidth();
     var elementWidth = this.element.getWidth();
     if (elementWidth != 0 && barWidth != elementWidth) {
       this.el.setStyle("width", elementWidth + "px");
     }
   },
            
   /**
    * Base the visibility of the EditBar on the
    * visibility of the
    * element which the EditBar represents editing upon
    */
   observeVisibility : function() {
     if (
       this.isVisible() &&
       ( ! jQuery( this.element.dom ).is( ":visible" ) )
      ) {
       this.hide();
     }
     else if (
       ( ! this.isVisible() ) &&
       jQuery( this.element.dom ).is( ":visible" ) ) {
       this.show();
     }
   }
 }
);
/*
* Override the observe method of CQ.wcm.EditRollover
* adding an observe visibility to support hiding and
* showing of editables
*/
CQ.Ext.override(
 CQ.wcm.EditRollover,
 {
   /**
    * Call the originally defined observe function
    * for the EditRollover and then perform the
    * visibility observation
    * @private
    */
   observe : function( originalFunction ) {
     return function() {
       this.observeVisibility();
                        
       originalFunction.apply( this );
                        
     };
   }( CQ.wcm.EditRollover.prototype.observe ),
              
            
   /**
    * Base the visibility of the EditRollover on
    * the visibility of the element which the
    * EditRollover represents editing upon
    */
   observeVisibility : function() {
     if (
       ( ! this.hidden && ! this.elementHidden ) &&
       ( ! jQuery( this.element.dom ).is( ":visible" ) )
      ) {
       this.hide();
     }
     else if (
       ( this.hidden ) &&
       jQuery( this.element.dom ).is( ":visible" ) ) {
       this.show();
     }
   }
 }
);

By Paul Michelotti

Nhận xét

Bài đăng phổ biến từ blog này

How to add a new supported language in CQ / WEM (Translator in CQ)

Use case:  You want to add new language to CQ Change display language options in translator grid Change language name and default countries  Solution: You can access translator UI in CQ with following URL http://<HOST>:<PORT>/libs/cq/i18n/translator.html Create new language location for Dictionary Go to CRXDE lite (or your favorite JCR browser) and add this structure (assuming /apps/myapp/i18n as a typical location for custom apps): /apps/myapp/i18n [sling:Folder]     - de [nt:unstructured]         + jcr:mixinTypes = [mix:language]         + jcr:language = de     - fr [nt:unstructured]         + jcr:mixinTypes = [mix:language]         + jcr:language = fr Then reload the translator and the path /apps/ myapp /i18n should show up in the drop-down at the top. Note: the translator will only save translations for languages that are actually present underneath the path (e.g. /apps/myapp/i18n), others will be skipped. Then on jsp pa

Login / Logout on a Publish instance and Closed User Group (CUG)

In CQ5 there is the login logout could be configured using a Closed User Group. Closed User Groups (CUGs) are used to limit access to specific pages that reside within a published internet site. Such pages require the assigned members to login and provide security credentials. http://dev.day.com/docs/en/cq/5-4/howto/create_apply_cug.html The logout using /libs/cq/core/content/login.logout.html always gets redirected to the geometrixx site   http://localhost:4503/content/geometrixx-outdoors/en.html By configuring the Default login page  under the osgi configuration for com.day.cq.auth.impl.LoginSelectorHandler to be – /content/mysite/en/login But still after logout the page goes to the geometrixx site. IIRC, the redirect first goes to to / which then goes through the standard, somewhat complex handling of the root with multiple redirects: 1) / has a resource type of sling:redirect and redirects to /index.html 2) /index.html is handled by the RootMappingServlet [0] which h

[PERFORMANCE] Adobe WEM/CQ performance tuning

Adobe WEM/CQ performance tuning Contents Caching-related configurations CRX Bundle cache CRX Search index handler (Lucene) cache Tar PM index cache Scalability Maintenance Optimizing Tar Files (for Tar Persistence Manager) Data Store Garbage Collection Main documentation you should consult first: http://dev.day.com/docs/en/cq/current/deploying/performance.html http://dev.day.com/content/kb/home/cq5/CQ5Troubleshooting/performancetuningtips.html Caching-related configurations CRX Bundle cache CRX caches bundles, consisting of a node with all its properties. This is used by all bundle-based Persistence Managers. The default size of BundleCache is 8 MB. If this is too small it can cause an excessive number of read-accesses to the underlying persistence layer. Set the bundleCacheSize to something larger than the default. See more here: http://dev.day.com/docs/en/cq/current/deploying/performance.html#CRX%20Bundle%20Cache CRX Search index handler (Lucene