Herramientas de usuario

Herramientas del sitio


plugins:apiplugins

Diferencias

Muestra las diferencias entre dos versiones de la página.

Enlace a la vista de comparación

plugins:apiplugins [2013/04/03 01:59]
127.0.0.1 editor externo
plugins:apiplugins [2021/04/30 19:19]
Línea 1: Línea 1:
-====== Clases necesarias para el desarrollo de plugins ====== 
- 
- 
- 
- 
-===== Persistencia de datos  ===== 
- 
-  * Package **model** 
- 
-^ Clase | **MPluginPO** | 
-^ Funcionalidad | Logica de negocios en persistencia | 
-^ Definición | Todo plugin que comprenda logica de persistencia debe extender de esta clase. Se deberán redefinir los métodos que sean necesarios (**preBeforeSave**, **postBeforeSave**, etc). | 
-^ Convenciones | Las mismas que para PO: Se relaciona el nombre de la tabla con la clase M correspondiente, priorizando el package del plugin.  Los métodos a implementar contienen los prefijos **pre** o **post** (por ejemplo **preBeforeSave**, **preAfterSave**, **postBeforeSave**, etc.) | 
-^ Retorno | Cada método deberá retornar una instancia de **MPluginStatusPO**, indicando: 1) El estado próximo de la ejecución a realizar (continueStatus) 2) En caso de error, indicar el mismo a fin de informar al usuario  | 
- 
-^ Clase | **MPluginStatusPO** | 
-^ Funcionalidad | Estado de retorno para persistencia objeto-relacional. | 
-^ Definición | El core lee la información devuelta por los metodos PO redefinidos en las subclases de **MPluginPO**.  En función del continueStatus, el core: 1) Detendrá la ejecución de persistencia (**STATE_FALSE**), 2) Salteará el metodo principal del core (override completo del metodo de persistencia del core) (**STATE_TRUE_AND_SKIP**), 3) Continuará la ejecución del metodo principal (el plugin es un agregado funcional al metodo principal del core) (**STATE_TRUE_AND_CONTINUE**) | 
- 
- 
- 
-===== Logica de documentos ===== 
- 
-  * Package **model** 
- 
-^ Clase | **MPluginDocAction** | 
-^ Funcionalidad | Logica de Documentos | 
-^ Definición | Todo plugin que comprenda logica de documentos deberá extender esta clase. Se deberán redefinir los métodos que sean necesarios (**preCompleteIt**, **postComplete**, etc). | 
-^ Convenciones | Las mismas que para PO: Se relaciona el nombre de la tabla con la clase M correspondiente, priorizando el package del plugin.  Los metodos a implementar deberán tener los prefijos **pre** o **post** según corresponda (ejemplo: **preCompleteIt**, **postCompleteIt**, etc.) | 
-^ Retorno | Cada método deberá retornar un **MPluginStatusDocAction**, indicando: 1) El estado próximo de la ejecución a realizar (continueStatus) 2) El m_processMsg 3) El docStatus | 
- 
-^ Clase | **MPluginStatusDocAction** | 
-^ Funcionalidad | Estado de retorno para logica de documentos | 
-^ Definición | El core lee la información devuelta por los metodos redefinidos en las subclases de **MPluginDocAction**. En función del continueStatus, el core: Detendrá la ejecución de logica de documentos (**STATE_FALSE**), Salteará el metodo principal del core (override completo del metodo de logica de documentos del core) (**STATE_TRUE_AND_SKIP**), Continuará la ejecución del metodo principal (plugin es un agregado funcional al metodo principal del core) (**STATE_TRUE_AND_CONTINUE**) | 
- 
- 
- 
-===== Callouts ===== 
- 
-  * Package **callout** 
- 
-^ Clase | **CalloutPluginEngine** | 
-^ Funcionalidad | Implementacion o redefinición de callouts | 
-^ Definición | Todo plugin que comprenda logica de callouts deberá extender esta clase. | 
-^ Convenciones | Se deberán implementar los metodos respetando la siguiente convención: La clase deberá tener igual nombre que la Tabla, anteponiendo la palabra **Callout**.  El metodo deberá tener igual nombre que la Columna, pero anteponiendo un prefijo "pre" o "post" Por ejemplo: **CalloutInvoiceLine.preM_Product_ID()** | 
-^ Retorno | Cada método deberá retornar un **MPluginStatusCallout**, indicando: 1) El estado próximo de la ejecución a realizar (continueStatus) 2) En caso de error, indicar el mismo a fin de informar al usuario | 
- 
-^ Clase | **MPluginStatusCallout** | 
-^ Funcionalidad | Estado de retorno para logica de callouts | 
-^ Definición | El core lee la información devuelta por los metodos redefinidos en las subclases de **MPluginDocAction**. En función del continueStatus, el core: Detendrá la ejecución del callout (**STATE_FALSE**), Salteará el metodo principal del core (override completo del metodo o métodos de callouts especificados en el campo de AD_Table) (**STATE_TRUE_AND_SKIP**), Continuará la ejecución del metodo principal (plugin es un agregado funcional al metodo principal del core) (**STATE_TRUE_AND_CONTINUE**) | 
- 
- 
-===== Procesos ===== 
- 
-  * Package **process** 
- 
-^ Funcionalidad | Redefinición de procesos | 
-^ Definición | Un plugin deberá redefinir un proceso por completo, pudiendo extender de **SvrProcess** o del proceso que está redefiniendo | 
-^ Convenciones | Será necesario implementarlo dentro del package de plugins correspondiente, con el mismo nombre de clase que la definida en **AD_Process** | 
-^ Retorno | Los procesos redefinidos no preveen una politica de ContinueStatus, ya que no tiene sentido.  Para dos plugins que redefinen un mismo proceso, se ejecutará el plugin con menor **CoreLevel**. | 
- 
- 
-===== Ventanas Info ===== 
- 
-  * Package **info** 
- 
-^ Clase | **InfoGeneralPlugin** entre otras | 
-^ Funcionalidad | Redefinición de ventanas Info | 
-^ Definición | Todo plugin que deba redefinir una ventana Info, deberá redefinir alguna de las clases detalladas en las covenciones, según esté redefiniendo una de las Info convencionales (**InfoProduct**, **InfoBPartner**, **InfoInvoice**, etc.) o creando una Info genérica (para cualquier otra tabla). | 
-^ Convenciones | Para redefinir una Info convencional, se debe implementar dentro del package correspondiente con el mismo nombre de la clase que se está redefiniendo.  Esta nueva clase podrá extender tanto de la clase redefinida como directamente de **InfoOrder**, según sea necesario.  Para crear una Info genérica, será necesario respetar la siguiente convención: Si la tabla a visualizar en la ventana Info se llama **C_AllocationHdr**, la clase deberá llamarse **InfoAllocationHdr** y deberá extender **InfoGeneralPlugin** a fin de respetar el constructor que invoca el engine de plugins. | 
- 
  
plugins/apiplugins.txt · Última modificación: 2021/04/30 19:19 (editor externo)