Definiciones del Management Center

La infraestructura del Management Center utiliza la información de configuración de los archivos XML para controlar la visualización y el comportamiento de objetos que están disponibles y que se utilizan en el Management Center. Estos archivos XML se denominan archivos de definición.

Todos los archivos de definición se incluyen en el directorio y subdirectorios workspace_dir\WebContent\WEB-INF\src\xml. Cuando cree sus propios archivos de definición personalizados, incluya los archivos debajo de este directorio dentro de un subdirectorio personalizado. No incluya los archivos personalizados debajo del subdirectorio commerce.

Los archivos de definición pueden incluir una o más definiciones. Hay tres tipos de definiciones que se utilizan en los archivos de definición del Management Center: definiciones de clase, definiciones de instancia de clase y definiciones de singleton.

Definición de clase: Las definiciones de clase definen las clases que se utilizan en la aplicación del Management Center. El nombre de elemento de una definición de clase es el nombre no cualificado de la superclase. Si la superclase no se encuentra en el paquete "cmc/foundation", el nombre del paquete, como por ejemplo, "cmc/catalog" debe estar incluido en el valor del atributo package para identificar por completo el nombre de definición de la superclase. Todas las definiciones de clase también deben incluir el atributo classDefinition con el valor establecido en "true".
Definición de instancia de clase: Las definiciones de la instancia de la clase definen instancias de clases. En una definición de instancia de clase, una instancia de la clase definida se diferencia de todas las demás instancias de la misma clase gracias a diferentes valores para los nombres de variable de la clase. El nombre del elemento de definición de instancia de clase es el nombre de la clase cuya definición es una instancia. Si el nombre de paquete de la clase no es "cmc/foundation", la definición de instancia de clase deberá incluir el atributo package para identificar el nombre de paquete. Se supone que una declaración de definición es una declaración de instancia de clase cuando se especifican tanto el atributoclassDefinition como el atributo singletonDefinition. No puede añadir lógica JavaScript definiendo métodos o manejadores para definiciones de instancia de clase.
Definiciones de singleton: Una definición de singleton define una clase singleton, que restringe la creación de instancia de una clase a una sola instancia. Esta única instancia se crea cuando se carga el módulo ADM (Definición de módulo asíncrono) correspondiente. El nombre del elemento de definición de singleton es el nombre de la superclase de singleton. Si la superclase no se encuentra dentro del paquete "cmc/foundation", la definición de singleton debe incluir el atributo de paquete. Todas las definiciones de singleton deben incluir el atributo singletonDefinition con el valor establecido en "true".

En función de los objetos y del comportamiento que está definido en un archivo de definición, el archivo se agrupa en una de las dos categorías de archivos siguientes: restringidos o personalizables.

Archivos restringidos: Los archivos restringidos incluyen definiciones de clases para las funciones básicas que son comunes a todas las herramientas del Management Center. Estos archivos restringidos pueden sustituirse cuando instale arreglos de mantenimiento o realice actualizaciones en HCL Commerce, por lo tanto, no los cambie. Todos los archivos dentro de un directorio restricted son archivos restringidos.
Archivos personalizables: Los archivos personalizables describen los objetos que se gestionan en una herramienta del Management Center y definen cómo se visualizan dichos objetos. Cuando instale arreglos de mantenimiento o realice actualizaciones en HCL Commerce, los archivos de personalización se mantienen. Puede utilizar, ampliar o cambiar las clases que hay en los archivos personalizables cuando vaya a personalizar el Management Center.

Dependencias de definiciones y estructura de archivo y definición

Cada definición se nombra de acuerdo con la definición principal dentro del archivo. Por ejemplo, el archivo BundlePrimaryObjectDefiniton.xml incluye la definición "cmc/catalog/BaseBundlePrimaryObjectDefinition", que define el objeto base o primario, a partir del cual derivan todos los paquetes compuestos de entrada del catálogo y los paquetes compuestos heredados.

Dentro de cada archivo de definición está el elemento <Definitions>. Dentro de este elemento raíz, cada elemento hijo debe ser una definición o una declaración de imagen. Cualquier otro tipo de elemento se ignora o se marca como un error. Las definiciones pueden incluir información de configuración para definir herramientas, objetos de negocio y vistas. Las definiciones deben definirse como un elemento hijo del elemento <Definitions> raíz. Para definir estas definiciones y declaraciones de imagen, se utilizan diferentes elementos y atributos. Para obtener más información sobre estos componentes de definición, consulte Componentes del archivo de definición.

Cada definición dentro de un archivo de definición se nombra, en mayúsculas y minúsculas, utilizando el nombre del paquete, el objeto que se está definiendo, y el sufijo del nombre de clase. Por ejemplo, el nombre de definición para buscar todas las definiciones de búsqueda de categorías es "cmc/catalog/FindCategories".

Una definición puede utilizar o depender de otras definiciones dentro del mismo archivo de definición o en definiciones que están definidas en otros archivos para ayudar a definir un objeto. Por ejemplo, una definición puede incluir una declaración de método que hace referencia a, o depende de, una clase o una definición de singleton para utilizar el objeto o la vista que está definida dentro de esa definición. Una dependencia de otra definición se declara definiendo un elemento <dependency> como elemento hijo directo de un elemento de definición.

Un elemento <dependency> debe incluir los atributos moduleName y localName. El atributo moduleName identifica el nombre de definición del módulo de AMD que se genera a partir de la definición a la que se hace referencia. El atributo localName identifica el nombre de variable que se utiliza dentro del código JavaScript local.

Si va a crear o personalizar una definición para que dependa de una definición de clase, debe anular la referencia a la variable de módulo con .Class para acceder a la definición de clase. Si la definición depende de una definición de singleton, debe anular la referencia a la variable de módulo con .Singleton para acceder a la definición de singleton.

Una definición también se puede ampliar sin cambiar directamente la definición original o el archivo que incluye la definición original. Puede ampliar una definición creando otra definición que identifique la definición que se amplía como la definición base. Utilice el atributo baseDefinition para establecer el nombre de la definición que se está ampliando.

Por ejemplo, el fragmento de código siguiente identifica la definición de objeto primario de productos que amplía la definición "cmc/catalog/BaseCatalogEntryPrimaryObjectDefinition" y tiene una dependencia de la definición "cmc/catalog/CatalogResources".


<Definitions>
  <PrimaryObjectDefinition baseDefinition="cmc/catalog/BaseCatalogEntryPrimaryObjectDefinition" 
    definitionName="cmc/catalog/BaseProductPrimaryObjectDefinition" detailsViewHeaderText="${catalogResources.UtilityPaneHeaderText}" 
    displayName="${catalogResources.product_DisplayName}" displayNameProperty="partnumber" helpLink="tasks/tpnaddpr.htm" 
    idProperty="catentryId" isBaseDefinition="true" newDisplayName="${catalogResources.product_NewDisplayName}" 
    newObjectMenuItemText="${catalogResources.contextMenuNewProduct}" objectGroups="CatalogEntry,Products,CatalogEntriesNotASKU" 
    propertiesDefinition="cmc/catalog/ProductProperties" searchType="FindAllCatalogEntries">
  <dependency localName="catalogResources" moduleName="cmc/catalog/CatalogResources"/>
  ...	 
  </PrimaryObjectDefinition>
</Definitions>

Crear y personalizar los archivos de definición

Puede personalizar los archivos de definición existentes o crear archivos de definición para definir la visualización y el comportamiento de sus propios objetos personalizados. Si no tiene la intención de crear y personalizar los archivos de definición, asegúrese de que cumple las directrices y las prácticas recomendadas para personalizar el Management Center. Para obtener más información, consulte Prácticas recomendadas de personalización y directrices de modelado del Management Center.

Cuando añade o cambia archivos de definición en el directorio y los subdirectorios workspace_dir\LOBTools\WebContent\WEB-INF\src\xml, no es necesario que reinicie el servidor de HCL Commerce. El servlet del módulo detecta las definiciones nuevas y cambiadas con la indicación de fecha y hora de los archivos de definición. No es necesario reiniciar el Management Center cerrando la ventana del navegador del Management Center y borrando la memoria caché del navegador.

Diferencias en los archivos de definición respecto a HCL Commerce versión 7

En HCL Commerce versión 7, los archivos de definición hacían referencia a los archivos estructurados XML con la extensión de archivo .def. Por lo general, estos archivos eran archivos de definición de propiedad o de objeto de negocio. En la versión 8, estos archivos se convierten a la estructura XML para los archivos de definición de clase e incluyen la extensión de archivo .xml..xml Todos los archivos OpenLaszlo (lzx) de la versión 7 se han convertido a los archivos de definición (.xml) en la versión 8. Con este cambio, los directorios de workspace_dir\WebContent\WEB-INF\src\lzx\commerce y los directorios de workspace_dir\WebContent\config\commerce de la versión 7 se fusionan para convertirse en el directorio workspace_dir\WebContent\WEB-INF\src\xml\commerce. Todos los archivos de definición (.xml) están en este directorio o en sus subdirectorios.