¿Cuál es la diferencia entre _isEnabled y isEnabled en Anguila?

Question

He estado siguiendo las extensiones de la GUI y los ejemplos de notificaciones usan _isEnabled o isEnabled, sin el guión bajo. Ambos parecen funcionar para ampliar o posiblemente reemplazar la funcionalidad existente.

isEnabled

Por ejemplo, la clase base PowerTools (que no parece para "extender" funcionalidad existente) tiene:

PowerTools.BaseCommand.prototype.isEnabled = function(selection, pipeline) 
{ 
    var p = this.properties; 

    if (!p.initialized) 
    { 
     this.initialize(); 
    } 

    if (!this.isToolConfigured()) 
    { 
     return false; 
    } 

    if (this.isValidSelection) 
    { 
     return this.isValidSelection(selection, pipeline); 
    } 

    return true; 
}; 

Una herramienta puede utilizar esta clase de base y declarar. isValidSelection, por ejemplo:

PowerTools.Commands.CountItems.prototype.isValidSelection = 
             function (selection) { ... } 

_isEnabled

Veo que Anguila usa ._isEnabled para la funcionalidad existente (en la consola de Chrome en numerosos lugares del código). Por ejemplo, WhereUsed tiene:

Tridion.Cme.Commands.WhereUsed.prototype._isAvailable = 
         function WhereUsed$_isAvailable(selection) ... 

funciones privadas?

Estoy familiarizado con un subrayado anterior que es una convención de nomenclatura para variables privadas. ¿Las funciones _isEnabled y otras que comienzan con un guión bajo son "privadas"? Si es así, entonces

• ¿Cómo debemos extender (añadir funcionalidad adicional al código existente) estas funciones?
• ¿Cómo deberíamos reemplazar (no ejecutar el código existente, pero ejecutar el nuestro en lugar de "anular") estos?

Estoy asumiendo el mismo enfoque se aplica a otras funciones que comienzan con un guión bajo como _isAvailable y _invoke.

Answer 1

Los siguientes métodos son llamados para un comando:

1. isAvailable
2. isEnabled
3. invocar

La clase base para todos los comandos - Tridion.Core.Command - tiene un nivel implementación de estos métodos. En su mayor parte, esta implementación predeterminada permite extensiones a Comandos. También llaman a los métodos de subrayado (_isAvailable, _isEnabled y _execute).

No sé por qué los comandos CME solo sobrescriben los métodos de subrayado. Tal vez alguien pensó que era más fácil de esa manera. Deben considerarse privados (o el equivalente de "protegido" en C#), por lo que en realidad me parece una mala práctica.

Sería más limpio implementar los métodos adecuados (isAvailable, isEnabled e invoke) y luego llamar a la implementación base utilizando this.callBase. Sin embargo, es posible que deba detener la canalización en este caso, o también sobrescribir los métodos de subrayado, para evitar que se sobrescriba su valor de retorno con los métodos de subrayado predeterminados. Depende del comando que está implementando o extendiendo.

En resumen: utilizar los métodos de guión bajo es probablemente una mala práctica, pero la implementación de Core parece dificultar que lo hagas "bien". Así que mi objetivo es evitar los métodos de guión bajo, pero no preocuparme si resulta demasiado difícil hacerlo.

P.S. isValidSelection es un método exclusivo de PowerTools que separa la lógica común que todos necesitan de la lógica específica de cada comando.