Refactorizacion de CIs (Junio 2005)
El motivo principal de la refactorizacion fue evitar las generalizaciones anidadas que se estaban dando dentro de la jerarquia. El comportamiento grafico se habia modelado con herencia y surgieron ramificaciones asociadas con el modulo de persistencia que suponian hijos equivalentes en distintos miembros de la familia. La refactorizacion ademas simplifica la futura creacion de editores e instanciadores para las clases.
Los que esten interesados en como se desarrollo la refactorizacion: source:branches/ci_abms
Esta actividad corresponde a una parte del trabajo definido en: Ver paquete
Resumen de modificaciones
- Los CI que pertenecian a la clase objeto_ci_me_tab ahora pertenecen a la clase objeto_ci, pero tienen seleccionado en su definicion el tipo de navegacion "TAB horizontal"
- Lo que antes era llamado "etapa", y era exclusivo de los objeto_ci_me en adelante, ahora se llama "pantalla" y existe para todos los CI. Para posicioner un objeto_ei graficamente dentro de un CI, es necesario dar de alta una pantalla.
- Los CI que estaban asociados a un CN ahora tienen que heredar de la clase "ci_cn", localizada en $toba_dir/nucleo/browser/subclases/ci_cn.php
Conversion
La refactorizacion implica conversion de metadatos. Se adjunto un script nuevo "conversion" (Ver script). El mismo funciona de la siguiente manera
conversion 01 toba
Esto crea el script correspondiente a la conversion 01 para la base "toba". Si se desea ver el script preparado, hay que ejecutar:
conversion mostrar
Por ultimo:
conversion run toba
ejecuta el script generado sobre la base "toba".
La forma de ejecutar la conversion es la siguiente:
- Exportar los proyectos a convertir y subirlos a su repositorio.
- Es recomendable no incluir en la instancia cualquier proyecto de cuya conversión no somos responsables (por ejemplo en mi caso, tengo que borrar comechingones y esperar hasta que el grupo de desarrollo lo convierta). Esto es porque no queremos convertir proyectos de 3eros, puede traer conflictos posteriores. La forma más sencilla de hacerlo es sacar el proyecto del directorio proyectos
- Hacer un UPDATE del toba. Tube que regenerar la instancia también..
- Ejecutar el script de conversion sobre la base del proyecto.
- Exportar el proyecto.
- Regenerar la instancia.
- Corregir el codigo PHP del proyecto (extension de clases).
- Commit del proyecto.
(NOTA: Es posible que el sql de conversion generado este mal (no es perfecto, pero el impacto de esta refactorizacion deberia darse sobre tan pocas implementaciones que no lo depure hasta la perfeccion), en ese caso, antes de ejecutar el paso 2, hay que editarlo segun los errores que aparezcan (Los cambios estan en una transaccion, asi que hasta que todo no ande bien, no va a pasar nada). El mismo se encuentra en $toba_dir/bin/entrada/conversion/01/conversion.sql)
La conversion necesita tambien modificar codigo fuente. Como las clases objeto_ci_me y objeto_ci_me_tab no existen mas, es necesario reemplazar los encabezados de las clases que las extiendan. Las mismas tienen que apuntar a la clase objeto_ci o ci_cn en el caso que utilice un controlador de negocio.
Comentarios
- Muy bueno el refactoring!
- Los CI simples que no tenian CN se convirtieron a ci_cn, ¿es un error?
- Como hasta ahora todos los CIs suponian un CN, por las dudas los mapee todos al 'ci_cn' para que no haya problemas, era imposible saber si las subclases lo utilizaban o no...
- ¿Porqué 6 parametros en la definición básica de un objeto? ¿Ese formulario tiene que pasar a ser un ML no?
- Las subclases del CI encargadas de manejar db_registros necesitan esa cantidad de parametros (el dao del cuadro y el dbr que utilizan). Es una necesidad urgente un nuevo editor de CIs. Los parametros exclusivos de alguna subclase puntual deberian estar en un tab aparte de la definicion estandard del CI.
