OnMind - Especificaciones Frontales - Version 1.0 (Preview)

Vista y Módulos de Formularios
© 2020 by César Arcila
This is still subject to change

Las especificaciones frontales para la vista o módulos de formularios de la plataforma OnMind puede entenderse como una capa abstracta y de unificación en la que se indica en un archivo JSON los atributos para generar el módulo frontal de componentes orientados a la gestión interna en una empresa o negocio, en donde se procesan datos para su control, conocimiento y estrategia, entre otros aspectos. Se podría ver también como una extensión de caracter netamente técnico del Método OnMind al interior de OnMind.

Dicho lo anterior, resulta importante que hayas revisado primero la documentación sobre los componentes de la interfaz de usuario (UI) y los demás componentes Web de OnMind, así como tener fundamentos de programación en el lenguaje Javascript moderno (2015+), aunque para empezar basicamente se requiere comprender el concepto de JSON (JavaScript Object Notation) dado que se usará siendo un formato de intercambio de datos ligero y sencillo en el contexto respectivo.

Una ventaja que ofrece esta propuesta es posibilitar facilidad de comprensión tanto a programadores o analistas recién iniciados como de largo recorrido pero no actualizados en tecnologías web del momento, apuntando al desarrollo ágil (en tanto no se requiera abordar mayor cosa sobre el aspecto visual) y yendo directamente al punto tan pronto como sea posible. Por otra parte, se proyecta con ello a futuro una manera dónde se puede especificar algo y traducirlo en diversas plataformas o estilos. Se cuenta con una función para generar algunas plantillas (“scaffolding” o andamiaje) que se basa en lo que por ahora corresponde a las especificiones establecidas por mi parte como autor de estas.

Actualmente, el generador de formularios requiere la comprensión del concepto de arquetipos, sus hojas de datos y las concordancias de “Data Specs” (elemento specs.main.form que se puede encontrar avanzando este documento). La composición de formularios, sus eventos o métodos se encuentran en el documento de Componentes Web de OnMind.
Adicionalmente, para personalizaciones o un nivel avanzado existen Componentes UI de OnMind y Tips de Implementación con Riot de modo directo.

Arquetipos de OnMind

Un fundamento clave para el análisis y diseño con el método OnMind consiste en comprender los arquetipos. Esto nos lleva a identificar un modelo o patrón, es decir, cada vez que se necesita una estructura de datos ya se han definido como arquetipos y lo que se requiere es determinar a cuál correspondería mejor una nueva colección o hoja de datos. Puede revisarse el documento del Método OnMind, pero básicamente esto se ilustra pensando en una colección de datos grande o super-tabla (apoyándose en tecnología como BigData o NoSQL de ser necesario). Los principales arquetipos son los siguientes:

Los arquetipos guardan una gerarquía interna o precedencia, por lo que no se requieren relaciones.

¿Especificaciones y Método?

• Ciertamente, partimos de especificaciones incorporadas a nuestro método.
• Se busca cercanía al estándar o modo prácticamente natural (Javascript funcional + HTML). Se puede obtener una baja curva de aprendizaje.
• Si aplicamos esto a la plataforma OnMind, tenemos los siguientes items:
  • La Hoja de Datos (fabricación o colección) basada en Arquetipos (x10)
  • Especificaciones frontales básicas (x8) en JSON (Data Specs)
  • Composición de formularios con componentes web principales (x7)
  • Generador de formularios + Editor. Herramienta para andamiaje o código ágil
  • Eventos o métodos frecuentes (x12) codificando con Javascript sencillo (plano)
  • El despliegue requiere aún intervención, pero es baja y habilita uso en dispositivos móviles
• ¿Qué posibilita partir de una especificación?
  • Por ejemplo, una interfaz visual más sofisticada que genere archivo de especificaciones y un proceso que corresponde a un generador con cierto estilo y librerías específicas (motor o clases según tecnología, ej. RiotJS).
  • Bajo esta filosofía, de implementarse podría llegar a independizarse de algunas tecnologías, si se logra una tendencia genérica.
• De este modo, es posible lograr impulso (técnico/tiempo) para proyectos.

Estructura general de la propuesta

Definir una estructura general para una serie de especificaciones propuestas (muchas por implementar) es simplemente un intento de orientarnos a cierta portabilidad o comprender la visión técnica del método. Es decir, a partir de una especificación abstracta, quizás también declarativa, es posible llegar a implementar herramientas a nivel superior y generadores a nivel específico. Por ejemplo, una interfaz visual más sofisticada que genere el archivo de especificaciones y un proceso que corresponde a un generador con cierto estilo y librerías específicas. Bajo esta filosofía, de implementarse podría llegar a independizarse de algunas tecnologías, si se logra una tendencia genérica. En su propuesta inicial, OnMind hace uso de Javascript y una librería sencilla como Riot JS (que guarda semejanzas de estilo con HTML) para implementar código de formularios, pero esto podría variar si se hacen uso de especificaciones que luego pueden implentarse como proyectos con otras tecnologías. Veamos a continuación la estrucutra general:

{
    "specs": {},
    "nav": {},
    "raw": {},
    "top": {},
    "bar": {},
    "msg": {},
    "fun": {},
    "own": {}
}

En un esquema esencial bastaría con definir simplemente el elemento specs y establecer las concordancias de “Data Specs” (specs.main.form) que es la manera simplificada cómo funciona el generador actualmente. Sin embargo, se documenta la especificación completa como parte de la visión del método.

En términos generales, esta sería una plantilla o estructura preliminar que deja ver los rasgos o elementos del nivel principal. Es importante recordar que estamos enfocándonos en un módulo o componente orientado a la gestión interna en una empresa o negocio, en donde se procesan datos para su control, conocimiento y estrategia. De allí que se implementan diferentes estados o instancias para dar un buen manejo y relación entre usabilidad y control admitido a un usuario de la interfaz, puesto que puede existir variación en la dinámica de un formulario cuando se inserta un registro nuevo y la que sucede cuando se está editando, por ejemplo, el identificador del registro debe protegerse de modificación o quizás exista un dato nuevo que aparece en el estado de edición dependiendo de la especificación dada. Dicho esto, se puede establecer la siguiente relacion de estados:

.
Lo anterior sugiere que deberá implementarse el comportamiento de los datos por cada estado, es decir, especificarse para: new, see, set y ask (incluso para for). Para mejor comprensión veamos la descripción de cada elemento de nivel principal.

Propiedades de “specs”

{
    "specs": {
        "languages": ["en","es"],
        "main": {
            "title": ["Title","Titulo"],
            "icon": "",
            "dai": "",
            "archetype": "",
            "making": "",
            "rendering": "",
            "tableref": "",
            "oneness": "2",
            "codefield": "id",
            "linkfield": "id",
            "nomode": ["ask"],
            "form": {
                "field1": {
                    "bind": "id",
                    "tag": "HIDDEN"
                },
                "field2": {
                    "bind": "column",
                    "tag": "INPUT",
                    "label": ["Name","Nombre"],
                    "new": {
                        "required": true,
                        "focus": true
                    },
                    "set": {
                        "tag": "INPUT",
                        "disabled": true
                    },
                    "ask": {
                        "tag": "HIDDEN"
                    },
                    "finder": true
                },
            }
        },
        "plus": [],
        "stylish": {
            "link": "default",
            "engine" "default",
            "hue": "default",
            "inverse": false,
            "mobilefirst": false,
        },
        "includes": [],
        "components": {}
    },
}

Los atributos relevantes que deben reportarse son los siguientes:

Se reserva specs.main.rendering que correspondería a la representación o versión del objeto, considerada para ser implementada a largo plazo.
Se reserva specs.plus que posibilitaría bloques de datos adicionales a specs.main. Actualmente se cubre dada la dinámica o estilo adaptado para móviles (mobile-first), en donde se pasa de una página a otra cuando se explora el detalle.
Se reserva specs.stylish para fijar el comportamiento del estilo de modo personalizado. Actualmente, se asume el estilo por defecto establecido para la plataforma.

Sobre “Data Specs” (Concordancias)

Lo que se busca es hacer una concordancia para especificar los datos en un formulario. Esto se usará en un generador. Cada dato o elemento para specs.main.form, definido en formato JSON (ejemplo: { "x": {}, "y": {}, }), puede tener los atributos que se describen a continuación:

.
Se usa specs.main.form considerando los modos o estados respectivos. Es decir, dada una dinámica con alguna particularidad se podrá definir haciendo uso de new, see, set, ask y for, los cuales a su vez pueden usar propiedades como bind, tag, label, focus, finder, required, disabled. Puede observarse en la estructura presentada. Tendríamos entonces lo siguiente:

.
Se usa specs.main.form...new (o new) cuando existe alguna variación del comportamiento respecto a specs.main.form, lo cual puede ser frecuente, por ejemplo, para una etiqueta o título, o un control de datos distinto en el evento de insercción. Este criterio sobre new aplica también para see, set, ask y for respectivamente. A diferencia de see que en pocas ocasiones se necesita indicar, for siempre se debe especificar.

Internamente, también se usan las propiedades super, stage y use. Además, para new, los eventos onsend, oncancel y onnext tienen un comportamiento por defecto.

Propiedades de “nav”

{
    "nav": {
        "tag": null,
        "sidebarif": false,
        "helpif": false
    },
}

Internamente usa también las propiedades stage y use

Propiedades de “raw”

Reservado para una barra de propiedades como alternativa a see o set de modo abierto, sin vincular campos, quedando definidos para su implementación.

{
    "raw": {
        "form": {
            "field1": {
                "name": 'user',
                "tag": 'INPUT'
                "label": ['User','Usuario'],
                "required": true
            },
            "field2": {
                "name": 'password',
                "tag": 'PASSWORD',
                "label": ['Password','Clave'],
                "required": true
            },
        }
    },
}

Propiedades de “top”

Actualmente se aplica una cabecera maestra. Se planifica para hacer o implementar un modo más sofisticado.

{
    "top": {
        "dai": "",
        "archetype": "",
        "making": "",
        "rendering": "",
        "tableref": "",
        "form": {
            "field1": {
                "bind": 'id',
                "tag": 'HIDDEN'
            },
            "field2": {
                "bind": 'column',
                "tag": 'INPUT',
                "label": ['Header','Cabecera']
            },
        }
    },
}

Internamente usa también las propiedades stage y use. Además los eventos onrow, oncard y onlinked con un comportamiento por defecto.

Propiedades de “bar”

Planificado para hacer o implementar desde cero correspondiendo a un menú de barra lateral

{
    "bar": {
    },
}

Propiedades de “msg”

Reservado para mensajes y su traducción

{
    "msg": {
    },
}

Propiedades de “fun”

Reservado para sobreescribir el comportamiento de las funciones internas dado la necesidad o el requerimiento. Los métodos o funciones de éste elemento se podrán ver en dellate citándose bajo el título “Eventos o métodos personalizables (fun)”.

{
    "fun": {
        "first": () => {},
        "find": () => {}
    },
}

Propiedades de “own”

Reservado para usar propiedades y metodos libres con alguna personalización específica para un usuario (o cliente), por ejemplo, funciones aplicadas al componente.

{
    "own": {
        "method": () => {}
    },
}

Ejemplo empalmando lo visto

{
    "specs": {
        "languages": ["en","es"],
        "main": {
            "title": ["Title","Titulo"],
            "icon": "",
            "dai": "",
            "archetype": "",
            "making": "",
            "rendering": "",
            "tableref": "",
            "oneness": "2",
            "codefield": "id",
            "linkfield": "id",
            "nomode": ["ask"],
            "form": {
                "field1": {
                    "bind": "id",
                    "tag": "HIDDEN"
                },
                "field2": {
                    "bind": "column",
                    "tag": "INPUT",
                    "label": ["Name","Nombre"],
                    "new": {
                        "required": true,
                        "focus": true
                    },
                    "set": {
                        "tag": "INPUT",
                        "disabled": true
                    },
                    "ask": {
                        "tag": "HIDDEN"
                    },
                    "finder": true
                },
            }
        },
        "stylish": {
            "link": "default",
            "hue": "default",
            "inverse": false,
            "mobilefirst": false
        },
        "includes": []
    },
    "nav": {
        "sidebarif": false,
        "helpif": false
    },
    "top": {
        "dai": "",
        "archetype": "",
        "making": "",
        "rendering": "",
        "tableref": "",
        "form": {
            "field1": {
                "bind": 'id',
                "tag": 'HIDDEN'
            },
            "field2": {
                "bind": 'column',
                "tag": 'INPUT',
                "label": ['Header','Cabecera']
            },
        }
    },
}