Proyecto de Colaboración

[aureliano.sanchezc]

Saludos a toda la comunidad Xailer.
Mi nombre es Aureliano y me gustarí­a compartir con vosotros una idea o proyecto que hace bastante tenemos en mente.
Somos dos programadores que colaboramos con cierta frecuencia y que desde hace bastante tiempo tenemos en mente un proyecto de colaboración a un mayor nivel, el cual es el que os deseamos presentar.
Hasta descubrir Xailer hemos programado en Clipper 87, Clipper 5.... hasta llegar a Fivewin (imagino que a alguno os sonara bastante) y como casi todos (imagino) pues hemos ido desarrollando nuestras librerias de utilidades al objeto de poder reutilizar/reciclar la mayor parte de codigo y asi rentabilizar al máximo nuestras horas de trabajo.
Tras evaluar Xailer como herramienta para nuestros futuros desarrollos creemos que es el momento de dar el salto
y afrontar ese proyecto de colaboración a mayor escala.
La idea es la siguiente. Partimos de que una gran cantidad de los desarrollos que se nos presentan (e imagino que a vostros tambien) suelen ser del tipo :
Gestion del modelo de negocio + Gestion Comercial Standard Tipo Factplus algo reducido) + Gestion Contable Standard (Tipo Contaplus algo reducido)
o bien
Gestion del modelo de negocio + Gestion Comercial Standard (Tipo Factplus algo reducido) + Posibilidad de conexión a distintos programas contables
Pues bien, el proyecto resumiéndolo muy mucho, pasarí­a por reunir un grupo de trabajo para diseñar y desarrollar esa plataforma común para todos nuestros futuros proyectos.
Asi mismo y forma paralela tambien se desarrollarian componentes y/o funciones (nuestras famosas dll`s de rutinas) enfocadas a facilitar y rentabilizar las horas de programación de la plataforma bajo Xailer.
Quien este interesado en ampliar dicha información puede ponerse en contacto con nosotros en la dirección aureliano.sanchezc@gmail.com

[Bingen Ugaldebere]

Llevamos tiempo pensando en ello también.
De donde sois?
Salu2.
El 18/03/2011 11:36, aureliano[dot]sanchezc escribió:
> Saludos a toda la comunidad Xailer.
>
> Mi nombre es Aureliano y me gustarí­a compartir con vosotros
> una idea o proyecto que hace bastante tenemos en mente.
>
> Somos dos programadores que colaboramos con cierta
> frecuencia y que desde hace bastante tiempo tenemos en mente
> un proyecto de colaboración a un mayor nivel, el cual es el
> que os deseamos presentar.
>
> Hasta descubrir Xailer hemos programado en Clipper 87,
> Clipper 5.... hasta llegar a Fivewin (imagino que a alguno
> os sonara bastante) y como casi todos (imagino) pues hemos
> ido desarrollando nuestras librerias de utilidades al objeto
> de poder reutilizar/reciclar la mayor parte de codigo y asi
> rentabilizar al máximo nuestras horas de trabajo.
>
> Tras evaluar Xailer como herramienta para nuestros futuros
> desarrollos creemos que es el momento de dar el salto y afrontar ese
> proyecto de colaboración a mayor escala.
>
> La idea es la siguiente. Partimos de que una gran cantidad
> de los desarrollos que se nos presentan (e imagino que a
> vostros tambien) suelen ser del tipo :
>
> Gestion del modelo de negocio + Gestion Comercial Standard
> Tipo Factplus algo reducido) + Gestion Contable Standard
> (Tipo Contaplus algo reducido)
>
> o bien
>
> Gestion del modelo de negocio + Gestion Comercial Standard
> (Tipo Factplus algo reducido) + Posibilidad de conexión a
> distintos programas contables
>
> Pues bien, el proyecto resumiéndolo muy mucho, pasarí­a por
> reunir un grupo de trabajo para diseñar y desarrollar esa
> plataforma común para todos nuestros futuros proyectos.
>
> Asi mismo y forma paralela tambien se desarrollarian
> componentes y/o funciones (nuestras famosas dll`s de
> rutinas) enfocadas a facilitar y rentabilizar las horas de
> programación de la plataforma bajo Xailer.
>
> Quien este interesado en ampliar dicha información puede
> ponerse en contacto con nosotros en la dirección
> mailto:aureliano.sanchezc@gmail.com
>
>

[jfgimenez]

Aureliano,
como dice Bingen, llevamos tiempo queriendo iniciar un proyecto así­. De
hecho llegamos a formar un pequeño grupo de desarrolladores para llevarlo a
cabo, pero todaví­a no hemos empezado. Hay que tener en cuenta que el
proyecto no es nada sencillo, porque cada uno tenemos una forma de trabajar
y de hacer las cosas, y no es fácil ponernos de acuerdo en todo. Pero la
razón principal es que no hemos llegado a coincidir en nuestra agenda de
trabajo; cuando unos están libres para empezar otros están ocupados con
proyectos que tienen que entregar. De todos modos, la intención está ahí­, y
sólo es cuestión de tiempo que podamos abordarlo.
--
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

[aureliano.sanchezc]

José F. Giménez
Esas mismas causas son las que han hecho que una vez tras otra hayamos tenido que retrasarlo nosotros tambien. Ahora quizas por efecto de la famosa crisis vemos en nuestras agendas más huecos que en tiempos pasados, cosa que hemos valorado de forma importante para decidirnos a comenzar. Si dejamos pasar estos momentos en los que tenemos algún hueco disponible pronto vendran tiempos en que las agendas vuelvan a estar repletas teniendo que volver a retrasar el proyecto. Ahora que lo tenemos, invirtamos en tiempo.
Entendemos que es un proyecto ambicioso y que posiblemente el mayor reto sea el organizar el grupo de trabajo, pues como bien dices, cada uno tenemos nuestra forma de trabajar y de hacer las cosas. Pero la diversidad tambien es algo a explotar. Según lo vemos nosotros el echo de que sea un grupo y no una o dos personas aportara frescura y dinamismo tanto al diseño como a las funcionalidades en sí­ del proyecto. Cuando trabajamos en solitario o en grupos reducidos tendemos a encapsularnos en una forma de trabajar, pues nos es más sencillo y más rentable trabajar siempre sobre el mismo esquema que compaginar la completa agenda de trabajo con estudios y pruebas sobre nuevas tendencias y/o productos.
Un saludo

[jfgimenez]

Aureliano,
> Entendemos que es un proyecto ambicioso y que posiblemente
> el mayor reto sea el organizar el grupo de trabajo, pues
> como bien dices, cada uno tenemos nuestra forma de trabajar
> y de hacer las cosas. Pero la diversidad tambien es algo a
> explotar. Según lo vemos nosotros el echo de que sea un
> grupo y no una o dos personas aportara frescura y dinamismo
> tanto al diseño como a las funcionalidades en sí­ del
> proyecto. Cuando trabajamos en solitario o en grupos
> reducidos tendemos a encapsularnos en una forma de trabajar,
> pues nos es más sencillo y más rentable trabajar siempre
> sobre el mismo esquema que compaginar la completa agenda de
> trabajo con estudios y pruebas sobre nuevas tendencias y/o
> productos.
Sí­, estoy de acuerdo. Al sumar puntos de vista siempre se enriquece el
resultado.
Por cierto, ¿de dónde sois? Si quieres, contáctame en privado.
--
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

[aureliano.sanchezc]

Saludos a todos
Lo primero agradeceros el tiempo y el interes mostrado en este proyecto, asi como pediros disculpas pues por motivos familiares me ha sido del todo imposible confeccionar este pequeño documento que a continuacion os expongo.
Pediros que tomeis este documento como lo que es, una declaración de intenciones sobre lo que opinamos que deberí­a de ser el proyecto en sí­.
- La aplicación deberí­a ser similar a las existentes en el mercado y que todos conocemos de sobra, pues evitariamos posibles problemas y tiranteces a la hora de plantear su sustitucion
- Existen modulos, como el de divisas por ejemplo, que si bien creemos necesaria su inclusion, esta en una primera fase podria limitarse al funcionamiento interno de la aplicación, dejando para posteriores revisiones el confeccionamiento de su mantenimiento.
- Los modulos clasificados como OBLIGADOS (Gestión de usuarios y permisos, Gestión de clientes, proveedores, etc.) se diseñaran intentando abarcar las necesidades expuestas por todos los integrantes del proyecto. Ademas, creemos que deberia de habilitarse un metodo transparente para que despues cada uno pudiera adaptarlo a las necesidades especificas de cada proyecto final si es que este lo requiere. Este quizas sea el punto más complicado pues como sabeis la herencia visual de formularios aun no está totalmente implementada en Xailer (por favor corregidme si me equivoco) y habria que evaluar si merece la pena o no esperar dicha implementación.
- El gestor de Base de datos pensamos que para la fase de desarrollo podria ser Access o SQLlite. Este hecho nos deberí­a permitir cambiar muy fácilmente el motor en aplicaciones de produccion y poder utilizar por ejemplo SQL Server o MySQL por citar algunos.
- La sintaxis utilizada en las sentencias SQL deberia de ser lo mas estándar posible para facilitar asi la portabilidad a cualquier motor que necesitemos.
- La gestión de los informes (punto muy importante) pensamos que deberia de realizarse con Fast Report por la facilidad y el potencial que tiene.
- Seria muy interesante el utilizar la técnica vista-controlador a la hora de la programación por la gran cantidad de ventajas que ofrece.
Otra vertiente seria la confeccion de algunos controles especificos y que serian los que se utilizaran despues en el desarrollo del proyecto.
Entre dichos controles podrian estar los siguientes
- Browses con paginación de registros. Los programadores que venidos del mundo DBF, solemos utilizar las tablas de SQl como si fueran bases de datos dbf. Cuando tenemos pocos registros o una buena conexión vemos que la aplicación vuela, pero cuando el numero de registros es de 100 ó 200 mil y/o la conexion no es muy buena vemos que es insoportable traérnoslos todos. Este browse deberí­a por él mismo conseguir la paginación de registros con independencia del motor de datos, y que esto fuera tan fácil de programar como los browses actuales de Xailer.
- Campos Get con autocompletado: Algo parecido a lo que hace Google cuando escribimos en su caja de texto lo que deseamos buscar.

Por último manifestar que creemos que seria muy muy interesante para todos contar con la colaboración (al nivel que estimen) de los creadores de Xailer pues bien podriamos hacer la labor de un centro de beta-testers ademas del valor añadido que supondrí­a un proyecto de este calibre para el producto.
Desde aqui os animo a todos a paticipar
Un saludo y gracias por vuestro tiempo
Aureliano Sánchez

[jfgimenez]

Aureliano,
> Este quizas sea el punto más complicado
> pues como sabeis la herencia visual de formularios aun no
> está totalmente implementada en Xailer (por favor
> corregidme si me equivoco) y habria que evaluar si merece la
> pena o no esperar dicha implementación.
Sí­ está implementada. Para verlo, sólo tienes que modificar la clase de
donde deriva el formulario. Es decir, donde pone:
CLASS TForm1 FROM TForm
al principio del módulo, hay que cambiarlo por p.ej.:
CLASS TForm1 FROM TMiFormularioBase
Eso es todo. Claro, para que esta caracterí­stica estuviera completa, serí­a
bueno que en vez de cambiarlo manualmente, se pudiera cambiar desde el
inspector o desde algún otro sitio. Pero en cualquier caso, eso no añade
absolutamente ninguna funcionalidad extra a la "herencia de formularios".
> - El gestor de Base de datos pensamos que para la fase de
> desarrollo podria ser Access o SQLlite. Este hecho nos
> deberí­a permitir cambiar muy fácilmente el motor en
> aplicaciones de produccion y poder utilizar por ejemplo SQL
> Server o MySQL por citar algunos.
Access no es nada apropiado, además de que está completamente descontinuado
por MS. En el caso de SQLite, yo soy un enamorado de él. Lo he utilizado
bastantes veces, y lo considero el mejor de todos, pero para uso local
exclusivamente. Para cliente/servidor hay que escoger otro motor. Y ahí­ es
donde vienen los problemas. Yo personalmente, después de muchas idas y
venidas, he decidido encaminarme hacia Firebird. El datasource nativo para
Xailer está empezado, aunque ciertamente llevamos retraso porque no hemos
podido dedicarle todo el tiempo que hubiesemos querido. Pero estoy seguro de
que estará listo dentro de poco.
> - La sintaxis utilizada en las sentencias SQL deberia de
> ser lo mas estándar posible para facilitar asi la
> portabilidad a cualquier motor que necesitemos.
Al principio parece una idea sencilla, y de hecho Xailer permite un altí­simo
grado de compatibilidad entre distintos motores, gracias a su arquitectura
de datasources/datasets. Pero cuando quieres optimizar una consulta que sea
un poco compleja, entonces tienes que olvidarte de la compatibilidad entre
motores y centrarte en el que estés usando.
> - Browses con paginación de registros. Los programadores
> que venidos del mundo DBF, solemos utilizar las tablas de
> SQl como si fueran bases de datos dbf. Cuando tenemos pocos
> registros o una buena conexión vemos que la aplicación
> vuela, pero cuando el numero de registros es de 100 ó 200
> mil y/o la conexion no es muy buena vemos que es
> insoportable traérnoslos todos. Este browse deberí­a por
> él mismo conseguir la paginación de registros con
> independencia del motor de datos, y que esto fuera tan
> fácil de programar como los browses actuales de Xailer.
Esto ya lo estuvimos estudiando a fondo hace bastante tiempo, y finalmente
optamos por no implementarlo. La principal razón, aparte de la complejidad,
es que no hay absolutamente ninguna forma de garantizar la correcta
presentación de los datos. Me explico: cualquier SELECT de SQL es una
especie de "foto" de la BD en un momento determinado. Si pasado algún tiempo
(que podrí­an ser simplemente unas milésimas de segundo), alguien añade,
borra o modifica un registro, entonces no es posible recuperar un bloque
adicional de registros y mantener la integridad de la vista. Resumiendo, que
hay que hacer el SELECT completo, o asumir que va a haber incongruencias
manifiestas en el tratamiento de los datos, y esto es algo que no creo que
podamos aceptar.
> - Campos Get con autocompletado: Algo parecido a lo que
> hace Google cuando escribimos en su caja de texto lo que
> deseamos buscar.
Eso ya está. Concretamente hay dos controles que hacen eso, aunque de forma
ligeramente diferente: TSearchCombobox y TFilterCombobox.
> Por último manifestar que creemos que seria muy muy
> interesante para todos contar con la colaboración (al nivel
> que estimen) de los creadores de Xailer pues bien podriamos
> hacer la labor de un centro de beta-testers ademas del valor
> añadido que supondrí­a un proyecto de este calibre para el
> producto.
El otro dí­a te comenté que unos cuantos ya habí­amos discutido sobre un
proyecto así­. Pues bien, entre ellos estamos parte del equipo de Xailer
--
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

[aureliano.sanchezc]

José F. Giménez
Quizas para no extenderme en exceso no precise lo suficiente sobre algunos aspectos. La herencia visual como bien dices funciona. Le hemos dedicado muchas muchas horas exclusivamente a este tema. ¿Donde vemos que aun no está implementada o no del todo? Si la clase de la que heredas a su vez se creo a partir de TformFolder la cosa cambia. Tambien comentar que se deberian de poder modificar todos los controles de la clase padre cuando diseñamos la clase hija. Eso facilitaria enormemente la adaptación de los proyectos finales.
En cuanto a lo que comentas sobre el motor de base de datos estamos totalmente de acuerdo contigo y la perfecta candidata para desarrollar (trabajo en monopuesto) seria SQLITE. Tambien nos encanta Firebird como gestor para las aplicaciones en explotacion.
En cuanto al tema del rendimiento de un motor especifico o utilizar select de alto nivel de compatibilidad creemos que el uno no debe de prevalecer sobre el otro. Me explico ( o lo intento). No todas las selects tienen el mismo peso en la aplicacion teniendo selects de mantenimiento (por llamarlas de alguna forma) y selects de explotación las cuales suelen ser las mas pesadas y las que podrian penalizar el rendimiento en mayor grado. Estas selects de explotación se podrian facilmente configurar especificamente para cada motor gracias precisamente a la herencia y al uso y sobrecargado de las clases.
En los browses tienes razon que es un tema complicado el no caer en incongruencias a la hora de mostrarlo. Nosotros hasta ahora hemos escogido el establecer un numero limite de registros a mostrar relativamente bajo (maximo 100). Si al hacer la consulta o filtrado el usuario vemos que existen mas coincidencias se lo anunciamos y le recomendamos que depure su criterio de busqueda.
Tendre que ver de nuevo TSearchCombobox y TFilterCombobox. Yo tengo un objeto heredado de TSearchCombobox que trabaja exactamente igual que la caja de Google pudiendo parametrizar algunos aspectos de su comportamiento como longitud de caracteres previos al autocompletado, tipo de datos para autocompletar, campos por los que intentar hacer el autocompletado, etc....
Gracias por tus aportaciones y tu interes
Aureliano Sanchez

[Carlos Ortiz]

Trabajando con SQL es jodido editar datos en las grillas, yo diría hasta
peligroso.
El tema es que estamos con una vista parcial de la tabla y quizás
desactualizada, por eso yo diria editar datos en fichas y no desde las
grillas. Un ejemplo http://www.youtube.com/watch?v=4MXkJNbCkfM ( MVC usando
JGrid, una grilla con cosas a tener en cuenta cuando se habla de grillas,
tiene los SubGrid que están muy buenos)
Quizás para una carga masiva o facturación se pueda manejar con un cursor
local o en el motor, pero que sea creado en forma temporal y al salir se
destruye.
Nosotros sugerimos que para buscar un dato o mostrar una lista se use browse
y para editar usar un form (obviamente siempre antes de editar preguntar si
el ID sigue existiendo en la tabla por si alguíen lo quito) teniendo cuidado
con eso se evitan muchos problemas.
Atte. Carlos Ortiz

[jfgimenez]

Aureliano,
> Quizas para no extenderme en exceso no precise lo suficiente
> sobre algunos aspectos. La herencia visual como bien dices
> funciona. Le hemos dedicado muchas muchas horas
> exclusivamente a este tema. ¿Donde vemos que aun no está
> implementada o no del todo? Si la clase de la que heredas a
> su vez se creo a partir de TformFolder la cosa cambia.
Eso es porque TFolderForm es una implementación de un control, que permite
"incrustar" un formulario dentro de un folder. Para que funcione la herencia
visual con TFolderForm, tan sólo hay que hacer algunas modificaciones en
esta clase.
> Tambien comentar que se deberian de poder modificar todos
> los controles de la clase padre cuando diseñamos la clase
> hija. Eso facilitaria enormemente la adaptación de los
> proyectos finales.
Eso no es ni correcto ni deseable. Si con cada clase hija modificas la clase
padre, entonces estás afectando a todas las clases, y eso "rompe" el esquema
de trabajo de POO. Si necesitas modificar la clase padre cada vez, entonces
lo que necesitas son "plantillas" de formularios, no herencia visual. Aún
así­, nada te impide tener las dos cosas a la vez: un formulario base desde
el que heredar y plantillas en las que basarte para derivar del primero.
> En los browses tienes razon que es un tema complicado el no
> caer en incongruencias a la hora de mostrarlo. Nosotros
> hasta ahora hemos escogido el establecer un numero limite de
> registros a mostrar relativamente bajo (maximo 100). Si al
> hacer la consulta o filtrado el usuario vemos que existen
> mas coincidencias se lo anunciamos y le recomendamos que
> depure su criterio de busqueda.
Exactamente. Es lo mismo que utilizamos nosotros en algunas de nuestras
aplicaciones. Es más, solemos poner un combo para que el usuario pueda
escoger cuantos registros quiere mostrar (100, 250, 500, 1000 y todo), y que
cada cual haga lo que quiera. Si un usuario prefiere ver todos los
registros, que no se queje si le va más lento.
--
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

[aureliano.sanchezc]

José,
> Eso es porque TFolderForm es una implementación de un control, que permite
> "incrustar" un formulario dentro de un folder. Para que funcione la herencia
> visual con TFolderForm, tan sólo hay que hacer algunas modificaciones en
> esta clase.
Si pudieras o pudierais realizar dichas modificaciones os estariamos muy agradecidos ya que el sistema que utilizamos es precisamente a base de pestañas de Folders con lo que evitamos el tener formularios dedicados lo que dota a las aplicaciones de un extra en cuanto a productividad y manejabilidad.
> Eso no es ni correcto ni deseable. Si con cada clase hija modificas la clase
> padre, entonces estás afectando a todas las clases, y eso "rompe" el esquema
> de trabajo de POO. Si necesitas modificar la clase padre cada vez, entonces
> lo que necesitas son "plantillas" de formularios, no herencia visual. Aún
> así­, nada te impide tener las dos cosas a la vez: un formulario base desde
> el que heredar y plantillas en las que basarte para derivar del primero.
Quizas no consegui explicarme de la forma correcta. Me referia a que se pudiera modificar el aspecto o incluso sus datas y/o metodos de los controles de la clase hija que ha heredado de la clase padre. Por ejemplo si la clase padre A tiene un combobox, en el diseñador cuando estemos diseñando un formulario que hereda de dicha clase A, que pudieramos cambiar de sitio o de forma o incluso eliminar u ocultar dicho combobox. Por descontado me refiero a poderlo hacer desde el diseñador ya que desde el codigo no existe limitación en ese sentido.
Un saludo,
Aureliano Sánchez