Manual técnico TpvFox

En esta sección pondremos información para SuperAdministradores y desarrolladores de la aplicación TpvFox.

En nuestro proyecto TPVFOX versionamos X.Y.Z

Método de crear versiones (tag)

Esto quiere decir que:

X: Fin de una etapa, ya se terminó de implantar de nuevas funcionalidades.

Y: Añadimos alguna funcionalidad o cambios bastante grandes.

Z: Pequeños cambios y pequeñas mejoras. Este número indicar cuantos commit esta por encima de la última versión (pequeños parches), si eres desarrollador y quieres saber que numero de version ver la respuesta a el punto siguiente , donde te explica como obtener cuando commits esta por encima.

¿Cómo sabemos en versión estamos?

De momento saber cuál es la única forma de saber cuál es la versión en la que estamos es a través de un repositorio de Git y desde la terminal poniendo la siguiente instrucción:

git describe

La respuesta es algo así

▶ git describe 
v0.3.0-29-g3266211c

v0.3.0 es el tag, la versión que estamos. 29 indica que la rama actual esta 29 commit por encima de ese tag.

En la rama STABLE no debería indicar ningun numero, ya que no es habitual que estemos encima sin tener versionado. En otras ramas, como MASTER si puede estar por encima, ya que son ramas que estan en constante desarrollo.

Versiones de nuestra Base de Datos

Todos sabemos que los cambios en la estructura de la Base datos implica siempre posibles problemas con el código

Como versionamos nuestra Base de datos

En nuestro proyecto TPVFOX cuando realizamos un cambio en la estructura de la base de datos, lo que hacemos es un fichero con los cambios indicando la versión, este fichero se guarda en el directorio BD/Update con el nombre y sufijo de la versión, como indicamos a continuación:

install_update_vX.Y.[Z]

[Z] Estos al igual que al anterior, nos indica cuantos commits estamos por encima de la rama actual. No tiene por qué existir esa versión con esa terminación, pero sí son correlativas.

En estos ficheros puede encontrar las instrucciones SQL para ejecutar y así actualizar tu Base de Datos.

Siempre que hagamos un cambio en la base datos, generamos un fichero install_update_vX.Y.Z que es realmente el commit que vamos a hacer justo después de crearlo.

Cuando vayamos a actualizar un repositorio, simplemente debemos saber en versión estamos y luego actualizar el repositorio, luego solo tenemos que ejecutar los ficheros superiores a la versión que estábamos.

Por ejemplo, si estamos en la versión v0.2.22 del código, si actualizamos hasta la versión v.0.3.30, debemos ejecutar todos los ficheros que hay con las versiones superiores v0.2.22 en el directorio BD/Update, hasta la versión que vamos a actualizar.

Posibles problemas con Base Datos de backup

Nos podemos encontrar con el problema que cuando tenemos un backup de base de datos, ya que no sabemos en qué versión está esa copia. Y tampoco podemos comprobarlo con el código, puesto que realmente no está en funcionamiento y no tenemos repositorio instalado para ese backup.

Por este motivo, creamos este issue en el proyecto, para poder registrar el número de versión en una tabla de configuración, así de esa forma podemos guardar en esa tabla el número versión de la base de datos y luego simplemente tendríamos que actualizar desde esa versión.

El objetivo es hacer un proceso sencillo para poder controlar eventos de teclado y raton en input o cjas que necesitemos. Una idea similar como Shortcut.js.

Nosotros creamos lib teclado.js, que utilizamos en nuestro proyecto tpvfox, donde pretendemos controlar eventos de teclado y raton de un forma mas sencilla, creo que lo hemos conseguido :-)

¿Como empezar?

Lo primero añadir nuestra librería al proyecto, por ejemplo:

<script src="/lib/js/teclado.js" type="text/javascript"></script>

Luego añadir JS los Objetos queremos controlar, variables globales en JS en el head


var idInput = {
	id_input : 'idInput', // Este se añade ante construir ya que el id input es Unidad_Fila_1
	acciones : {
		 13 : 'accion_realizar_pulsar_intro', // Pulso intro
		 40 : 'accion_realizar_pulsar_abajo', // Pulso abajo. 
		 38 : 'accion_realizar_pulsar_arriba', // Pulso arriba pero va para abajo.
			},
	parametros : {
		dedonde : 'nombre_pantalla'
		// Los parametros que podemos necesitar
		}
}

Esto nosotros en tpvfox, no los añadimos directamente, lo generamos con el fichero parametros.xml, pero eso es otra historia a contar en otro momento.

Luego en nuestro html , en nuestro input debemos porne el atributo data-obj="Nombre_objeto_global". También tenemos que llamar a la funcion controlEventos(event) en el atributo html del evento queramos controlar.

En esta parte tienes que tener en cuenta que las funciones que necesita y utiliza son:

function controladorAcciones(caja,accion)
function after_constructor(padre_caja,event)
function before_constructor(caja)

¿Que hace la funcion controladorAcciones ?

Esta funcion puede ser un switch o simple if donde comprobamos si existe la accion que le tenemos objeto global.

Llegamos a la funcion cuando pulso una tecla o un evento que tengamos definido en el objeto global, realizar la accion que le indiquemos

¿Que hace la funcion after_constructor(padre_caja,event)?

Antes de montar el objecto con la tecla y realizar accion, se ejecuta.

¿Que hace la funcion before_constructor(caja)?

Despues de montar la caja y antes de hacer la funcion que asignamos, se ejecuta.

Nota:
La definicion de esta dos ultimas funciones, debería se al contrario, pero como ya teníamos proyectos con ella, de momento no la cambiamos.

Usamos el Modal de Javascript de Bootstrap, puede ver la documentación del modal de bootstrap

Como puedes ver en el repositorio github del proyecto tenemos en el directorio plugin/modal los ficheros

func_modal.js
ventanaModal.php

El primero es JS con el tenemos funciones para abrir modal, cerrarlo y alguna otra mas... :-)

El fichero php es el html template del modal, el cual podremo añadir con Javascript (Jquery) el contenido.

¿ Como lo añado en mi vista ?

Simplemente en fichero vista php añades:

 <?php
 echo '<script src="'.$HostNombre.'/plugins/modal/func_modal.js"></script>';
 include $URLCom.'/plugins/modal/ventanaModal.php';
 ?>

Lo suelo colocar justo antes de cerrar la etiqueta body.

¿ Como muestro popModal y como cierro?

Pues desde nuestro JS podemos llamar a la función abrirModal que tenemos func_modal.js , enviando titulo y el contenido como parámetros.

Para cerrar lo mismo, utilizamos la funcion cerrarModal que tenemos func_modal.js

¿ Como hago algo después de cerrar el modal ?

En la documentación encontré el evento :

$('#ventanaModal').on('hidden.bs.modal', function (e) {
.... lo queremos hacer despues de cerrar.
});

Con este evento, se ejecuta al cerrar Modal..

Por ejemplo, puede ser interesante refrescar la pagina cuando añadimos o operamos algo, pero si pulsamos cerrar, te interesa que refresque la pagina para mostrar los cambios.

Esto prefectamente podrías hacerlo sin controlar el evento y poner recarga de pagina con javascript, pero si tienes un boton de cancelar el que no hace nada, o no simplemente deja todo igual, te interesa que no lo haga, es ahi donde entra el metodo anterior.

Aquí intentaremos explicar los posibles estado que pueda tener el campo estado en las distintas tablas del proyecto TPVFOX.

Este campo hasta ahora era varchar, sabemos que no es lo correcto, crearemos una tabla de estados para relacionarlas con un id :-)

Ahora definimos los posibles estados que vamos utilizando en las distintas tablas.

CRUD es un acronimo ingles de Crear, Leer, Actualizar y Borrar. Los que me conoceis sabeis que no me gustan mucho tecnicismos y acronimos raros, aunque tenemos que conocerlos para poder hablar a veces con algunos compañeros que si los utilizan.

En nuetra aplicacion intentamos hacer un modelo CRUD que podamos utilizar en todos los modulos que utilicemos, desde que empezamos el proyecto hasta ahora pasamos ya por varios modelos, por ello es hora empezar de formarme y documentar de una forma mas estandar para tener CRUD en tpvfox.

Ponemos los Modelos que tenemos en estos momento, ya que algunos los fuimos descartando y no existen:

/modulos/claseModelo.php
/modulos/claseModeloP.php
/ClaseTFModelo.php

Poco a poco estoy intentando pasar todas las llamadas a de los primeros al ultimo ( /ClaseTFModelo.php ).

Explicacion general de permisos en tpvfox

La gestión de los permisos es independiente para cada usuario.

En la tabla usuarios tenemos un campo grupo_id que si le ponemos al usuario el valor 9 es como si fuera administrador y tiene todos los permisos.

Aunque los permisos son independiente y se podría quitar o poner permisos distintos a casa usuario.

Lo permisos pueden ser:

1 -> tiene acceso
0-> no tiene acceso

Los permisos de modulos , vistas o acciones los indicamos en el fichero access.xml de cada modulo pero siempre con jeraquia modulo->vista->accion. Por ejemplo:

mod_clientes -> tiene permiso
vista listado clientes -> tiene un permiso
acciones dentro listado clientes -> tiene otro permiso.

No podemos crear un permiso una accion fuera de una vista.

¿Donde guardamos los permisos de cada usuario ?

Los permisos de cada usuario los guardamos en tabla permisos

¿ Que son lo permisos del con usuario 0 ?

Son los permisos que tenemos por defecto en los ficheros access.xml de todos los modulos y plugins.

Se utilizan para limpiar permisos y añadir los que faltan a cada usuario, reorganizar permisos.

¿ Donde añado un permiso a un modulo ?

Cuando se crea un modulo , en el fichero acces.xml se indica los permisos por defecto del modulo , de sus vistas y sus acciones.

Cuando en produccion añadimos una accion, entonces los permisos tienes que reorganizar permisos, tambien podermo resetear los permisos.

Lo primero es deciros que esta entrada es un borrador para nosotros los programadores de tpvfox, no es un modelo a seguir, para nada, todo contrario ya que este proyecto empezó con código espagueti y poco a poco lo vamos mejorando.

Si estas interesado continuar mejorando nuestro TPVFOX es interesante que sigas leyendo. No dudes en ponerte en contacto con nosotros para cualquier aclaración o duda.

Un poco teoría y referencias.

Un MVC que precie debería separar la lógica de la aplicación con la vista (lo que muestra), es decir que nos permite separar los componentes de nuestra aplicación según su funcionalidad, que cuando hacemos un cambio en alguna parte de nuestro código, esto no afecte otra parte del mismo, no es una tarea fácil.

Por ejemplo:

En una web un usuario hace una petición en una web , el controlador responde esa petición, ya que es el controlador el se que encarga de la lógica de la web.

El controlador le pide al modelo la información de esa petición. El modelo se encarga de los datos ( consultar la base de datos) , una vez los tenga , se los envía al controlador nuevamente , por ultimo es el controlador el que se los envía a la vista para mostrarlos.

Tengo que decir que todas las referencias que fui leyendo , no siempre los modelos se encargan de los datos, por lo que entiendo que no todas los sistema MVC son iguales.