<><> CHANGELOG DIA 25/01/2015 <><>
Por fin le he puesto cara a la aplicación, gracias al WindowBuider Pro, el cual es también Software Libre, y haciendo algunos ajustes he logrado obtener la vista principal de la aplicación. Como el tema de Swing es horroroso, y el tema de GTK no se si será compatible con Windows, así que intentaré con tiempo, que dudo que vaya a emplear simplemente en la apariencia, a hacer un tema exclusivo de InformaT.
Las clases base del MVC no he tenido que tocarlas al diseñar esto, lo que me está convenciendo cada vez más que los cimientos de la aplicación son ya sólidos, es más, llegué a plantearme modificar el array de elementos de la Vista por un array de dos dimensiones para reflejar composiciones entre elementos Swing, pero al final un array simple de elementos era más que suficiente, lo que terminó de despejar mis dudas sobre la efectividad de la estructura de mi MVC.
<><> CHANGELOG DIA 10/01/2015 <><>
2015, vaya, tengo que acabarlo antes de que lleguen las generales de este país, ya que ese era el objetivo que me plantee dese el principio, así podría crear una comunidad que se encargase de hacer uso de sus contenidos y actualizarlos, así como tratar de contactar con los distintos partidos, informándoles de una nueva herramienta que permita a los ciudadanos conocer mejor a sus partidos y a sus miembros de una manera tanto profesional como personal. Espero que no haya algún segmento de las reglas del concurso que prohíba hacerlo, tendré que revisar.
El código es ya una tómbola, como la canción. No sólo me he cargado el javadoc, y las clases de usuario, sino que creo haber desglosado con más precisión la conexión de las clases principales del MVC, en las cuales el controlador principal sólo es una formalidad enfocada a simplificar el código. He tirado por la borda todo Processing, ya que me parecía ridículo usar un runtime de un app entera para leer XML, y lo he sustituido por el DOM de java, que confío que como viene incorporado dentro de OpenJDK será también de código abierto. Al principio la sintaxis me parecía un petardo que no había por donde cogerlo, pero al final tras importar un escuadrón de librerías y contemplar el mecanismo me di cuenta que en realidad era muy parecido al sistema que usaba Processing.
Y, mira tú, como buen pardillo estaba tratando de codificar el swing de las vistas a mano, hasta que mi profesor de POO me dijo que las IDE tenían generadores de código de vista. Me cago en todo.
<><> CHANGELOG DIA 29/12/2014 <><>
He generado por fin el javadoc, sólo falta rellenar con explicaciones, las cuales he sacado de los códigos fuente de la aplicación.
Igual en Changelogs anteriores me se había subido el optimismo a la cabeza acerca de cómo de listas estaba las clases que conformaban el sistema mvc, pues hoy mismo he tenido que arreglar la encapsulación y la clase de eventos del mismo, así que ahora sí que la veo lista para ir al siguiente nivel, y el que más me aterroriza y apasiona: el diseño.
¿Porqué me aterroriza si me gusta tanto? Porque para hacer esta aplicación digna del concurso al que la presento no sólo tengo ahora que realizar el trabajo técnico de las planeadas tres personas, sino el creativo; convertir en un éxito una aplicación de un tema del que el 50% 70% de mis usuarios huye. Mis mayores enfoques han sido estos programas:
http://www.rtve.es/noticias/elecciones/generales/programas-electorales/ http://lab.rtve.es/noticias/resumen-programas/index.html
Y éste otro:
Y aparte de una tarea de centralización, hay que innovar. Hay que centrarse en la teoría de los grupos sociales que representan colectivos, y "disfrazar" la app como una especie de red social, y personalizar al máximo, y de la manera más anónima posible, los eventos al gusto del usuario, lo que implicaría ir de puntillas en la línea de la ley de protección de datos.
Desde el primer momento supe que esto iba a ser un reto profesional y personal, así que sin más dilación me pondré con un diseño cuya descripción merezca otro changelog.
<><> CHANGELOG DIA 26/12/2014 <><>
Los eventos están empezando a encajar como un puzzle ahora que he definido bien las funciones de cada modelo. Sólo me falta definir el comportamiento de las clases principales del MVC ante la llegada de un evento, de modo que el Controlador haga el desglose adecuado del ActionCommand para recibir adecuadamente la vista en la que se ha efectuado el evento de Swing, luego cuando recoja el evento de registro de la vista obtenga sus componentes y los registre para escuchar esos eventos de Swing.
El modelo recibirá la vista y la acción y ejecturará una búsqueda de árbol descendente hasta localizar el evento origen de la vista, en el cual una vez se hayan hecho las operaciones oportunas con la base de datos XML, se parsearán las modificaciones a un array de String y se enviará junto con el identificador del modelo a la vista principal, la cual hará el mismo tipo de búsqueda y con el String y algunos flags en cada String indicando si el elemento es nuevo o reemplaza a a otro, se actualizará la vista, y enviará los nuevos elementos que se hayan podido crear al actionlistener del controlador.
Una vez implementado eso, considero que el MVC está listo para construir las clases características de la aplicación.
<><> CHANGELOG DIA 24/12/2014 <><>
Tras unos días de aburrimiento, finalmente me he animado a tocar la parte de los eventos; me he cargado toda la herencia de los eventos. Motivo: en un principio pensaba que, por razones de peso, almacenar únicamente los datos a enviar en el evento mejoraría la eficiencia.
Pero después de una observación de la clase EventObject, me he dado cuenta de que todos los eventos de Java se crean con el objeto emisor, y mediante el método getSource() se establecía un "puente lógico" entre los objetos que permitía al receptor obtener toda la información que necesite del emisor.
Pensado en esto, he modificado el método agregarEmisor() y lo he establecido como constructor, ya que no voy a tener nunca más de un emisor, y nada de crear eventos sin emisor, muy estúpido por mi parte.
Luego hice que los objetos MVC principales se enviaran mensajes por pantalla, como si estuviesen hablando, llamado desde InformaT para asegurarme que no me había equivocado. Una vez terminado el mensaje, el modelo enviaba a la vista, la vista al controlador, y el controlador al modelo. Un StackOverflow muy gracioso por despistado xd.
Ahora a hacer la documentación de estas clases. Creo que no voy a hacer un JAVADOC de momento, y voy a recurrir al comentario.
<><> CHANGELOG DIA 21/12/2014 <><>
Considerando las opciones gráficas de processing, lo mejor es hacer un híbrido, usando Processing para cargar XML y hacer operaciones cliente/servidor sobre la clase modelo, y usar swing para la clase Vista, no parece hacer conflicto alguno entre ambos así que va bien.
Además, he redefinido la forma de conectar las clases principales al MVC, y he desligado la instancia principal de Processing, que reservaré exclusivamente para operar con modelos, así como la Vistaprincipal y ModeloPrincipal, encargados de iniciar la aplicación.
Antes de avanzar en complejidad en la aplicación, tengo que hacer dos cosas; definir el javadoc de las clases que tengo, y establecer cómo voy a diseñar los eventos de Modelo, Vista y Controlador.
Por fin presiento que la aplicación ha pasado la fase de scratch y tanto mi mentalidad como la aplicación está empezando a tomar forma.
<><> CHANGELOG DIA 20/12/2014 <><>
Al final he decidido que la conexión del MVC se resuma en una clase con elementos estáticos de las clases base de la aplicación, de modo que la búsqueda de modelos y vistas será de manera ascendente en la relación de composición y usando el identificador para localizar el elemento en cuestión.
Además, finalmente me he decantado por Processing, siendo éste mucho más sencillo y flexible que Swing a la hora de diseñar interfaces, donde draw() es el hilo principal de la aplicación, el cual conecto a MVC para dar servicio a todos los elementos del MVC, de manera muy parecida al sistema que usé el primer día que subí este changelog.
Parece ser que, dado el grado de interés de mis compañeros, al final soy sólo yo el que va a hacer esta aplicación, por lo tanto espero que sea posible realizar esta aplicación con la misma calidad que esperaba cuando contaba con tres personas.
<><> CHANGELOG DIA 17/12/2014 <><>
El MVC, y por tanto lo que hay de aplicación, se ha rediseñado para incluir eventos caseros, más intutivos, y que son independientes de mi decisión final entre el uso de swing o processing. Este ya es el modelo definitivo.
Además, he cascado los comentarios de documentación, que reservaré para el JAVADOC, y para separar atributos, constructores y métodos he incluido comentarios que los agrupan por funciones.
Aún desconozco si mis compañeros de clase van a participar, ya que no he recibido confirmación de ningún tipo, espero tener la respuesta mañana.
<><> CHANGELOG DIA 12/12/2014 <><>
Mediante una conversación sobre el diseño de las clases padre que van a controlar la aplicación, decidí remodelar la estructura de las mismas. Al igual que en el changelog anterior, no tengo desarrolladas más que la instancia de Processing que crea la aplicación y el SINGLETON que encapsula esa instancia para ser usada por el modelo MVC y sus clases hijas. Una vez más, favor de no valorar.
<><> CHANGELOG DIA 3/12/2014 <><>
He metido los diseños de la aplicación en /doc, y en /lib están las librerías de Processing.
He desarrollado en /src sólo Processing y ClaseProcessing para asegurar compatibilidad total con el modelo de aplicación MVC y su correspondiente desglose, únicamente para asegurar que podría desarrollar semejante pedazo de proyecto con las herramientas que propuse.
Favor de no valorar, ya que ha sido hecho fuera de la etapa de desarrollo.