• Este debate está vacío.
Viendo 2 entradas - de la 1 a la 2 (de un total de 2)
  • Autor
    Entradas
  • #31763

    Muy Buenas gente de Libertya ;)

    Estoy enfrentando un dilema en la modificacion de codigo que puede afectar al sistema general.

    La necesidad de esta modificacion provino de querer hacer lo del siguiente ejemplo

    En una Ventana con cuatro pestañas con el siguiente orden:

    A
    B
    C
    D

    (C y D hijos en comun de A y B)

    Al cargar el registro en A y dirigirme a C translada las propiedades y esto es correcto al igual que con D o de B a D o C.

    El poblema lo encontre en que si me paro sobre registros procesados en la pestaña B y quiero agregar un nuvo registro no me deja. En el codigo encontre un fregmento que segun la descripcion esta para validar que no se cree registros si el registro padre esta procesado. Esto parece valido pero la manera en la que lo hace me parece que no.

    Cito:

    org.openXpertya.model.MTab metodo(dataNew)

    // Prevent New Where Main Record is processed

    if( m_vo.TabNo > 0 ) {
    boolean processed = “Y”.equals( Env.getContext( m_vo.ctx,m_vo.WindowNo,”Processed” ));
    boolean active = “Y”.equals( Env.getContext( m_vo.ctx,m_vo.WindowNo,”IsActive” ));

    if( processed ||!active ) {
    log.severe( “Not allowed in TabNo=” + m_vo.TabNo + ” -> Processed=” + processed + “,Active=” + active );

    return false;
    }

    log.fine( “Processed=” + processed + “, Active=” + active );
    }

    Como se ve en el codigo el IF pregunta por el m_vo.TabNo que es el orden de aparicion u orden de despliege.
    Esto me parece una limitacion ya que se esta obligando a siempre tener un unico padre para las pestañas.

    En conclucion, mis preguntas son las siguientes:

    1. ¿No tendria que preguntar por el Nivel de la Pestaña en vez de por el Orden (Ya que este nivel permite tener valores iguales como A=0 y B=0, C y D = 1)?
    de esta manera permitiria poner cuantos pares quisieramos.

    2. ¿Si modifico esta condicion afectare gravemente al sistema?

    Bueno, espero que se compadescan de mi y me ayuden ya que esto esta deteniendo procesos de negocios.

    Saludos y desde ya muchas gracias.

    #35676
    Javier Ader
    Participante

    y si… la condición que chequea no es la ideal; el tema es que Libertya maneja “subcontextos” a nivel de ventanas completas (Env.getContext( m_vo.ctx,m_vo.WindowNo,”Processed”)). Esta claramente pensado bajo supoción de que en cada ventana va a existir un solo “Documento” (la columnas Processed y creo que un par mas son tratadas de manera especial, DocumentNo creo ).
    Mas alla de esto, tené en cuenta:
    -el nivel de la pestaña solo es algo visual (si no me equivoco); no tiene una semántica mas allá de mostrarte la pestaña identada.
    -No entendí muy bien como tenes las pestañas, esa asi?:
    A (order 10, nivel 0)
    -> C (order 20, nivel 1; “hija” de A)
    B (order 30, nivel 0)
    -> D (order 40, nivel 1, “hija” de B)

    La frase “C y D hijos en comun de A y B” me confunde un poco ; en particular “hijos en común”.

    -Si estas teniendo este problema es porque en una misma ventana tenes mas de una pestaña asociada a algún tipo de documento; es medio raro esto….

    De todas maneras; un “hack” podría ser cambiar la condición por
    if( m_vo.TabNo > 0 && “el nivel de la tab actual” >0) {

    “el nivel de la tab actual” porque no se que tendrías que mirar (m_vo casi seguro que lo tiene en algún campo); también tal vez la condición no tenga que ser >0 si no >1 . Lo “ideal” seria “buscar en las pestañas padres” y ver si tienen en la fila actualmente seleccionada con Processed = Y… pero lo veo muy complicado y no se si tan necesario (tal vez un hack mas “simple” seria no mostrar en A y B las columnas Processed; creo que de esa manera no se guarda nunca valor en el contexto, y la condición de error nunca se daría…. igual, es medio “sucio”; porque te permitiría agregar filas “hijas” cuando Processed es realmente “Y”) .

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