segonzal / jEdit-CC4401

0 stars 0 forks source link

Plugins y trabajo en conjunto son exluyentes? #11

Closed nsdelgadov closed 10 years ago

nsdelgadov commented 10 years ago

Abro la discusión antes de que sigamos trabajando. Si hacemos plugins por separado, de todas formas debemos dejar algo Común para que sea fácil extender el resto de alguna forma o no?

joseo commented 10 years ago

En #8 he donde iba esta discusion

nsdelgadov commented 10 years ago

@agoni08 " Si todos vamos a utilizar un visualizador global debieramos tener en cuenta como hacerlo. Revisen el patron Factory o Abstract Factory. Seria la manera mas "limpia" de implementarlo. Igual seria bueno decidir si vale la pena, porque a lo mejor no hay manera sencilla de exponer una interfaz comun para plugins independientes, y tener una clase o modulo compartido para todos a lo mejor nos expande por gusto el impacto de un cambio en esa dependencia comun. Posteo esto aqui y en el otro hilo pero vamos a discutirlo en un solo lugar. :) "

nsdelgadov commented 10 years ago

@yo "+1 a angel, dentro de las observaciones que dejé ne la wii, están que podríamos hacer algo para que los plugins no se pisen, que sería después de hacer funcionar cada uno. Pero debemos tener en cuenta esto al implementarlos con un patrón de diseño como el que menciona angel."

nsdelgadov commented 10 years ago

@alopezq "ojo q si se leen la api de los plugins la gran gracias es q no se pueden pisar es decir cada uno trabaja por si solo. lo que si puede suceder es que cada uno de los 3 plugins tenga codigo muy similar o repetido pero es imposible librarse de el dado que si queremos tener 3 plugins por separado cada uno tiene que ser capaz de funcionar por si solo"

nsdelgadov commented 10 years ago

@agoni08 "

@alopezq a eso me refiero. La pregunta es:

Es posible crear un modulo que fabrique visualizadores y desde el plugin lo podamos consumir??? En este caso es factible usar un codigo unico, pero cualquier cambio a la fabrica de visualizadores impactaria en cada uno de nuestros plugins. O sea piensen en esto como una libreria utilitaria que se importaria en los plugins, pero que sera un componente transversal de cara al desarrollo.

Si eso no funciona o es muy complicado, la cosa seria crear un codigo generico que todos "cortemos y peguemos" en nuestros plugins y que sera modificado segun nuestras necesidades.

Esto depende de como querramos ver nuestro proyecto, si cada issue se gestiona como un subproyecto por separado no seria un problema (de hecho soy partidario de la ultima alternativa, me parece menos trabajosa). "

nsdelgadov commented 10 years ago

@joseo "

Respecto a lo que indica @agoni08, pareciera ser lo ideal (no habría duplicación de código), pero habría que hacer un nuevo Análisis de impacto y una "circugía" a jEdit, agregando la o las clases nuevas.

Lo que dice @alopezq permitiría comenzar a trabajar más rápidamente (no sería necesario coordinar clases en común ni intervenir jEdit directamente), pero generaría duplicación de código.

¿Qué tan grave sería la duplicación de código? Creo que el fin de los plugins es justamente no intervenir el código de jEdit, pero igual suena tentador hacerlo."

agoni08 commented 10 years ago

Creo que estamos hablando de lo mismo pero el lenguaje natural nos hace difícil entendernos. Nico, por favor, mueve este comentario a donde se vaya a quedar la discusión final :D. Siempre trabajaremos en conjunto lo que necesitamos decidir es el enfoque. Lo que estaba preguntando en el otro issue era el como seria mejor hacerlo.

Yo prefiero que desarrollemos en común un visualizador suficientemente genérico para que podamos usarlo todos pero que no sea un framework que heredemos/importemos todos sino un snippet de código que podamos modificar en nuestros plugins sin afectar a los demás.

Si fueramos a generar un framework (como la idea del patrón) seria algo como esto:

Class VisualizationFactory

-atributos que definan propiedades de la interfaz -Metodos que provean acciones sobre la interfaz

Class PluginGraphviz -Objeto de tipo VisualizationFactory (permite hacer las acciones sobre la interfaz que implementemos en su clase)

Si se fijan aquí todo el código del visualizador esta encapsulado en su clase factory que permite simplificar el desarrollo de los plugins, pero cualquier cambio a la nueva dependencia afecta a todos los plugins. Además cada vez que un plugin requiera una nueva funcionalidad visual, tendría que ser agregada como método a la clase VisualizationFactory.

Me hice entender ahora? No me quedaba claro a mi que queríamos hacer cuando hablaban de "trabajo conjunto" y quise exponer las soluciones mas evidentes que me vinieron a la cabeza. :)

nsdelgadov commented 10 years ago

El "trabajo conjunto" es lo común a todas las funciionalidades que queremos agregar. Sobre el tema de la issue, creo que podríamos hacer lo que es más rápido, trabajar por separado y cuando tengamos mejor ideas de qué cosas tocar (código) nos dará una mejor idea de como Refactorizar nuestra solución a una más genérica, bella y digna de mostrar. Esto tiene el contra del code smell, y que después de mplementar cada plugin por sí solo habría que hacer un refactoring que quizás sea muy grande, pero trabajando por separado, podremos saber si hay algun plugin más dificil que otro, si es realmente útil hace algo en conjunto, etc. Hago notar que a pesar de estar trabajando por separado, creo que es necesario aportar en un documento qué cosas se podrían refactorizar después y que al repetir código, lo más probable es que se repita trabajo si no hablamos, por lo que debemos mantener una alerta a los demás cada vez que trabajemos en algo que tiene pinta de ser común. ;tldr : Trabajemos por separado, pero teniendo en cuenta las pegas de los demás y refactoricemos después.

joseo commented 10 years ago

Examiné el código de un plugin que crea un panel anclado, y creo que no vale la pena hacer en común el tema, debido a un posible "code smell" (duplicación de código).

El código (simplificado) que agrega el panel anclado, hace sólo:

splitter.setLeftComponent(new JLabel("hola mundo")); splitter.setRightComponent(child);

Dónde:

Hay algunas líneas más, pero son declaraciones y otras formalidades.

El resultado es (NO es una "maqueta"):

6enbvb5pe4jw

Y voilà. ¿Qué opinan?

nsdelgadov commented 9 years ago

Se cierra discusión al mostrar el uso de los plugins y las facilidades que entrega jEdit para integrarlos sin hacer "cirugia" (cre´ditos por la frase a @joseo )