QuartupDevDoc

Estructura definición de campos de objetos QU_Table

Los campos de una tabla SQL (clases que extiendan la clase QU_Table) se definen con un array del siguiente formato:

array(<colType>,<colCode>,<sqlType>,<lenght>,<htmlType>,<description>,<values>,<defaultValue>,<onkeyupCol>)

<colType>

Tipo de campo, con el siguiente formato:

{'', 'E', 'F', 'P', 'Q'/'q'/'r'/'A'/'T', 'G'/'g', 'X', 'Y'} + ["H"] + ["V"] + {"L","l"(obsoleted)} + ["N"(obsoleted)] + ["t"] + {"e","b","n"} + ["B"] + ["I"] + ["R"]

• '' línea de tipo campo [QU_ColReal]
• E enlace con otro fichero (hay que llenar codcampo; descrip. vals y defVal) Si el vals se deja vacío, entonces se interpreta el defVal como código html a incrustar en su ubicación (tanto para el flow como para el look). Si se quiere usar para el 'flow' hay que tener en cuenta que todos los 'ids' hay que sufijarlos con 'QQQ' para que el núcleo del Quartup lo sustituya automáticamente por el sufijo del registro del 'flow' en cuestión
• F enlace con otro fichero (igual que el "E" pero en formato "iframe"). Para estos casos, el campo defVal puede ser un array: el primer elemento será el código de que incrustará dentro del 'iframe' y el segundo el código que se incrustará a continuación del 'iframe'
• a es complemento del 'F', desactiva la línea en blanco encima del 'iframe'
• P pestaña de separación (solo hay que llenar codcampo con los datos: 'título-pestaña|titulo-corto|key'). Si se deja el 'codcampo' en blanco, entonces se interpreta como un 'bloque fijo' que no tiene botón de activación y está siempre visible (y si ponemos 'PP' indicamos que la pestaña debe tener una ralla de separación en el bloque de secciones con la siguiente pestaña) (el título-corto es el que se ve en la capa escamoteable -y si es 'false' se omite-) (la key es el código de tecla para activar la pestaña por el teclado, puede ser 'esc','f6','f7' por ahora)
• Q/q fieldset de separación, con 'Q' se abre y con 'q' se cierra (se puede que llenar codcampo del 'Q' con una lista pipe-separada con los datos: {#color-fondo ó html-class} | título-fieldset | id-fieldset | indicador-'closed')
• r raya simple de separación (se puede llenar codcampo con el color de la ralla) (antiguamente se interpretaba la 'q' que no cerraba una 'Q' como la 'r', actualmente no)
• A línea en blanco de separación (si ponemos 'An' nos pondrá 'n' líneas en blanco)
• T texto html, se llena codcampo con el texto en cuestión
• G/g grupos de campos (si ponemos 'Gn' nos creará el grupo con un 'colspan=n' en el 'td' contenedor) (solo hay que llenar codcampo con título de grupo en 'G', y el tipSql con % de 'width' coma-separados de títulos/input o 'c' de config.) Si está vacío ocupará el ancho que pueda, si tiene 'r' se pondrá 'align=right', si tiene 'm' se pondrá 'align=center' (por defecto es 'left'), si tiene 't' se añadirá 'valign=top', y si tiene 'b' se añadirà 'valign=bottom' (por defecto es 'valign=middle')
• H hidden, líneas reservadas para usos internos (y no salen en pantalla) Si la línea es un 'link', entonces se cargará internamente, y se renderizá en los edits, aunque oculto (para las líneas que son campos [QU_ColReal], la 'H' hay que ponerla en el tipHtml)
• V void, líneas anuladas, no se cargarán en el constructor, y no se procesarán para nada. Lo habitual es que las líneas 'V' se asignen de forma dinámica (según los parámetros que reciba el constructor), por ejemplo: el cialdocolin asigna 'V' a los campos que no se activan por configuración según el 'soporte', de esta manera los objetos creados con los campos desactivados con 'V' son más ligeros y mejoran el rendimiento en tablas grandes. Para estos casos lo lógico es que el constructor sin parámetros no asigne la 'V' a esos campos, para que así se creen en la tabla física. También es posible que haya campos que siempre estén con 'V' incluso con el constructor sin parámetros, en esos casos dichos campos no se crearán nunca (puede ocurrir que la configuración de la instalación los desactive por rendimiento). También puede ser que algunos campos estén en 'stand-by' para usos futuros, y los dejamos con la 'V' hasta que decidamos activarlos.
• X solo para 'admin', solo visible para usuarios de tipo 'admin' (para las líneas que son campos [QU_ColReal], la 'X' hay que ponerla en el tipHtml)
• Y solo para 'superadmin', solo visible para usuarios de tipo 'superadmin' (para las líneas que son campos [QU_ColReal], la 'Y' hay que ponerla en el tipHtml)
• L listed, se lista por defecto en los browse
• l(obsoleted) listed/edited, se lista y edita por defecto en los browse
• N(obsoleted) 'nombre' listed, se listan los campos 'nombre' (de salida) por defecto en los browse
• t indica que el título del campo no debe aparecer en el Edit (se usa para ocultar los títulos de los campos)
• e/b/n si procede, solo aparecerá el botón de Look(e), Flow(b), o Ninguno (n)
• B indica que el campo debe aparecer en la Barra de título/etiquetas del 'look'
• I para los links, indica que la ventana se abrirá como iframe
• R indica que el título del campo o link se usará en los reports sin alterar, y por tanto no se permitirá modificar en la edición de los reports que lo usen (a la práctica, siempre es posible modificarlo activando las traducciones en el usuario) y de esta forma forzamos que los cambios de los nombres de estos campos/links se propagen siempre a todos los informes

<colCode>

Nombre del campo/control, con letras, números y guiones bajos.

• Es imprescindible usar siempre minúsculas, ya que las mayúsculas se reservan para sufijos y prefijos de control.
• Existen algunos nombres reservados que permiten adicionar propiedades al campo cuando este contiene dicho valor reservado:
  • cif: si el código de campo empieza por la cadena 'cif', los controles JS validarán que el contenido sea un CIF correcto
  • email: si el código de campo contiene la cadena 'email', y no es numérico, los controles JS validarán que el contenido sea un e-mail bien formado
  • iban: si el código de campo contiene la cadena 'iban', y no es numérico, los controles JS buscarán seis campos con las subcadenas 'iban_pais/iban_banco/iban_oficina/iban_dc/iban_cuenta/iban_extra' y validarán que el contenido global sea un IBAN correcto
  • descuento: si el código de campo contiene la cadena 'descuento', los controles JS validarán que el contenido esté formado por valores numéricos (con posibles decimales) separados por símbolos '+'
  • filter: si el código de campo contiene la cadena 'filter' y el campo tiene una Join definida, entonces el browse de la join trabajará en modo 'filter', esto es: permitirá marcar más de un código, y estos se irán concatenando en el campo destino para formar un filtro según la codificación que usa Quartup en los filtros de las consultas.

<sqlType>

Tipo SQL del campo, con los posibles valores:

• TINYINT(99)
• SMALLINT(9(4))
• MEDIUMINT(9(7))
• INT(9(9))
• BIGINT(9(19))
• DECIMAL
• DATE
• DATETIME
• TIME
• date (idem que DATE pero sin siglos visibles)
• time (idem que TIME pero sin segundos visibles)
• CHAR (hasta 255)
• VARCHAR (hasta 255) (para casos case-insensitive)
• BINARY (hasta 255)
• VARBINARY (hasta 255) (idem CHAR, pero case-sensitive)
• TEXT (hasta 65.535) (para casos case-insensitive)
• MEDIUMTEXT(hasta 16 megas) (para casos case-insensitive)
• LONGTEXT (hasta 4 gigas) (para casos case-insensitive)
• BLOB (idem *TEXT, pero case-sensitive)

<lenght>

Longitud de dígitos con los valores:

• ZZ9 para campos CHAR,VARCHAR
• Z999 para campos DECIMAL (los 2 primeros son los dígitos totales, y los 2 últimos los decimales) (Cuidado: NUNCA poner ceros delante, ej: sí-"200" no-"0200", ya que PHP interpreta "0200" como octal)
• 0 resto de campos

<htmlType>

Tipo Html del campo, con el formato:

{'I[99][%]','M9999[%]','R'} + ['N'] + ['n'] + [{'a','A','B'}] + ['+'] + ['S'] + ['P'] + ['H'] + ['O'] + ['o'] + ['T'] + ['K'] + ['X'] + ['Y'] + ['Z'] + ['G'] + ['D'] + ['d'] + ['F'] + ['I'] + ['C'] + ['c'] + ['sql'] + ['sqls'] + ['Q'] + ['php'] + ['L'] + [',xxx']

• I[99|999][%] Input normal (los 9,s opcionales permiten forzar un tamaño para la pantalla)
• M{9999|999999}[%] select Múltiple (los 9,s son los número de líneas/columnas de la "select")
• R Radio
• N campo numérico AUTO-INCREMENT de numeración automática por el gestor de BBDD (solo puede haber un campo en todo el fichero, y el SQL lo numera solo), es imprescindible que haya un índice UNIQUE de la tabla que sea este campo, y solo ese campo, (el innoDB lo fuerza) aunque, para myIsam es suficiente con que exista un índice UNIQUE que finalize con ese campo.
• n campo numérico AUTO-HASH de numeración automática aleatoria (solo puede haber un campo en todo el fichero, y el PHP lo numera solo con números aleatorios de 18 dígitos), esto provoca que Quartup cree una clave primaria (PRIMARY) automáticamente con este campo solo (no se necesita definir, la crea el propio Quartup).
• a campo numérico de numeración automática por el Quartup (el Quartup lo numera solo antes de grabar), es imprescindible que exista un índice de la tabla con este campo (no necesita ser el primer índice, pero es habitual que lo sea si no hay campo 'N') y el primer índice que encuentre el Quartup con este campo se usará automáticamente para que el Quartup gestione este autonumérico. Se permiten tantos autonuméricos como se quieran, pero el primero de ellos definido cumple unas restricciones adicionales: su índice asociado ha de incluir el campo al final de la lista, y dicho índice debe ser 'unique'. El resto de autonuméricos no necesitan que su campo esté al final del índice, ni necesitan que sea de clave 'unique', así se permite que estos autonuméricos adicionales puedan ser ajustados por el usuario a su libre albedrío.
• A igual que el anterior, pero permite inserciones (renumeraciones) 'encima' de un registro dado. Solo puede haber un campo autonumérico de tipo insertable, y debe ser el primero de ellos definido (a la práctica esto no es una restricción importante, puesto que es muy habitual que este campo sea de la clave principal, y esté definido en los primeros campos del fichero). En los procesos de renumeración, Quartup ya se encarga de alterar los registros posteriores para encajar el nuevo que se quiera insertar
• B igual que el A, pero admitiendo también inserciones 'por debajo' (renumeraciones) A la práctica, si se define más de un campo con 'A' o 'B', solo se procesará el primero de ellos, y el resto se tratarán como 'a'
• + para los numéricos indica un campo sin signo, solo positivo; para los alfanuméricos indica que siempre será 'uppercase' (útil para los códigos)
• S secure, para campos "password" (se ven en pantalla, pero con asteriscos)
• P campo protegido, el usuario no puede modificarlo pero se ve en pantalla (cambia solo) Para los campos que no sean 'sql' ni 'php', el indicador 'P' protege el campo, pero para los campos 'sql' o 'php' funciona al revés: los desprotege (esto solo es útil cuando los métodos write/rewrite que usan el contenido manual del campo 'sql' o 'php' para procesar algo concreto, ya que, lógicamente, los campos 'sql' o 'php' no se almacenan en la tabla)
• H campo oculto, no se ve en pantalla (pero sí se carga, por si hay internal-updates)
• O obligatorio llenar en edición (en los campos con Join, también se valida que el campo 'nombre' asociado tenga valor correcto, así se valida que el código exista en el fichero relacionado)
• o no se valida el valor aunque esté lleno (solo tiene sentido en los campos con Join, ya que si no hay ni 'O' ni 'o' entonces Quartup valida que, si el campo está lleno, exista en el fichero relacionado siempre)
• T control para activar/desactivar totales del campo: los campos numéricos sin 'join' ni 'radio' siempre se entienden sí-totalizables por defecto, el resto de campos se entienden no-totalizables por defecto. Con el indicador 'T' forzamos invertir el valor por defecto anterior. Este indicador es importante para la 'sqlSelect': cuando hay un 'GROUP-BY' la 'sqlSelect' arropa la obtención del campo con un 'SUM()' automático
• K se añadirá botón para num-keypad
• X accesible solo para usuario tipo "admin"
• Y accesible solo para usuario tipo "superadmin"
• Z campo zero-visible (numérico que deben verse siempre los ceros en pantalla)
• G campo con botones grandes (por ahora solo en 'date': los botones de cambios de dia/mes/año)
• D campo 'document' ligado con la gestión documental del DMS (debe ser un BIGINT)
• d campo 'document' ligado con la gestión documental interna (debe ser INT)
• F campo 'file' para almacenar un archivo (debe ser BLOB o mayor), y en el campo vals hemos de poner los datos pipe-separados: tabla-para-almacenar-archivo | id-tabla-archivo | campo-local-filename | campo-local-extension
• I campo 'image' (debe ser un TEXT, donde se almacena el directorio y el archivo de la imagen), y en el campo vals hemos de poner los datos necesarios para que el kernel construya el nombre del archivo para almacenar la imagen (ver detalles más adelante en vals). Dentro del campo físico de la tabla se almacena el nombre final del archivo imagen, de tal manera que con un 'file_get_contents' del valor del campo podemos acceder al contenido de la imagen. Estos campos siempre quedan "Protected" automáticamente, salvo que se indique lo contrario con el indicador 'P'.
• C campo 'color' (debe ser un CHAR(6)), donde se almacena un color rgb de 6 dígitos. AL hacer 'click' sobre el 'input' se abre un color-picker (el del jscolor) para seleccionar el color del campo
• c campo 'compressed' (debe ser un TEXT/BLOB), donde se almacena un texto de tamaño importante. La compresión permite optimizar el espacio en disco y el tránsito hacia/desde la base de datos.
• sql Campo expresión 'sql', definida en vals (quedan "Protected" automáticamente, salvo que se indique lo contrario con el indicador 'P') Si queremos asociarle una 'join', entonces el vals lo montamos con la expresión 'sql' más un 'pipe' (|) más la expresión de la 'join'.
• sqls Igual que el caso 'sql', pero añadiendo una expresión 'php' adicional para evaluar en los totales. Igual que la anterior, también puede tener 'join': 'sql' + '|' + 'php-totales' + '|' + 'join'
• Q campo 'sql' desactivado por defecto en las lecturas (si no se indica la 'Q' la expresión sql se activa por defecto) 
• php campo expresión 'php', definida en vals (quedan "Protected" automáticamente, salvo que se indique lo contrario con el indicador 'P'), si la expresión en vals es una string vacía de comillas simples, entonces se interpreta que el valor del campo se asigna manualmente en la 'sqlSelect' y no se evaluará nunca.
• L campo 'drop-down-list' forzado 
• ,XXX tipo de campo DECIMAL (tipos cuyos decimales son configurables en la ficha de la empresa), ver abajo detalle

<description>

Descripción del campo (aparecerá en las ediciones)

<values>

Valores del campo:

• para los campos "Radio" (tipoHtml="R") se monta una string con la lista de valores:
  • "A,valor a[,x[,s]]|B,valor b[,x[,s]]|..."
  • (el [,x] indica el valor por defecto, y el [,s] indica salto de línea)
  • (si [,x] se pone con el valor [,checkbox] el 'radio' se convierte en un 'checkbox')
  • (IMPORTANTE: los checkbox han de tener el 1º valor 'unchecked' y el 2º 'checked')
• para los campos relacionados con un Join (tipo "E"o"F") se pone la definition del Join
• para los campos 'image' se detalla lo siguiente:
  • 'directorio|expresión-php-para-montar-el-nombre-sin-extensión|with-visible-en-pantalla,height-visible-en-pantalla|max-size|r/b según right/bottom-position-en-pantalla'
  • directorio: el nombre de la carpeta donde se ubicarán las imágenes, normalmente se deja en blanco, de forma que se calcula automáticamente con el formato: '../../images/prefijo-base-de-datosbase-de-datos/nombre-tabla'
  • expresión-php-para-montar-el-nombre-sin-extensión: expresión php del nombre, sabiendo que los campos del registro se acceden a través del array $a, (ejemplo del fichero de productos: $a['cod_articulo']). Aquí no se incluye la extensión, ya que esta siempre se arrastra de la extensión original del archivo 'uploaded'.
  • with-visible-en-pantalla,height-visible-en-pantalla pixels del tamaño al que queremos dejar visible la imagen en pantalla, si se omite uno de ellos, el navegador lo dimensiona proporcionalmente al otro. Si se dejan en blanco los dos se usará el tamaño original de la imagen.
  • max-size: el tamaño máximo de la imagen que permitiremos para 'upload', para evitar que nos puedan subir archivos demasiado grandes. Si se omite se sobreentiende '256000'.
  • r/b según right/bottom-position-en-pantalla: indicador de la posición de la imágen en pantalla: 'r' - right (a la derecha de los botones), 'b' - bottom (debajo de los botones), se asume una 'b' por defecto

<defaultValue>

Valores por defecto:

• para los campos "no-Radio" se pone el valor por defecto,
• si el campo es "DATE" y no ponemos defVal cogerá la fecha del día, si queremos otro valor podemos poner: "00000000", "m", "M", "a", "A", "I", "F"
• para los casos 'iframe' (tipCampo=='F') se pueder poner datos extras a enviar al browse, ejemplo: '&inf=pr,filter=cialdoco.sw_estado%21%3D%27T%27'

<onkeyupCol>

Código del campo del que dispará el onkeyup cuando se dispare el onkeyup en curso. Si le ponemos el valor 'ON' (fijémonos que está en mayúsculas, y no puede coincidir con ningún campo real) se entiende que se generará una llamada al 'onkeyup' del propio campo, para poder ejecutar validaciones controladas por el servidor.

Detalle de los tipos de campo DECIMAL

• "ST" - stocks/cantidades compras/ventas (unidades)
• "SE" - stocks/cantidades compras/ventas (embalajes)
• "PME" - precio medio ponderado en Euros
• "PCE" "PCD" - precios compras Eurs/Divs
• "PVE" "PVD" - precios ventas Eurs/Divs
• "DT" - descuentos
• "BU" - bultos
• "PE" - pesos
• "VO" - volúmenes
• "CA" - cambios de divisas y de embalajes
• "CM" - capacidades metricas
• "MD" - medidas métricas
• "TP" - tiempos de produccion
• "CP" - cambios de produccion
• "HP" - horas (duraciones) de produccion
• "AP" - cantidades de produccion (CANTIDAD-FIJ/VAR)
• "RP" - revisiones de produccion (NIVEL-REVISION)