Convenciones sobre personalizaciones

Buenas! Acudo nuevamente al querido foro ya que tengo una pequeña duda sobre personalizaciones.
Queremos, antes de empezar con las nuevas personalizaciones, crear algo así como un documento de convenciones a la hora de nombrar los nuevos ítems, ci, cn, clases y demás componentes que aparezcan. Lo más parecido que encontré hasta ahora es este artículo http://portalguarani.siu.edu.ar/trac/Portal-G3/wiki/NotasTecnicas/ejemplopersonalbasic

Si bien entiendo parcialmente los estándares que propone, no me queda claro si este sistema de sufijos se aplica solo a ítems clonados y clases heredadas o si se aplica también a personalizaciones nuevas que no tienen nada que ver con componentes de Guaraní ya existentes.

Para resumir, la convención sería:
Nombre operaciones: Nueva operación - UNQ
Nombre CI,CN: Nuevo controlador de interfaz - UNQ
Clase CI,CN: ci_nuevo_controlador_interfaz_unq.php
Nombre del resto de los componentes: pantalla, cuadro, filtro, form
Clases de extensión del resto de los componentes: pantalla_nueva_unq.php, cuadro_nuevo_unq.php, form_nuevo_unq.php

Cualquier adición o corrección a estos estándares será bienvenida, gracias!

Hola Pablo,

Antes que nada, te comento que estamos revisando y actualizando la documentación de personalizaciones que se entregará con la versión 3.11.0, próxima a salir. Los cambios que vamos a plantear tienden a simplificar el trabajo del día a día, pero siempre teniendo en cuenta que lo que presentamos son recomendaciones. Las instituciones que están trabajando siguiendo otro estándar bien pueden continuar con su metodología o sumarse a las nuevas propuestas.

Te anticipo algunas cuestiones en línea con tus preguntas. Todo lo referido a convenciones de nombres que podés encontrar en la documentación son recomendaciones a seguir para minimizar los conflictos de nombres entre las clases de ustedes y las que distribuimos nosotros, buscando poder identificar unívocamente a los objetos y clases para evitar posibles “colisiones” ante nuevas funcionalidades liberadas.

Es por dicha razón que recomendamos colocar un sufijo a las clases de extensión PHP y nuevas carpetas. En el caso de las instituciones que se sumen a personalizar de ahora en más, vamos a recomendarles prescindir de la carpeta con el nombre del nodo en “personalizacion/php” (en el caso de ustedes, “personalizacion/php/unq”), donde deberían recrear la estructura de carpetas del SIU. Pueden ubicar directamente sus clases en “personalizacion/php/nucleo” y “personalizacion/php/operaciones”, contemplando que, en caso de crear una nueva carpeta (no existente en la estructura que distribuimos nosotros), deberían colocarle el sufijo institucional.

Con respecto a todo lo que se le presente al usuario, como por ejemplo los nombres de los ítems (operaciones), títulos de los elementos de interfaz, etiquetas, etc, no sería conveniente marcarlo con un sufijo (ej: Nueva operación - UNQ). A pesar de que existan personalizaciones, el usuario final debería percibirlo como un todo homogéneo.

Si están confeccionando un documento interno, y desean que le demos una mirada a la versión final, cuenten con nosotros.

Saludos,
Fernando

Buenísimo Fernando. En base a lo que me decís voy a terminar de definir el documento con las convenciones que deben seguir nuestros desarrolladores. Ni bien lo tenga listo se los paso. Gracias!

Buenas. Siguiendo con el mismo tema. Estábamos pensando que nombres ponerles a las nuevas tablas que tengamos que crear. En principio la idea sería ponerlas en un esquema nuevo llamado guarani_pers. Después en cuanto a los prefijos queríamos usar los mismos que el Guaraní (sga, mdp, etc), pero nos surgía la duda del significado de cada uno. Lo busqué en la documentación pero no tuve demasiada suerte. Lo tienen documentado en algún lado que puedan compartir? Gracias!

Podes encontrar los siguientes prefijos de las tablas:

select distinct(left(tablename,4)) from pg_tables where schemaname = 'nombre_esquema' order by 1

acc_ = Tablas del módulo de acceso al sistema
adm_ = Tablas del módulo de administración del sistema
app_ = Tablas relacionadas con la aplicacion - versionado
gde_ = Módulo gestion de encuestas
gdu_ = Gestión de usuarios - permisos
his_ = Tablas de datos historicos
int_ = Tablas de interfaces con otros sistemas
mce_ = Módulo de circuito de egreso
mdp_ = Módulo de datos personales
men_ = Módul de mensajeria
mug_ = Módulo de ubicación geográfica
not_ = Módulo de noticias
par_ = Parámetros del sistema
sga_ = Sistema de Gestion de Alumnos
tmp_ = Tablas temporales…

Mas alla que uses estos prefijos, te diria que uses como prefijo la sigla de la institucion, que se corresponde con el que esta en el nodo de tu institucion en el sitio colab.siu.edu.ar.

Ejemplo:
unq_docentes
unq_alumnos
unq_alumnos_promedio

Esto te garantiza que:

  • Tengas ordendas las tablas y poderlas ubicar todas juntas
  • Garantizar que el nombre no existe en otra tabla de otra institucion o del SIU.
  • Poder compartir personalizaciones con otras instituciones sin que le traiga problemas por duplicidad de nombres en tablas de la institucion.

Esto es válido tambien para los otros objetos de la base como ser: funciones/triggers/procedures/fk/ck/vistas/tipos de datos/etc…

Podes ubicarlo en un esquema a parte por si queres tener mas organizado las tablas personalizadas.

Hola Pablo,

Extiendo la respuesta de Alejandro para pasarte una documentación, que tal vez te pueda servir en caso de necesitar extender una tabla del modelo estándar.

En este caso, podrás ver que si necesitás extender una tabla nuestra, sugerimos que la nueva tabla (dentro del esquema_pers) tenga como nombre <nombre_tabla_siu>_unq. Tomen la precaución de no repetir el mismo nombre en el campo PK de la nueva tabla, respecto del original, para evitar problemas luego con el Datos Tabla de Toba.

Por ejemplo, si tenés que extender mdp_personas, tu nueva tabla sería mdp_personas_unq y el campo clave persona_unq.

Saludos!
Fernando

Gracias por las prontas respuestas chicos. Cual creen de las dos alternativas es la mejor?
Yo me inclino más por crear un esquema nuevo ‘negocio_pers’ y ocupar allí las tablas nuevas. Ahora, que pasa si en el mismo esquema tengo tablas extendidas y tablas nuevas independientes? Quedaría algo como:

negocio_pers
---- sga_comisiones_unq
---- unq_sga_tabla_independiente

O, tal vez, así:

negocio_pers
---- sga_comisiones_unq
---- sga_tabla_independiente_unq

Qué dicen, cuál les parece más limpia?

Saludos

Por otro lado, estar usando un esquema diferente me puede traer problemas también.
Acabó de chequear que para crear gatillos para los perfiles de datos el toba levanta solo un esquema, no los dos.
Eso nos va a traer problemas, porque es algo que vamos a necesitar seguro en nuestras tablas.

Hola Pablo,

Con respecto a las nomenclaturas, es una convención que pueden fijar ustedes. Si yo tuviera que definirlo, preferiría esta alternativa:

---- sga_comisiones_unq
---- unq_sga_tabla_independiente

porque presenta la ventaja que te permite distinguir a simple vista las tablas de extensión de las tablas nuevas.

En relación a la última consulta, te pediría si nos podés ampliar el uso que le darían a las nuevas tablas en cuanto a perfil de datos, para analizar bien el caso.

Gracias!
Fernando

Sí, tenemos una personalización que básicamente implica la gestión de una entidad nueva cuya relación con el Guaraní es la tabla sga_propuestas. Tenemos la duda de si vamos a poder crear o no los gatillos para esta nueva entidad si las tablas están en un esquema nuevo. Saludos!

Hola Pablo,

Si observás la composición de la dimensión “ug” en la solapa “Datos” del Editor, podrás ver que tanto la tabla “sga_propuestas” como la vista “vw_ug_propuestas” forman parte de los gatillos. Eso implica que al aparecer esas tablas o vistas en las SQLs ejecutadas a través de guarani_db::consultar(…), si la persona está asociada a un perfil de datos, este se activará y se filtrará según corresponda.

Con respecto a tus nuevas tablas, podés ubicarlas en un esquema nuevo, relacionándolas con las tablas del core por las Foreign Keys correspondientes. Si en las SQLs en las que intervengan estas tablas te asegurás de realizar un JOIN con alguna de las tablas o vistas presentes en la dimensión “ug” (en el caso que planteás, sería “sga_propuestas”), evitás tener que personalizarla.

Saludos,
Fernando