Hybrid CDT, Cloning, and Click™ Portal 5.8.x

The previous post of how properly handle Hybrid CDTs during the clone process described the implementation targeted at Click™ Portal 5.6.x and 5.7.x. Click™ Portal 5.8 introduced a new implementation of the clone capability which requires a different approach to support Hybrid CDTs.

If you’re unfamiliar with what a Hybrid CDT is, I encourage you to read the earlier posts:
Implementing a “Hybrid CDT”
Implementing a Hybrid CDT – Update
Hybrid CDT's and Cloning

By default, Selection CDT entities are cloned by reference, meaning that the actual entities are not duplicated. When a Selection CDT is used pas part of a Hybrid CDT pair, this default will not work. The entities themselves need to be cloned.

For Click Portal 5.8 and later, there are two ways to do this.

Option 1: Override default behavior at time of clone

In the code that kicks off the clone, add an additional call for each Selection CDT involved in a Hybrid CDT pair. The line looks like this:

   1: // replace INTERNAL_ETYPE_NAME with the appropriate type name, One call per EType.

   2: ec.customizeHandling(“INTERNAL_ETYPE_NAME”, “cloneEntity”); 

Note: ec is an instance of the EntityCloner entity that you are already using to initiate the clone. Your variable name may be different.

Option 2: Override the default method on the Entity Type

The clone process, by default will call a method on the EntityType of the entity being processed, to determine how clone should handle it. For Custom Data Types, On the Selection CDT EType, override the inherited method named “overrideEntityClonerRefHandling()” to return “cloneEntity”.  This is a per-type method on your Selection CDT. The method would look like this:

   1: function overrideEntityClonerRefHandling()

   2: {

   3:     try {

   4:         return "cloneEntity";

   5:     } catch(e) {

   6:         wom.log("EXCEPTION _CDT_TYPE_NAME.overrideEntityClonerRefHandling: " e.description);

   7:         throw(e);

   8:     }

   9: }

  10:     

What’s nice about this is that, unlike the changes required prior to Click™ Portal 5.8, these changes do not require a base product change which means that you can avoid having to deal with this every time the site is upgraded.

If you have already implement the earlier base change and are planning to upgrade to 5.8.x, it’s critical that either of the above options be implemented as part of your upgrade. If this step is skipped, the result is that clone operations will cause Selection CDT entities used in Hybrid CDT pairs to be referenced by more than one project. This will result in the change of the entity by one project to reflect in the other projects. This violates the intent of Hybrid CDTs, causes arguable data corruption, and is difficult to correct after the fact. if you find yourself in this situation, contact your Huron Project Manager right away so we can help.

Cheers!