Primero de todo, ¿qué es esto de las Nested classes o Clases anidadas? Hablamos de este concepto, en este caso, para referirnos a controles de formularios, datasources de formularios, campos de un datasource de un formulario, etc… ¿Pero por qué lo llamamos as� Pues una forma sencilla de verlo es dirigirnos a algún formulario de #MSDyn365FO, por ejemplo, al CustTable, y ver su código. En el, podremos ver que el formulario CustTable es una clase, que tiene dentro uno o varios DataSources, que son a su vez clases que contienen DataFields, que también son clases, por lo que nos encontramos con clases dentro de clases, o clases anidadas.
[Form]
public class CustTable extends FormRun
{
const str address = 'Address';
const str addressTab = 'AddressTab';
...
[DataSource]
class CustTable
{
....
[DataField]
class CashDisc
{
....
}
}
}
Visto esto, os recuerdo como podÃamos modificar propiedades de FormControls en #MSDyn365FO a través de manejadores de eventos (Event handlers), de forma que podÃamos cambiar el comportamiento o las propiedades de dicho control en tiempo de ejecución. En ese momento, la única posibilidad que tenÃamos para realizar dicha tarea era esa, suscribirnos al evento en cuestión, obtener el control que querÃamos editar, y modificar sus propiedades.
A dÃa de hoy, podemos hacer este tipo de modificaciones de forma más rápida y sencilla, ya que podemos extender la funcionalidad por medio de Chain Of Command (CoC) sobre clases anidadas, o lo que es lo mismo, aplicar Chain Of Command sobre controles de formularios (FormControls), orÃgenes de datos (FormDataSources) y controles en general como botones o campos de datos (FormDataFields) del propio formulario. ¿Y cómo hacemos esto?. Pues muy fácil, supongamos que queremos modificar alguna propiedad de un DataSource concreto en tiempo de ejecución. De momento, nos olvidamos de los Event Handlers, y vamos directamente al lÃo:
1- Creamos una clase, que debe ser de tipo final y será la extensión FormDataSource en sÃ, y le añadimos el atributo ExtensionOf que indicará el objeto que estamos extendiendo.
[ExtensionOf(formDatasourceStr(CustTable, CustTable))]
final class CustTableJATM_Extension
{
}
2- Añadimos el método active, que debe tener la misma definición que el método estándar. En este método tenemos que llamar al método next() obligatoriamente, que se encargará de ejecutar el código estándar del método. Es un concepto similar al de super().
[ExtensionOf(formDatasourceStr(CustTable, CustTable))]
final class CustTableJATM_Extension
{
public int active()
{
int ret = next active();
return ret;
}
}
3- Ahora ya añadimos el código necesario para llevar a cabo nuestro propósito.
[ExtensionOf(formDatasourceStr(CustTable, CustTable))]
final class CustTableJATM_Extension
{
public int active()
{
int ret = next active();
FormDataSource custTableDS = this;
custTableDS.allowEdit("condición");
return ret;
}
}
La primera gran diferencia que vemos con respecto a los event handlers, es que podemos acceder al objeto en cuestión utilizando el this, eso sÃ, si necesitamos modificar alguna propiedad tenemos que asignarlo a una variable de ese tipo para poder acceder a sus propiedades.
La verdad que la entrada del Chain of Command dentro de la plataforma nos facilita muchÃsimo la tarea de extender la funcionalidad del sistema, y eso es de agradecer. (Por ejemplo, y aunque no tiene que ver con los nested classes, mientras que solo podÃamos suscribirnos a eventos de métodos públicos, Chain of Command nos permite extender la funcionalidad de métodos tanto públicos como protegidos).
Como comentaba anteriormente, podemos extender implementando Chain of Command tanto FormDataSources como FormControls y FormDataFields, utilizando los métodos formDatasourceStr(), formControlStr() y formDatafieldStr() respectivamente para identificar el objeto que estamos extendiendo.
Y hasta aquà el artÃculo de hoy, os leo en los comentarios. 

Like
Report
*This post is locked for comments