No me agradaba tener ese metodo para solo 3 funciones que lo usaban, y
de todas formas, estas funciones necesitaban los datos de manera
distinta por lo que no era tan util en realidad
Para lograrlo se realizo el mismo procedimiento que con el informe de
libro de ventas
Primero que nada se elmino el objeto de InformeEgresosContent que se
tenia porque realmente no aportaba nada, era basicamente lo mismo que el
objeto egresos con un campo de fecha añadido y creo que un campo menos.
Por lo que se paso a utilizar el objeto de Egresos directamente.
Debido a lo anterior no era necesario tener una query especial para
juntar los datos, ya que solo eran los egresos de todas las cajas de un
tipo en especifico, por lo que solo se hizo una query nueva en el
EgresoDAO en el que se satisfacia esta necesidad.
Luego fue solo hacer compatible el InformeEgresosToExcel y listo!
Primeramente, se tenia por objetivo reescribir el informe para que este
fuera mas claro y para lograrlo se penso en que en vez de realizar 2
querys grandes en las que se tomaban todos los datos necesarios y se
mapeaban un objeto el cual se añadia a un array, se realizaran
multiples querys separadas, en las que se irian obteniendo los datos
individualmente y sean juntados en un objeto.
Para esto se debio reescribir parte de SQLiteIngresoDAO, por una parte,
para añadir las querys que obtenian los numeros de boletas y de Z en una
caja para un tipo de ingreso en ademas de la query para obtener el total de
ingresos por un tipo de ingreso en un mes.
Junto con esto, al toparme con un bug, reescribi el como se realizaban
las querys en todo el objeto DAO, dado a que creia que se debia a un
problema donde no se estaban cerrando bien los ResultSets y los
PreparedStatement, aunque al final no fue eso y era simplemente el que
no habia un resultado en la query que se habia realizado.
A partir de aca no sabria bien como describir lo que se realizo, pero se
puede resumir en que encontre redundante el tener 2 paquetes de informe
y un objeto DAO para generar el informe cuando realmente no lo era,
siendo mas un "builder" creo .w.
Por lo que separe todo eso y lo deje en 3 objetos, el LibroDeVentas, el
cual contiene la instancia de un dia de informe, el InformLibroDeVentas,
el cual es un wraper para un hashmap que contiene el libro de ventas y
ademas tiene el metodo que genera el libro, y finalmente el
InformeLibroDeVentasToExcel, el cual pasa el informe a un archivo excel
para la lectura del usuario final.
Finalmente separe el que se guardara el informe automaticamente al
generarlo. para ello cree un objeto aparte, el cual tendra metodos
estaticos para todos los objetos que tenga que guardar eventulamente,
por ahora como solo necesito guardar un Workbook, eso es lo que guarda.
Creo que eso seria todo :3
Como consecuencia esto llevo a modificar otras clases que la utilizaban
ya que se decidieron cambiar un par de cosas en su API
- Quitar el que los metodos de update e insert retornaran un booleano,
realmente no era algo necesario y no se estaba utilizando.
- Remplazar el retornar una Caja por retornar un Optional<Caja> en los
metodos de getByFecha y getById, con el fin eliminar un poco los
chequeos de nulls
- El metodo de cajasFromResultSet fue eliminado ya que no lo veia
necesario ya que operaba generaba una List con las cajas obtenidas por
el ResultSet y los de los 2 metodos que la invocaban, solo uno de ellos
necesitaba una lista, el otro solo obtenia el primero de la lista y
continuaba.
- Cambie el necesitar un LocalDate en el metodo que genera las cajas
para un mes, por un objeto con logico para esta situacion, el cual es
YearMonth, esto tuvo como consecuencia la mayoria de los cambios fuera
de esta clase.
- Renombre los metodos para que tuvieran nombres mas agradables para mi,
esto es lo otro que hizo cambiar muchas otras clases.
Se habia olvidado hacer previamente
Junto con esto se eliminaron las funciones que generaban los headers y
footers y ahora se hace ese proceso en las funciones que generan cada
seccion.
Se separaron estos metodos para mayor claridad en el codigo y mas facil
reutilizacion de los dialogos ya que ahora me vi en el caso de que me
encontraba utilizando estos metodos en 2 vistas separadas y me vi
copiando los metodos de una a otra, pero eso no es bonito! asi que las
separe en clases con un solo metodo publico llamado execute el cual
devuelve el objeto que se espera recibir o un null en caso de que el
usuario cancele el dialogo o ocurra algun error.
la clase responsable cambio de nombre a configuration y ahora tiene un bloque estatico que inicializa el objeto properties y expone el get de este objeto
