Consulta por extensión _Ext en plugin

Inicio Foros Foro principal Desarrolladores Consulta por extensión _Ext en plugin

  • Este debate está vacío.
Viendo 8 entradas - de la 1 a la 8 (de un total de 8)
  • Autor
    Entradas
  • #32854
    Jose Fantasia
    Miembro

    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

    #38809
    Jose Fantasia
    Miembro

    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) {

    #38812
    Federico Cristina
    Superadministrador

    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

    #38816
    Jose Fantasia
    Miembro

    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

    #38824
    Jose Fantasia
    Miembro

    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 !!

    #38825
    Federico Cristina
    Superadministrador

    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

    #38834
    Jose Fantasia
    Miembro

    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 !!!

    #38835
    Federico Cristina
    Superadministrador

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

    Slds,
    Federico

Viendo 8 entradas - de la 1 a la 8 (de un total de 8)
  • Debes estar registrado para responder a este debate.