En esta cápsula introduciremos la creación de extensiones de objetos estándar, en concreto tipos de datos y enumerados, por un lado, así como tablas, vistas y entidades por otro.  

Veremos qué cosas podemos y qué cosas no podemos hacer sobre estos objetos, puesto que, para proteger la integridad de la solución y la lógica ya establecida, las extensiones no nos permiten cambiar absolutamente todas las propiedades de los objetos estándar y no todos los objetos son extensibles, como por ejemplo ocurre con algunos enumerados. Por esta razón es de vital importancia conocer las limitaciones que Microsoft nos pone y saber qué alternativas tenemos a dichas protecciones para lograr con éxito satisfacer los requerimientos.

Crearemos nuevos campos y relaciones en tablas, así como éstos serán añadidos a vistas y entidades. Y además crearemos nueva lógica (un método display) a la tabla de clientes, viendo así cómo añadir código a las tablas.

A continuación, profundizaremos un poco más en el concepto de extensiones de código centrándonos en clases y formularios.

Las extensiones de código son la forma que tenemos de implementar nueva lógica en objetos estándar.

También crearemos extensiones de objetos tales como formularios, menus y menú items estándar. Llevando a cabo unos desarrollos simples con unos requerimientos ficticios, para ir familiarizándonos con esta nueva forma de trabajar.

Añadiremos una variable global y un método parm a una clase estándar.

Veremos los diferentes puntos donde añadir lógica a un formulario, y crearemos a modo de ejemplo el mismo método display que creamos en la tabla, esta vez a nivel de data source. Además de añadir nuestros nuevos campos de la tabla en el Grid del formulario de clientes.

Tras esto haremos que el botón de todos los clientes, en lugar de abrir la vista de grid abra la vista de detalles.

En esta cápsula veremos cómo trabajar con informes (reports) y seguridad estándar.

Frente a la imposibilidad de extender informes, plantearemos una posible solución para “modificar” el informe estándar, que consiste en hacer una copia.

Esta forma de actuar, en la cual sustituimos los objetos estándar por copias nuestras, no es una práctica recomendable en aquellos casos que no sea estrictamente necesario, puesto que MS ya no se va a hacer cargo de la mantenibilidad de este nuevo objeto que hemos creado, que será creado al margen de la lógica estándar. Por ello solo usaremos esta solución cuando no tengamos alternativa, como es este caso.

Además, esta solución tiene otro defecto que es desarrollar la lógica para que se seleccione nuestro report, en lugar del estándar. Cosa que haremos de una forma poco “invasiva” con el proceso estándar, añadiendo el diseño de nuestro nuevo report a la gestión de impresión y usando así toda la funcionalidad de ésta para ejecutar nuestro report, sin necesidad de extender ni sustituir menú ítems ni cosas por el estilo. Y es que, siempre aconsejaremos, en la medida de lo posible, usar la funcionalidad estándar antes que crear nosotros una propia.

También veremos cómo, para hacer cambios en seguridad, debemos extender los deberes (duties) y roles, para incluir los privilegios o duties que sean necesarios, ya que la extensión de privilegios para añadir acceso a nuevos menú ítem no es posible.

Llegados a este punto, quizá alguno de vosotros os estéis planteando lo siguiente:

Esto está muy bien pero solo hemos añadido nueva funcionalidad, nuevos campos, nuevos métodos… pero no hemos modificado en ningún caso la lógica que ya hay en el ERP, y sin poder hacer cosas en el transcurso del código estándar, no podemos llevar a cabo casi ningún desarrollo real.

¡Y la respuesta es que tenéis razón! Enhorabuena, porque habéis comprendido la enorme necesidad que tenemos de “extensiones de métodos” que se materializan en nuestro caso en Chain of Command y Event Handlers.

Por eso en esta cápsula conoceremos y aprenderemos a usar Chain of command y Event Handlers, que son las dos herramientas que tenemos a nuestra disposición para ejecutar lógica antes y después de los métodos estándar, así como cambiar los valores que reciban o devuelvan dichos métodos.

Estudiaremos las diferencias entre ambos aplicándolo a un ejemplo en el formulario de clientes. Y profundizaremos en el que usaremos a partir de ahora, explicitando sus ventajas, que es Chain of Command.

En esta cápsula ahondaremos en la extensión de métodos estándar usando Chain of command. Veremos su aplicativo a clases y tablas, y lo pondremos en práctica retomando el desarrollo de cápsulas anteriores del campo nuevo en la tabla CustTable.

Incluiremos el campo departamento en las tablas de facturas de servicio y de diarios de facturas de cliente también, de forma que nos traeremos el departamento del cliente en la factura de servicio y posteriormente, lo llevaremos al diario de facturas. Para ello añadiremos la lógica usando CoC además de añadir lo necesario en el formulario etc.

Además, veremos como la extensión de métodos nos da la oportunidad de modificar cosas que no se nos permite modificar en la extensión de objetos, como por ejemplo la obligatoriedad del campo descripción de la línea de factura.

También, haremos que en la validación que se hace sobre la factura de servicio a la hora de registrarla, se obligue a que el departamento de la factura esté relleno.

Dada la importancia del CoC en el desarrollo de D3FO, tanto ésta como la cápsula anterior son de vital importancia, y volveremos a trabajar el mismo concepto en cápsulas posteriores y en los ejercicios.

A la hora de desarrollar en general, no solo con extensiones, es realmente importante seguir una serie de buenas prácticas que ayuden a estructurar mejor los desarrollos, ordenarlos y hacerlos más fácilmente entendibles y mantenibles.

En nuestro caso, algunas de estas buenas prácticas son especialmente importantes puesto que vamos a trabajar sobre una plataforma de Microsoft que además está en constante cambio, y debemos ser ordenados y construir nuestras modificaciones de la forma más segura posible.

En esta cápsula veremos algunos consejos, y cosas que tener en cuenta, a la hora de estructurar y nombrar nuestras extensiones dentro de los diferentes modelos, así como motivaremos el uso de las naming conventions y explicaremos la importancia de las mismas.

Algunos ejemplos son el uso siempre de prefijos en los objetos extendidos o reutilizar las extensiones, de forma que solo haya una extensión por objeto por modelo.

En esta cápsula plantearemos un ejercicio completo de añadir campos nuevos a los pedidos de venta. Esto implica, tanto añadirlos a la tabla como al formulario como a incluirlos en DMF data entity framework, es decir, añadirlo a la entidad y la tabla staging.

Además, será necesario implementar funcionalidad para dichos campos, con lo que tendremos que refrescar nuestro Chain of Command.

El objetivo de este ejercicio no es otro que el de reforzar y motivar el aprendizaje propio en lo relativo a las extensiones tanto de objetos como extensión del código de los mismos.

Con lo que hemos visto a lo largo del curso, debéis tener al menos la capacidad para intentar el ejercicio por vuestra cuenta en el momento en que se plantee el enunciado completo.

En esta cápsula se planteará un ejercicio para reforzar y motivar el aprendizaje principalmente en el trabajo con formularios.

Nos centramos en este caso en el trabajo con formularios porque estos objetos son de los objetos más importantes y sofisticados de la herramienta.

Como ya hemos visto durante el curso, se trata de los únicos objetos, que no dejan de ser clases al final, que tiene clases embebidas. Esto hace que la extensión del código de los mismos sea ligeramente diferente como ya sabréis.

Dado que a lo largo del curso hemos hecho ejemplos prácticos tanto de extensión de DataSource como de FormRun, quería plantear un ejercicio con la idea de usar la extensión de un control del formulario. Me parece enriquecedor insistir en el trabajo con código de formularios estándar y de paso continuar mejorando y familiarizándonos con el CoC, que como ya os habréis fijado, se acaba necesitando para casi todo.

Esta cápsula es el ejercicio conceptualmente más complejo de los cuatro. En la misma hay un objetivo simple, pero para conseguirlo necesitaremos analizar el código estándar y encontrar la mejor forma y los mejores puntos en los que ejecutar nuestra lógica usando CoC. 

Este ejercicio, en mi opinión, es de una importancia superlativa, puesto que la mayor parte del trabajo de un desarrollador, y sobretodo de D3FO, es analizar y entender el código, en este caso del estándar, para encontrar los puntos clave en los que incluir la funcionalidad extra sin que ello afecte a la lógica del sistema, de una forma lo más limpia, clara y eficiente posible.

Como en todos los ejercicios, hay muchos caminos para llegar a la solución, por eso yo os invito a que encontréis vuestro propio camino, habiendo analizado muy bien el proceso estándar involucrado.

Tras hacerlo, ved la solución que yo os propongo, que no es más que una solución entre muchas otras igualmente válidas. Así que comparad las dos opciones y quedaos con la que más os guste.

En esta última cápsula se planteará un ejercicio para entrenar de nuevo el uso de CoC en procesos estándar tras haber hecho el análisis previo del mismo, así como de rellenado de un informe duplicado del estándar con datos nuestros, cosa que no hemos hecho durante el curso, pero que se puede generalizar fácilmente de lo aprendido en él.

El ejercicio estará aplicado a la modificación de nuestro informe ERDFreeTextInvoice, que está basado en data provider que toma los datos de unas tablas estándar, para lo que habrá que estudiar cómo se rellena ese report y añadir mediante extensiones todo lo necesario para incluir el campo nuestro.

Partiremos de la base de que el desarrollo hecho en la cápsula 3 está completo, y por tanto, tenemos nuestro report ERDFreeTextInvoice, así como el código para incluirlo en la gestión de impresión.

Una vez os aseguréis de tener todo lo necesario, os animo como siempre a que completéis el ejercicio por vuestra cuenta.