🚀 go-pugleaf

On 8 abr, 12:55, Ricardo Palomares Martinez <rpm.PU...@iespana.es>
wrote:

> Yo no llevo mucho tiempo, así que aquí no puedo darte mucha
> información. Sí te puedo decir que me hice cargo de un proyecto
> open-source basado en Java 1.4 y de momento lo he compilado con Java
> 1.5 sin problemas; ahora lo probaré con la 1.6. También sé que, cuando
> cambian algo, lo que suelen hacer es marcar la manera vieja de hacerlo
> como "deprecated" y la mantienen al menos una versión para dar tiempo
> a cambiarlo. Pero, como te digo, no tengo mucha experiencia, y podría
> ser que otras personas con más experiencia te cuenten casos en los que
> no haya sido así.

En cualquier caso, no creo que llegue a la locura de MS. Ya tengo una
edad en la que no quiero volver a redisenhar nunca mas un proyecto
grande.

> Ahora mismo, las opciones son dos en la práctica: Eclipse y NetBeans.
> También hay otros, como JDeveloper (de Oracle, gratuito, creo) e
> IntelliJ (de pago), pero son más bien nichos de mercado. JBuilder está
> muerto en cuanto a desarrollo, por lo que sé, y Sun está convirtiendo
> NetBeans en el IDE de referencia; hasta en los tutoriales genéricos de
> Java lo usan para explicar muchas cosas.

De los que he visto, el que mas me ha gustado ha sido NetBeans. Tenia
mis dudas, porque cuando estas comenzando dependes por completo de la
ayuda sensible al contexto, pero ya ese punto esta resuelto.

Me acabo de instalar el plugin de UML.

Y desde que pregunte ayer hasta ahora, he encontrado una cantidad de
soluciones que me hacen estar mucho mas satisfecho con el.

Creo que no voy a buscar mas, al menos hasta que no tenga un buen
motivo. Lo importante ahora es parender el lenguaje, y eso es lo unico
que deberia preocuparme.

¿Como agrego un archivo fuente preexistente a un proyecto en NetBeans?

> ¿Es realmente indispensable? En modo alguno. ¿Hay dificultades no
> evidentes? Si vienes del mundo MS, puedes encontrar algunas. En Java
> no existen los controles gráficos "data aware". Es decir, pones un
> ComboBox en un formulario y, a diferencia de lo que tenía VB la última
> vez que lo miré, no tienes un par de propiedades con las que decirle
> que recoja su contenido de una consulta SQL o tabla de una base de datos.

Nunca use controles enlazados a datos en VB (es la clase de cosas que
contribuyeron a la justificada mala fama del lenguaje: al final,
resultaba mucho mas complicado controlar en detalle la conducta de los
controles enlazados que aprender a manejar las teconologias de acceso
a datos de manera directa).

> Aparentemente, no hay discusión posible: si no usas un ORM, estás
> muerto. En cambio, yo de momento no quiero usarlo. :-) ¿Por qué?
> Porque, a mi juicio, el ORM oculta tanto de JDBC que siento que pierdo
> el control de si los objetos con los que trato en el programa afectan
> a los datos en la base de datos o no. Introduce, además, un montón de
> conceptos nuevos, y como soy un poco novato, ya me sobran conceptos
> que asimilar.

Al final, en el modelo de objetos, tiende a haber una relacion 1-1
entre cada tabla de la BD con una clase del modelo.

Hay clases que incluyen agregados (por ejemplo, un documento con
detalles). Pero en estos casos, cada tipo de detalle es una clase en
si. Es simple manejar la agregacion mediante una funcion que te
devuelva una coleccion, lista o como se llame en Java con los
detalles.
Aunque entiendo su sentido, no me parece que la utilidad del ORM sea
tanta como se le atribuye.

> Así que yo, particularmente, de momento no quiero usar un ORM. Si te
> haces muy deprisa a Java, y dado que tienes mucha más experiencia de
> trabajo con OOP, quizá te lo debas plantear.

No, no creo.

Me preocupaba que la complejidad de usar directamente JDBC desde las
aplicaciones fuera demasiada, pero al final es mas o menos la misma
que la de ADO en el mundo de MS.

> Depende de si cada ventana tiene procesos interactivos que requieren
> cierto tiempo. Por ejemplo, si en cada ventana se cargan
> constantemente imágenes actualizadas desde una web que se bajan
> comprimidas y hay que descomprimirlas con su coste de CPU antes de
> poder mostrarlas, probablemente quieras varios threads, porque si no,
> lo más fácil es que una de ellas funcione constantmente mientras la
> otra se queda bloqueada. Pero, seguramente, esos threads no se usarán
> realmente para pintar las ventanas y responder a pulsaciones en los
> botones que contengan, sino para recuperar los datos de Internet,
> descomprimirlos y asignarlos a los controles gráficos de las ventanas.

Imagino que mi solucion sera abrir cada frame "superior" de la
aplicacion en su propio thread (no tengo dependencias entre frames:
esa fue otra de las cosas que contribuyeron a desprestigiar a VB), y
permitir que cualquiera de ellos se bloquee mientras dura alguno de
los procesos largos que deberan ejecutar (es lo que debe pasar). Esos
debera permitir que el resto de los frames sigan respondiendo a
eventos correctamente.

Bueno, ahora a seguir experimentando.

Muchas gracias, y nos seguiremos viendo.


Salud!