Esta guía o “cajón de sastre” para los desarrolladores de PHPRunner, son algunas pequeñas cosas que no se escriben todos los días pero que son frecuentes y siempre está bien disponer de un sitio donde poder ir a recordar cómo se hacen.

Los temas los obtengo de las consultas que me llegan de distintos programadores que normalmente se están iniciando en PHPRunner y que me preguntan cómo se puede hacer ……

Para hacer los ejemplos me he basado en este modelo de datos que os explico.

El modelo no es real, pero quiere recoger los datos de una Persona, que dependiendo de su situación la Administración le va a facilitar una serie de ayudas y subvenciones Todo ello dependerá de la clasificación de esta Persona.

(1).- Tabla Maestra de los datos de la Persona y su clasificación. Sólo si es Mujer podrá informar si está embarazada o no.

(2).- Son las ayudas/prestaciones que recibe esta Persona. Como indica el modelo, las prestaciones que pueden recibir depende del Rol de la Persona.

(3).- Son las subvenciones que recibe la persona. Sólo si está embarazada, podrá recibir subvención de embarazada

(4).- Las prestaciones se relacionan con el Rol, pero para facilitar la actualización y claridad de los datos, se define un campo multivalor. El objetivo es cómo actuar en los lookup con un campo multivalor.

(5).- Son las clasificaciones que tiene Persona. Hay que fijarse en el campo Activo (Activo o Baja). Este campo nos va a servir para BLOQUEAR ( No Add, Edit o Delete) todos los registros de la tabla Histórico.

La DEMO de lo programado lo podéis ver en:  https://fhumanes.com/persona

Requisitos, Presentación y Codificación.

Aunque algunos de los requisitos o problemas, ya están planteados, pasaré a presentar el aspecto de la aplicación, explicar los requisitos y la codificación que se ha hecho.

(1) .- Se quiere que cada persona tenga un Estado y que según ese estado, se ponga el texto en color.

El estado es calculado dependiente de la “fecha de Próxima Revisión”.

• En plazo.- Cuando quedan más de 15 días para cumplirse la fecha.
• En renovación.- Cuando quedan entre 15 y 0 días para que venza la fecha.
• Está vencida.- Cuando ya ha sobrepasado la fecha de revisión.

Esto se ha solucionado con:

• Cambiando el SQL de la tabla “Persona”.

  SELECT
        idpersona,
        NombreyApellidos,
        persona_genero_idpersona_genero,
        persona_embarazo_idpersona_embarazo,
        persona_rol_idpersona_rol,
        persona_activo_idpersona_activo,
        proxima_revision,
       DATEDIFF(proxima_revision,now()) dias_diff,
   CASE
   WHEN DATEDIFF(proxima_revision,now()) > 15 THEN 'En plazo'
   WHEN DATEDIFF(proxima_revision,now()) <= 15 and DATEDIFF(proxima_revision,now()) >= 0 THEN 'En renovación'
   WHEN DATEDIFF(proxima_revision,now()) < 0 THEN 'Está vencido'
   END Estado
  FROM persona

• En el campo “Estado” se ha definido que es del tipo “Custom” y se ha codificado

  // Colorear el estado
  if ($data['dias_diff'] <= 15 && $data['dias_diff'] >= 0) {
      $value= '<p style="color:orange;">'.$value.'</p>';
  }
  if ($data['dias_diff'] < 0) {
      $value= '<p style="color:red;">'.$value.'</p>';
  }

(2).-  Se requiere que sólo la “Persona” que estén en “Activo”, se puedan dar Add, Edit y Delete.

Se han hecho varios ejemplos para este tipo de bloqueo, pero el más eficiente es:

• En el evento “after application initialized”, he puesto este código

   
  if ( $_REQUEST['mastertable'] == 'persona') {
      // Consultamos si el registro Master está ACTIVO
      $key1 = $_REQUEST['masterkey1'];
      $sql="SELECT persona_activo_idpersona_activo activo FROM persona WHERE idpersona = $key1";
      $rs=db_query($sql,$conn);
      $data=db_fetch_array($rs);
      if ($data['activo'] == 2) { // Consulta si "persona está de baja
           $_SESSION['historico_add'] = false; // No puede haber Add y DELETE
      } else {
           $_SESSION['historico_add'] = true;  // Sí puede haber Add y DELETE
      }
  }

Lo que hace es utilizar la variable de sesión “historico_add” para indicar si se puede A,E,D el registro “Historico” o no. Esto se hace controlando si la “mastertable” es “Persona” y capturando la información de “Activo” del registro “Master” que se está tratando.

• En el evento “Get Table Permissions” codificando:

  if ($_SESSION['historico_add'] == false ) {
        $permissions = str_replace("A", "", $permissions); // Quita  "A"
        $permissions = str_replace("D", "", $permissions); // Quita  "D"
        $permissions = str_replace("E", "", $permissions); // Quita  "E"
  }
  return $permissions;

Otras formas de bloquear, en este caso, el Add puede ser:

• Modificar el SQL de la tabla “histórico”, para llevar en el registro información de la clasificación de la tabla “máster”:

  SELECT
        idpersona_historico,
        Fecha,
        persona_idpersona,
        persona.persona_rol_idpersona_rol rol,
       persona.persona_activo_idpersona_activo activo,
        persona_prestacion_idpersona_prestacion
  FROM persona_historico
  join persona on (persona.idpersona = persona_idpersona)

• Los campos que hemos añadido de la tabla maestra “persona”, si no lo utilizamos en la presentación de Add o Edit, no hay que hacer ni tener en cuenta nada en especial, si como en este caso lo vamos a utilizar en la presentación de los datos, tenemos que hacer en evento “before record added” en caso de Add y “before record updated” en caso de Edit:

  unset($values['rol']); // Elimino variable para que la la incluya en el UPDATE o INSERT
  unset($values['activo']); // Elimino variable para que la la incluya en el UPDATE o INSERT
  

• En Javascript podemos controlar e informar si se puede o no, dar el Add. Evento “javascript Onload event”:

  var ctrlrol = Runner.getControl(pageid, 'rol');
  ctrlrol.makeReadonly();
  var ctrlactivo = Runner.getControl(pageid, 'activo');
  ctrlactivo.makeReadonly();
  var mensaje = '0';
  ctrlactivo.on('change', function(e){
     if (this.getValue() == '2' && mensaje ==  '0'){
              mensaje = '1'; // Para que no salgan varias veces la ventana
              alert('Esta persona está dada de baja y no admite nuevas altas');
     }
  });
  

• También lo podemos controlar en el evento “before record added”:

  $return = true;
  if ($values['activo'] == 2) { // Consulta si "persona está de baja
  $message = "Esta persona está dada de Baja y no se permite añadir nuevos registros";
        $return = false;
  } else {
        unset($values['rol']); // Elimino variable para que la la incluya en el INSERT
        unset($values['activo']); // Elimino variable para que la la incluya en el INSERT
  }
  return $return;
  

(3).-  El requisito es que al hacer Add o Edit, en la tabla de “subvencion”, la subvención para embarazadas sólo aparezca para las “personas” que están “embarazadas”

• Este es otro método de establecer condiciones dependiendo de los valores del “master” sin que tengamos que arrastrar los campos en la presentación de las páginas. Incluimos el código en el evento “Process Record Values”, tanto en Add como en Edit:

  $idpersona = $values['persona_idpersona']; // Recogemos el Id de la persona
  $sql="SELECT persona_embarazo_idpersona_embarazo FROM persona WHERE idpersona = $idpersona";
  $rs=db_query($sql,$conn);
  $fila=db_fetch_array($rs);
  // Pongo el valor de la clave (N,S) (1,2) en variable de "proxy"
  $pageObject->setProxyValue("clave_embarazo", $fila['persona_embarazo_idpersona_embarazo']);
  

Lo que hace es recoger el valor de “Embarazada” del registro “persona” y lo deja en la variable “clave_embarazo” y la pasa al entorno del javascript.

• Y en el evento de “Javascript OnLoad Event” se incluye esta codificación:

  // alert(proxy['clave_embarazo']);
  var ClaveEmbarazo = proxy['clave_embarazo']; // Recoger variable de "proxy"
  var ctrlPersona_subv_embarazada = Runner.getControl(pageid, 'importe_embarazada'); // Acceder al campo de subv. de embarazada
  // Si no está embarazada no se "abre" el campo
  if (ClaveEmbarazo != '2') {
        ctrlPersona_subv_embarazada.setValue(0);
        ctrlPersona_subv_embarazada.makeReadonly();
  }
  

Otros Requisitos

• En este caso el requisito es que el desplegable de “Prestaciones” es dependiente del atributo “rol” que está en el registro “master” “persona”.

En este caso, para mantener la relación entre Rol y Prestación hemos utilizado un campo multivalor, para facilitarla lectura y mantenimiento de esta relación:

Para poder utilizar esta información en  2 lookup dependientes “rol” y “prestación” hay que normalizar el modelo de datos y eso se hace con una vista de PHPrunner con el siguiente código:

SELECT
p.`idpersona_prestacion`,
p.`Titulo`,
p.`Sigla`,
r.`idpersona_rol`
FROM ( persona_prestacion p join persona_rol r )
where ( find_in_set(r.`idpersona_rol`, p.`persona_rol_idpersona_rol`) > 0 )

• Cuando se está añadiendo o editando el registro “persona” el campo de “embarazada” sólo debe poderse informar si se ha indicado que en sexo es “mujer”.

Esto se hace codificando en el evento “Javascript OnLoad Event”:

// De entrada, el campo de Embarazo se oculta o se pone en  solo Lectura
var ctrlGenero = Runner.getControl(pageid, 'persona_genero_idpersona_genero');
var ctrlEmbarazo = Runner.getControl(pageid, 'persona_embarazo_idpersona_embarazo');
// ctrlEmbarazo.hide();
// ctrlEmbarazo.setDisabled(); 
ctrlEmbarazo.makeReadonly();
// Cuando se introduce el valor de género.
ctrlGenero.on('change', function(e){
   if (this.getValue() == '2'){
       // ctrlEmbaraso.show();
       //  ctrlEmbarazo.setEnabled();
       ctrlEmbarazo.makeReadWrite();
   }
});

Esto es todo lo que deseaba explicar en esta guía. La he puesto número 1, porque  mi intención es ir recogiendo nuevas preguntas e irlas explicando en este tipo de guías y ejemplos.

En los ficheros adjuntos están todos los fuentes que podéis necesitar para instalar el ejemplo en vuestros PC’s y como siempre, para cualquier duda o necesidad de explicación, poneros en contacto conmigo a través de mi email [email protected]