Una de las cosas buenas y malas que le puede suceder a un determinado entorno de desarrollo es que cuente con abundantes componentes desarrolladas por terceros. Es una cosa buena porque enriquece el entorno, y es mala porque demuestra que al propio entorno de desarrollo le faltan controles.
La existencia de desarrolladores de componentes de terceros también demuestra que el entorno cuenta con un amplio número de seguidores que hacen rentable que otras empresas o personas – los terceros – dediquen su esfuerzo a completar el entorno con nuevos componentes. Es evidente que no existe la misma cantidad de componentes para Fivewin que para Delphi, por poner un ejemplo, de igual manera que los programadores que usamos Five somos bastante menos que los que usan Delphi.
Cuando comencé a desarrollar software utilizaba muchos de los controles de la extinta CanalFive: su grid, folders, meters y su calendario. Ahora con xHarbour lo único que uso es el calendario, debido a que no he podido – mejor dicho no he sabido – migrar el grid, los folders de Fivewin ya son nativos y toman el aspecto de XP y el meter me dio unos problemas muy raros y decidí no usarlo en Colossus.
Con esto intento plantear uno de los mayores problemas que como desarrollador tiene usar componentes de terceros: que te vuelves componentesdeterceros adicto y te puedes encontrar con problemas de compatibilidad de los componentes al evolucionar el entorno de desarrollo, lo cual se agrava si el desarrollador del componente ha bajado la persiana.
¿ Y porqué bajan la persiana ? … continuará
Jose Luis:
Precisamente nos acaba de suceder algo que da para pensar un poco sobre la conveniencia de usar o no usar componentes de terceros.
Mi buen amigo Israel Solis de Sanroms Software (www.sanroms.com) tiene un bonito sistema de control escolar, que la verdad sea dicha esta muy bien trabajado, vamos, que se lo ha currado el tio.
Utiliza componentes de terceros por un tubo, el Calendarios de CanalFive, la FileXLS, la SSay, la TSbrowse, los TSButtons, etc. etc. etc, todo esto muy bonito, la aplicacion de 16 bits es fenomenal, funciona super estable, pero los problemas comenzaron cuando quizo dar el «siguiente paso».
Quizo primero implementar Cliente/Servidor con Advantage Database Server, y su sistema se basa ampliamente en Browses hechos con TSBrowse, hasta se hizo su propia clase para manejar catalogos basado en el TSBrowse y con un montón de virguerías adicionales, el caso es, que me pidió ayuda para mover su software a ADS, en 16 bits, te parecera increíble, pero nos tardamos 2 días completos tratando de hacer funcionar TSBrowse con ADS profesional y no lo pudimos hacer.
¿ Tan facil como coger el codigo fuente y ponerse a ver donde casca….? ¿ si ?, ja !, ese código fuente no hay Dios quien lo entienda, mas que el que lo hizo (Saludos Manuel Mercado donde quiera que estés), 2 tios con un buen nivel de programación y con amplia experiencia en ADS tratamos y tratamos y de los 2 días que estuvimos viendo eso, un dia completo lo invertimos en tratar de meterle mano al código fuente de TSBrowse y cuando no cascaba en un lado, cascaba en otro, al final decidimos pasar del cliente / servidor (de momento) hasta que hagamos funcionar el TSBrowse con ADS de manera estable.
Bueno, ya que no se pudo migrar a cliente / servidor, pues tratamos de pasar a 32 bits con xHarbour y con FWH, y otro frentazo en la pared: no hay FileXLS para xHarbour 0.91.1, el código fuente no esta disponible, por lo mismo estamos pensando como vamos a sustituirlo, seguramente sera con OLE, pero eso es mas lento que usar la clase para generar hojas de Excel directamente y hay que mover un monton de código, lo mismo ha pasado con el SSay y con los controles de Ramon Avendaño, al carecer del codigo fuente, es dificil migrarlos.
La conclusión: El proximo desarrollo, CERO componentes de terceros, utilizaremos lo que traiga el lenguaje estandar o bien cosas que sabemos que funcionan y que puedan ser portables.
Patrick Mast me lo comentó alguna vez…. nunca uses componentes de terceros gratuitos, nadie te garantiza que existan o que los puedas utilizar en un futuro.
Saludos.
José Luis:
como dice René (ni yo pude haberlo dicho mejor) los componentes de terceros son de GRAN ayuda para complementar los huecos del lenguaje y poder tener un producto como haz planeado… PERO… efectivamente no existen muchos productos para FW, y con la gran ayuda del foro y las aportaciones desinteresadas de muchos colegas logras medio cubrir esos huecos.
Así inicié mi sistema, utilizando desarrollos como tSBrowse, tSButton, FileXLS, etc. mi sistema ha crecido mucho y la obligación y presión de los clientes me han obligado a apresurar la versión de 32 bits y Cliente/Servidor… pero oohh sorpresa, como comenta René, me tope con muchos problemas con estos componentes.
Aclaro que no soy mal-agradecido, al contrario, siempre agradeceré a Manuel Mercado, Ramón Avendaño, etc. todo el apoyo y desarollos que han ofrecido; pero, con toda razón, ellos no están obligados en ningún momento en darles seguimiento y actualizaciones a sus aportaciones (ya han hecho suficiente en obsequierlas).
Pero cuando te decides a migrar a FWH, [x]Harbour o ADS, te das cuenta que marca errores por aquí y por acá y es cuento de no acabar. Pero ¿porqué no lo arreglas? quizá suene simple y abres tSBrowse (un desarrollo que no es tuyo y cuenta con mas de 7,000 líneas de código) te da miedo mover una coma erronea y deje de funcionar lo que ya funcionaba. La FileXLS (una excelente clase) no cuentas con el código fuente y tienes mas de 50 reportes diseñados para ser exporados con esta clase, etc., etc., etc.
Por esa razón he llegado a la conclusión de evitar los componentes de terceros no soportados, los lenguajes de programación y los Sistemas operativos avanzan y mejoran a una velocidad impresionante y no puedes detenerte mucho con tus desarrollos o la competencia se te adelanta demasiado y por esta razón siempre debes intentar estar un paso adelante de ellos.
Sería feliz si contara con un lenguaje en el cual la necesidad de componentes de terceros sea mínima y, si esto es necesario, aceptara controles OCX, COM, etc. (hay millones de ellos)
Nuevamente y para cerrar este comentario MIL GRACIAS a todas las almas caritativas y desinterasadas del foro de FW.
Pero es casi imposible desarrollar aplicaciones con código 100{480d580d36768405d93963bdd82c570c8132a231e8d2b870ef0b18322d1f72b2} propio o con lo que traen los entornos actuales, incluso lo que traen muchas veces no lo ha desarrollado la propia «casa» y en un cambio de versión se van por el aire.
¿Nos haremos cada uno de nosotros nuestro propio generador de listados? ¿Nuestros propios browses, vistas, treeviews?
Yo trabajo con Delphi y me he encontrado con el problema que comentais, no es sólo cuestion de cuanta gente utiliza un entorno, es tambien seleccionar correctamente los componentes que utilizas. Al final me he quedado con unas cuantas colecciones de componentes que veo que van evolucionando con cada versión de Delphi, y sigo una máxima: «Siempre disponer del código fuente del componente». Ya he tenido ocasión de modificar componentes para que se adaptasen a versiones diferentes para las que fueron creados, claro que como comentais, no siempre fue fácil y otras fue imposible.
Salvo grandes compañías que disponen de personal dedicado al desarrollo de componentes, el resto de programadores estamos «condenados» a utilizar componentes de terceros, y lo hacemos para ganar tiempo en el desarrollo de la solución final, lo que ocurre es que muchas veces esa decisión es «Pan para hoy y hambre para mañana.»
Un saludo.
Hola a todos,
Una de las grandes premisas en el programación es la de no utilizar nunca componentes de terceros sin disponer del codigo. Quien sabe q hace de mas ¿ Se bloqueará algun dia ¿ Q pasa si hacemos un cambio de version y no se adapta ¿
Estoy a favor de usar componentes de terceros si hay alguien detras, sino cada uno que se la juegue si quiere. Cuando Jose Luis comenta q usaba la CanalFive, entonces eran lib de pago y sabias q habia un ‘soporte’ detras. Yo recuerdo en su dia haber usado su grid y calendar y un par de problemas q tuve me los solucionaron inmediatamente. Actualmente todas las aplicaciones q desarrollamos disponemos de todo su codigo fuente. Muchas clases de dominio publico las tenemos revisadas y otras de pago, pero nos da una mayor seguridad, el hecho de tener practicamente todo el codigo de la aplicacion.
Israel -> la clase TFileXls esta con codigo fuente con la distribucion de la OZLib de Ignacio, evidentemente fantastica, y decirte q tambien dispones de la mejor clase (para mi) para el manejo de Browse, etc…. Tambien comentarte q cuando dispongas de la extension para usar tus OCX (en xHarbour parece q ya esta), caerias en la misma tentación o te lo pensarias q control usar si no tienes los fuentes ¿
Y todo y disponer del codigo fuente a veces si tienes q meter mano como dice Rene -> ja ¡ a ver quien es el guapo q toca cierta coma.
Un saludo a todos y felices fiestas.
Carles.