Ir al contenido

Tipos de valor

Cada atributo declara de qué tipo es su valor. En Histrix eso importa más que en otros lenguajes por una razón concreta: los booleanos del motor no se evalúan todos igual. Hay atributos donde attr="false" desactiva la función, otros donde la deja activa, y otros donde escribir false la activa.

Por eso los booleanos están separados en tipos distintos según su criterio de evaluación: el nombre del tipo dice qué hace el valor, sin necesidad de leer la descripción del atributo.

Tipo Con attr="false" Si se omite el atributo
BoolEstricto desactivado desactivado
BoolDefaultActivo desactivado activo
BoolPresencia activo desactivado
BoolTrueFalse depende del camino del motor indefinido
Bool01 usa 0 y 1, no true/false según el atributo

BoolPresencia sólo admite el valor true, y es deliberado: el motor mira si el atributo está, no qué dice. El schema rechaza ="false" para que el error salte en la validación en lugar de manifestarse como una función que quedó prendida.

BoolTrueFalse es el caso a mirar con cuidado: son los atributos que el motor lee por más de un camino, con criterios distintos. Ahí conviene escribir el valor explícito y leer la descripción del atributo antes.

Booleano textual: sólo el literal true en minúscula activa la función. Cualquier otro valor, y también omitir el atributo, la deja desactivada — así que TRUE en mayúsculas no la activa, y false es equivalente a no escribir nada.

Base: xs:string.

Valores (3 en total): true, false

Valores con particularidades:

  • no — Legacy: cuenta como “false” por no ser true, no por diseño. No hay un si complementario. En código nuevo escribir “false”.

Booleano activo por defecto: si el atributo no está, la función corre igual. El único valor con efecto es false, que la apaga. Escribir true es redundante.

Base: xs:string.

Valores (3 en total): true, false

Valores con particularidades:

  • no — Forma legacy equivalente a “false” en los atributos que la contemplan (borra, modifica, inserta). En código nuevo escribir “false”.

Sólo acepta true, y a propósito. El motor no mira el valor de estos atributos sino si están presentes, así que attr="false" activa la función igual que attr="true" — es el error más frecuente con estos flags. Para desactivarla hay que omitir el atributo.

El schema restringe el valor a true justamente para que un ="false" se marque como error en vez de fallar en silencio en runtime.

Base: xs:string.

Valores (1 en total): true

Modo del helper de ayuda de un campo. No es un booleano ni el atributo HTML autocomplete: los únicos valores con efecto son true (autocompletado sobre el input) y full (autocompletado + popup de la ayuda). Cualquier otro valor —incluido on u off— cae en el comportamiento por defecto, que es sólo el popup de búsqueda: o sea que off no apaga nada.

Base: xs:string.

Valores (2 en total): true, full

Qué hace el <jseval> después de calcular: true (por defecto) manda el valor al servidor con un request por cada cambio; false lo resuelve entero en el browser — es la forma recomendada para aritmética pura, porque en una grilla con cálculos en cascada el default genera cientos de requests. También acepta el nombre de un XML (algo.xml), y en ese caso el request va contra ese XML.

El patrón sólo admite esas tres formas justamente para que un fasle se marque como error.

Base: xs:string.

Patrón: true|false|[A-Za-z0-9_./-]+\.xml

Booleano textual "true" | "false" cuyo criterio de evaluación no es uniforme: el motor lo lee de más de una manera según el camino, o no está verificado cuál usa. En estos casos omitir el atributo no equivale a escribir ninguno de los dos valores, así que conviene ponerlo explícito y leer la descripción del atributo antes.

Si un atributo tiene un criterio único y claro, está tipado con uno de los otros tres: BoolEstricto, BoolDefaultActivo o BoolPresencia.

Base: xs:string.

Valores (3 en total): true, false

Valores con particularidades:

  • no — Legacy: cuenta como “false” por no ser true, no por diseño. No hay un si complementario. En código nuevo escribir “false”.

Booleano que se copia tal cual a la configuración de la grilla del navegador: por eso no acepta ni no ni 1/0 — cualquier otro texto no es un booleano válido del otro lado y rompe el armado de la grilla en lugar de simplemente no aplicarse.

Base: xs:string.

Valores (2 en total): true, false

Unidad de la escala de tiempo de un diagrama de Gantt.

Base: xs:string.

Valores (4 en total): hours, days, weeks, months

Qué hacer con el campo al limpiar el formulario. uniqid es el único valor que el motor reconoce: cualquier otro texto no hace nada.

Base: xs:string.

Valores (1 en total): uniqid

Booleano entero: “0” | “1”.

Base: xs:string.

Valores (2 en total): 0, 1

Papel que cumple el campo dentro de la tarjeta de un tablero tipo="kanban". La lista es cerrada: KanbanData::ROLES la valida y un rol mal escrito se reporta como error de configuración en pantalla, no se ignora.

Base: xs:string.

Valores con particularidades:

  • title — Encabezado de la tarjeta. Uno por tablero; sin él el tablero no se dibuja. Si el campo lleva un <helper>, la tarjeta muestra el valor crudo (el texto del control es vacío).
  • body — Texto descriptivo, recortado a tres líneas.
  • tag — Etiqueta corta al pie. Admite varios campos: cada uno se dibuja como una etiqueta aparte.
  • person — Responsable. Si el campo es un combo, se muestra el texto resuelto, no el id.
  • age — Antigüedad. El campo es una fecha y la tarjeta muestra el tiempo transcurrido (“12h”, “3d”). Acepta ISO y dd/mm/yyyy.
  • color — Color del borde de la tarjeta, tomado del valor del campo (un color CSS). Pisa el color de la columna: sirve para pintar por regla de negocio (vencido, urgente) en lugar de por estado.
  • action — Botón al pie de la tarjeta, normalmente un <helper type="link">. El campo no debe ocultarse: con noshow="true" el helper viaja como metadata y la tarjeta muestra el valor crudo, y con colstyle="display:none;" el botón hereda ese display:none. Dejarlo visible no molesta, porque la tabla que alimenta al tablero ya está oculta. Admite varios campos.

Dirección de ordenamiento. En el ORDER BY del SQL da igual la caja, pero el orden en memoria de la tabla temporal sólo reconoce DESC en mayúsculas: con orderType="desc" la consulta sale ordenada y la grilla temporal no. Para que las dos coincidan, escribir ASC/DESC en mayúsculas.

Base: xs:string.

Valores (6 en total): ASC, DESC, asc, desc, Asc, Desc

Tipo de JOIN.

Base: xs:string.

Valores (8 en total): left, right, inner, full, LEFT, RIGHT, INNER, FULL

Aplicación de un estilo de fuente en el PDF. No es un booleano: el valor dice a qué parte de la celda se aplica el estilo. El motor pinta la celda en dos pasadas —primero el valor, después la etiqueta— y compara el atributo contra la pasada en curso: “true” aplica sólo al valor, “label” sólo a la etiqueta y “both” a las dos. “false” no coincide con ninguna pasada, o sea que no aplica el estilo (es la forma de anularlo). El estilo se consulta sólo al imprimir fichas y etiquetas: en las columnas de una grilla no se mira, así que ahí ninguno de los cuatro valores cambia nada.

Base: xs:string.

Valores (4 en total): true, false, label, both

Tipo de helper (UI/ayudas). Un valor que no esté en esta lista no construye ningún helper y se ignora en silencio — el campo queda sin ayuda y no hay error en ningún log.

Pero el valor se guarda igual en el campo antes de que el motor decida qué helper armar, y otras partes lo comparan para saber si el campo tiene combo, ayuda o contenedor embebido. Por eso un type mal escrito no sólo pierde la ayuda: además puede desactivar la grabación inline de ese campo o el modo tags.

Base: xs:string.

Valores (10 en total): combo, comboex, link, external, parameter, object, inline, media, tags

Valores con particularidades:

  • import — Importa datos de otro XML al formulario. Se procesa por un camino aparte del resto de los tipos de helper, equivalente al tag <importar>: acepta los mismos <field>/<parameter> y los atributos del botón.

Tipo del campo: decide el render, el formato y la validación. El valor se resuelve a una clase de tipo del motor y, si no existe una clase para ese valor, el campo cae en silencio en el campo genérico: pierde el comportamiento del tipo y también la inferencia por la metadata de la columna, sin ningún error. Por eso el enum es cerrado: un valor no listado casi siempre es un typo que ya está fallando en producción.

Para resolver la clase el motor normaliza el valor (el guión bajo equivale a un espacio y el capital inicial es indiferente), pero guarda además el texto crudo del tag y lo compara de forma case-sensitive en más de una docena de lugares: armado del SQL, formato en el PDF, mapas. O sea que las variantes de grafía no son equivalentes aunque carguen la misma clase — resuelven el tipo y después no pasan ninguna de esas comparaciones. Escribir el valor exactamente como figura en la lista, con una excepción documentada más abajo: geoPoint va en camelCase.

Base: xs:string.

Valores (61 en total): date, datetime, time, hora, month, timestamp, text, varchar, char, character, longtext, mediumtext, html, editor, integer, int, bigint, mediumint, smallint, tinyint, numeric, decimal, hfloat, custom_numeric, enclosed_integer, enclosed_numeric, meter, check, toggle, flipswitch, radio, select, button, color, tags, file, files, dir, aws, base64pdf, cuit, email, url, tel, isbn, password, grafico, qr, rrule, cron, string, float

Valores con particularidades:

  • simpletextNo equivale a omitir <tipo>. No hay clase para este valor, así que el campo cae en el genérico; y como el tag trae un tipo no vacío, el motor ya no consulta el tipo real de la columna: el campo queda sin tipo, ni siquiera varchar. Para un campo de texto plano conviene no escribir el tag.
  • simpleditor — Idéntico a editor: no cambia ningún comportamiento (la clase CSS que lo distingue la pone el propio editor).
  • mapNo-op: como tipo de campo no agrega nada. El mapa lo dibuja la vista <histrix tipo="map"> a partir de un campo geoPoint.
  • geopoint — Punto geográfico. Si el campo alimenta una vista tipo="map" hay que escribirlo geoPoint, en camelCase: el mapa compara el texto del tag y con geopoint no encuentra el punto, así que no dibuja nada.
  • geopoly — Renderiza igual que un geopoint: hereda el input del punto y el control de polígono nunca se alcanza. Sirve para documentar la intención, no cambia el comportamiento.
  • DateNo equivale a date: la clase resuelve igual, pero las comparaciones del motor son contra el texto crudo del tag y ninguna matchea Date, así que el campo pierde el tratamiento de fecha. Usar date.
  • IntegerNo equivale a integer: la clase resuelve, pero el texto crudo Integer no pasa ninguna de las comparaciones de tipo del motor. Usar integer.
  • custom numericNo equivale a custom_numeric: la clase resuelve, pero el formato numérico del PDF compara contra custom_numeric y con el espacio se pierde. Usar custom_numeric.
  • geoPointEs la grafía obligatoria para los mapas, no una variante a evitar. La vista tipo="map" busca el tipo escrito exactamente así, en camelCase, para saber qué campo trae el punto; con geopoint en minúsculas no lo encuentra y el mapa sale vacío. En un campo que no alimenta un mapa las dos grafías rinden igual.

Operadores SQL para condiciones. Enum cerrado: arreglar el XML si trae un valor no listado.

Base: xs:string.

Valores (27 en total): =, !=, <, >, <=, >=, <>, IN, in, LIKE, like, NOT LIKE, not like, is null, is not null, IS NULL, IS NOT NULL, IS, is, IS NOT, is not, NOT, not, NOT IN, not in, BETWEEN, between