gvHidra

Tras discusión en "directo" se propone:
- Toni: Dejar que el array que se pasa al constructor de la clase "gvHidraForm_DB" (generalmente llamado "nombreTablas"). Se refiera exclusivamente a tablas coyo contenido se va a mantener (es decir tablas sobre las que se hace inserción y/o edición), no a tablas que se usan en la cunsulta.
- David: Si se lleva a cabo es relajación, simplificar el tercer parámetro del addMatching, haciendo que sea opcional siempre que el segundo parámetro incluya nombretabla.campo o aliastabla.campo (tener en cuenta que puede llegar a usarse el nombre del esquema de BD, nombreesquema.nombretabgla.nombrecampo). Algoritmo:
- Si el tercer parametro es vación:
Entonces explode sobre el segundo para obtener el nombretabla (o esquema.nombretabla) y el nombrecampo
Las variable internas se "inicializan" como toca y es portable hacia atrás.

Portabilidad: Propuesta de script/expresion regular que realice la migración de forma generl, dejando el tercer parámetro ANULADO. Esta opción facilita a futuro la incluisón, o el uso de un nuevo "tercer parámetro" que incluya condifciones sobre la forma de utilizar el matcheo (like vs =, o alternativvas abiertas a arrays de valores min/max, inclusiones con clausulas in, <, >... etc) (este nuevo tercer parámetro podría ser un objeto de una clase "gvHidraClause" que permitirse flexibilidad total en casos concretos para que el modo consulta del panle NO sobrecargase el campo que tuviese asociado información de ese tipo).

Pues eso...