[Jose Fantasia]

Quería saber porque hay casos que al momento de buscar la clase que redefine en un plugin una clase del modelo me esta agregando un _Ext de sufijo, por ende no encuentra la clase que estoy definiendo según el ejemplo de la wiky. Para el caso de redefinir un completeIt me anda bien pero en persistencia me agrega esto del _Ext.

Siguiendo el código es en PluginHandler método getLPluginPO

Gracias

[Jose Fantasia]

Agrego el código que estoy probando

package ar.com.mutual.plugin.model;

import java.util.Properties;

import org.openXpertya.model.PO;
import org.openXpertya.plugin.MPluginPO;
import org.openXpertya.plugin.MPluginStatusPO;

public class MProductPrice extends MPluginPO {

public MProductPrice(PO po, Properties ctx, String trxName, String aPackage) {
super(po, ctx, trxName, aPackage);
// TODO Auto-generated constructor stub
}

public MPluginStatusPO afterBeforeSave(PO po, boolean newRecord) {

[Federico Cristina]

Buenas,

La jerarquía para los beans es la siguiente:

PO
|
X
|
M
|
LP
|
M.._ext

Donde X es un POJO autogenerado (generalmente de CORE) a partir de la información en metadatos de columnas, y M es una clase opcional con lógica de persistencia/documentos (también de CORE). LP es un POJO autogenerado a partir de la información de metadatos de tu componente, y M.._ext es opcional conteniendo lógica ad-hoc, pero NO de persistencia/documentos. Esas clases deben extender de MPluginPO o MPluginDocAction, como se muestra en los ejemplos.

En cuanto a la lógica de PluginHandler.getLPluginPO():

Code:

// Primero busco la M.._Ext
…
// Si no existe, busco la LP_
…

Esa lógica se utiliza únicamente en el handler de persistencia o lógica de documentos, a fin de recuperar el POJO correcto (y con la información cargada adecuadamente), fijate por ejemplo PluginDocActionHandler.processAction() y PluginPOHandler.processPO(). Sin embargo, para determinar la clase de helper a instanciar (clases que extienden MPluginPO y MPluginDocAction), esta lógica no tiene incidencia alguna (no debería estar buscando la clase M..Ext para instanciar helpers).

Saludos,
Federico

[Jose Fantasia]

Federico gracias por la respuesta !!!

Consulto en base a esto que me contestaste.

Yo por ejemplo para otro caso donde tenía que agregar algo al CompleteIt de MInventory, en el plugin lo que hice fue crear la clase como M o sea:

public class MInventory extends MPluginDocAction {

public MInventory(PO po, Properties ctx, String trxName, String aPackage) {
super(po, ctx, trxName, aPackage);
// TODO Auto-generated constructor stub
}

public MPluginStatusDocAction postCompleteIt(DocAction document) {

Esto me anda perfecto el tema es que lo mismo no me funciona para cuando quiero redefinir una que extienda de MPluginPO que es el caso que te pase:

public class MProductPrice extends MPluginPO {

Debería en realidad redefinir como LP_ ? y no como lo estaba haciendo con M ?

Gracias
Saludos

[Jose Fantasia]

Lo que no entiendo es porque no me reconoce la clase MProductPrice del plugin en el caso que esta heredando de MPluginPO y si me reconoce MInventory.

Gracias Federico !!

[Federico Cristina]

Buenas,

Efectivamente debería comportarse tal como mencionás: si estás queriendo redefininir lógica de persistencia, hay que extender de MPluginPO e implementar – por ejemplo – el método preBeforeSave().

Si esto se encuentra correctamente configurado, quizás pueda deberserse a algún comportamiento anómalo de la lógica de componentes bajo una tabla cuya Primary Key se encuentra compuesta por dos Foreign Keys (M_ProductPrice no contiene un campo M_ProductPrice_ID, sino que la PK se forma mediante M_Product_ID y M_PriceList_Version_ID. M_Inventory sí contiene un campo PK con nombre M_Inventory_ID).

Esto podría llegar a ser el motivo, pero es una idea únicamente. Para validar si efectivamente es así, podrías implementar una clase M que extienda de MPluginPO sobre otra tabla cuya PK sea el típico campo M_XXX_ID (son la mayoría de tablas) y validar si ahí no se presenta el problema. Por otro lado, validar si el problema también ocurre sobre otra tabla similar a M_ProductPrice, como por ejemplo AD_User_Roles (PK formada por dos FK). Si por ejemplo al implementar MUserRoles que exientede MPluginPO se presenta mismo problema, entonces ya tenemos determinado el origen del problema.

Slds!
Federico

[Jose Fantasia]

Perdón por la torpeza, uno automatiza y no se fija detalles mínimos por ejemplo que estaba poniendo afterBeforeSave en el código en lugar de preBeforeSave … podemos quedarnos tranquilos que no hay problemas con las claves compuestas !!!

Muchas gracias por el tiempo !!!

[Federico Cristina]

Bárbaro, me alegra que funcione como corresponde entonces!

Slds,
Federico

[Autor]

Entradas