Persistencia en Squeak/Pharo
Locked
12
12
 
|
Hola a todos,
Tengo que presentar un informe a mis superiores sobre herramientas de desarrollo, y le toca el turno a Smalltalk, por enésima vez. Tras ir evaluando distintas herramientas, tengo que ponerme a hacer unas pruebas, y me gustaría saber como está el tema de persistencia en Squeak/Pharo. Aunque aún ando en la tesitura de elegir si Squeak o Pharo, por lo que veo, al parecer, el movimiento "empresarial" anda más por el lado de Pharo, así que, quizás, sería la mejor elección, aunque, ahora mismo, eso es lo de menos. Básicamente, necesitaría algún tipo de almacenamiento en local monopuesto que sea rápido, pero a la vez, sea capaz de poder trabajar, si lo necesitara, en multipuestos con distintas imágenes trabajando (un mismo local con distintos puntos de trabajo). Nunca he trabajado con persistencia en Smalltalk, por lo que desconozco qué sería lo mejor. Me dá miedo que según vayan creciendo los movimientos de la aplicación se vuelva lenta. Había pensado en Magma, pero quizás sea matar moscas a cañonazos, por lo que insto a vuestra experiencia. Por otro lado, siempre y cuando fuera posible, si los datos pudieran consultarse de manera externa a la imágen sería excepcional (por ejemplo, para acceder a ellos en caso de catástrofe o algo) Para que os hagáis a la idea, sería para una aplicación para tiendas. Por lo que necesitaré trabajar con puertos serie, scanners, generar informes, consultar datos históricos, manejar almacenes, seguramente comunicar con una aplicación central y un lago etcétera etc... -- Giuseppe Luigi http://www.lordzealon.com -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Persistencia en Squeak/Pharo
|
|
¿Por qué no Gemstone? Para plantearse un tema web.
http://seaside.gemstone.com/docs/GLASS-Announcement.htm 2010/11/9 Giuseppe Luigi Punzi <[hidden email]> Hola a todos, -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Persistencia en Squeak/Pharo
|
|
Sobre persistencia tenes varios sabores...
Si va a priorizar la transparencia en el desarrollo Magma es tu camino, Ahora bien si lo que estas buscando es la interacción con otros sistemas no Smalltalk y la consulta externa.. la recomendación es GLORP con alguna DB Relacional.
Si el desarrollo no es muy grande podes usar Sandstone,por otro lado no descartaría la pre-valencia, propia de la imagen,, dependiendo el caso. En lo personal, las mejores resultado los logre con soluciones mixtas, es decir, no tes porque casarte con algo..
Por ejemplo tenes una aplicación donde tenes datos propios de la maquina que esta usando y tenes un repositorio de datos común para todos los puestos (supongamos que no podemos usar seaside u otra tecnologia web). Los datos locales los guardas en la propia imagen y comunes una en la base de datos, usando Glorp.
No conozco el contexto sobre el que te estas moviendo, pero tenes soluciones para lo que necesites,,, hasta tenes por ahí (desconozco el grado de madures), una integración con Amazon WS DB. Saludos BTW, alguien conoce si alguna implementación de Map Reducing o NoSQL integration (algo como por ejemplo big table ) 2010/11/9 Alejandro Pérez <[hidden email]> ¿Por qué no Gemstone? Para plantearse un tema web. To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Alejandro Pérez
sin dudas, Gemstone o Magma para algo bien "objetos".
Si querés una base de datos tradicional PostgreSQL se puede usar muy bien y con excelente performance (podés chequear SmallPOS en Squeaksource que lo usa para un sistema del tipo que estás consultando). Saludos. El día 9 de noviembre de 2010 09:21, Alejandro Pérez <[hidden email]> escribió: > ¿Por qué no Gemstone? Para plantearse un tema web. > > http://seaside.gemstone.com/docs/GLASS-Announcement.htm > > 2010/11/9 Giuseppe Luigi Punzi <[hidden email]> >> >> Hola a todos, >> >> Tengo que presentar un informe a mis superiores sobre herramientas de >> desarrollo, y le toca el turno a Smalltalk, por enésima vez. >> >> Tras ir evaluando distintas herramientas, tengo que ponerme a hacer unas >> pruebas, y me gustaría saber como está el tema de persistencia en >> Squeak/Pharo. Aunque aún ando en la tesitura de elegir si Squeak o Pharo, >> por >> lo que veo, al parecer, el movimiento "empresarial" anda más por el lado >> de >> Pharo, así que, quizás, sería la mejor elección, aunque, ahora mismo, eso >> es >> lo de menos. >> >> Básicamente, necesitaría algún tipo de almacenamiento en local monopuesto >> que >> sea rápido, pero a la vez, sea capaz de poder trabajar, si lo necesitara, >> en >> multipuestos con distintas imágenes trabajando (un mismo local con >> distintos >> puntos de trabajo). >> >> Nunca he trabajado con persistencia en Smalltalk, por lo que desconozco >> qué >> sería lo mejor. Me dá miedo que según vayan creciendo los movimientos de >> la >> aplicación se vuelva lenta. Había pensado en Magma, pero quizás sea matar >> moscas a cañonazos, por lo que insto a vuestra experiencia. >> >> Por otro lado, siempre y cuando fuera posible, si los datos pudieran >> consultarse de manera externa a la imágen sería excepcional (por ejemplo, >> para >> acceder a ellos en caso de catástrofe o algo) >> >> Para que os hagáis a la idea, sería para una aplicación para tiendas. Por >> lo >> que necesitaré trabajar con puertos serie, scanners, generar informes, >> consultar datos históricos, manejar almacenes, seguramente comunicar con >> una >> aplicación central y un lago etcétera etc... >> >> -- >> Giuseppe Luigi >> http://www.lordzealon.com >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Hola de nuevo,
El mar, 09-11-2010 a las 09:55 -0300, Germán Arduino escribió: > sin dudas, Gemstone o Magma para algo bien "objetos". Si, también había pensado en Gemstone, pero, no sé, los veo como usar Oracle como BBDD de una aplicación de finanzas caseras, no creéis? Quizás tire por el lado magma. > Si querés una base de datos tradicional PostgreSQL se puede usar muy > bien y con excelente performance (podés chequear SmallPOS en > Squeaksource que lo usa para un sistema del tipo que estás > consultando). Había pensado en RDBMS usando SqueakDBX, pero parece que me apetece más tirar de una BBDD de objetos. Mi intención sería hacerlo todo en objetos, así que, a poder ser, si la performance de Magma es buena, tiraría por ese lado. SmallPOS, no conocía ese proyecto, lo chequearé, gracias. -- Giuseppe Luigi http://www.lordzealon.com -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Alejandro Pérez
Hola,
El mar, 09-11-2010 a las 13:21 +0100, Alejandro Pérez escribió: > ¿Por qué no Gemstone? Para plantearse un tema web. Como digo en otro mail, creo que gemstone podría ser muy pesado para instalaciones pequeñas. Parece que gemstone está más pensado para cosas grandes, y mi caso no lo sería. Mi aplicación tendría interfaz web, pero no para su uso intensivo, si no para temas particulares. Un saludo. -- Giuseppe Luigi http://www.lordzealon.com -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
In reply to this post by Giuseppe
> trabajar con puertos serie, scanners, generar informes...
Hay alguna utilidad medianamente seria para mostrar informes en Pharo/ Squeak?? No quiero ser pesimista pero no me imagino Pharo para aplicaciones de gestión por detalles como éste. Saludos -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by Diogenes Moreira
Hola Diogenes,
El mar, 09-11-2010 a las 09:39 -0300, Diogenes Moreira escribió: > Sobre persistencia tenes varios sabores... > > > Si va a priorizar la transparencia en el desarrollo Magma es tu > camino, > Ahora bien si lo que estas buscando es la interacción con otros > sistemas no Smalltalk y la consulta externa.. la recomendación es > GLORP con alguna DB Relacional. > Si el desarrollo no es muy grande podes usar Sandstone,por otro lado > no descartaría la pre-valencia, propia de la imagen,, dependiendo el > caso. Seguramente opte por Magma al final, tendré que hacer pruebas... > En lo personal, las mejores resultado los logre con soluciones > mixtas, es decir, no tes porque casarte con algo.. > > > Por ejemplo tenes una aplicación donde tenes datos propios de la > maquina que esta usando y tenes un repositorio de datos común para > todos los puestos (supongamos que no podemos usar seaside u otra > tecnologia web). Los datos locales los guardas en la propia imagen y > comunes una en la base de datos, usando Glorp. > > > No conozco el contexto sobre el que te estas moviendo, pero tenes > soluciones para lo que necesites,,, hasta tenes por ahí (desconozco el > grado de madures), una integración con Amazon WS DB. Si, lo sé, pero tengo poca experiencia en smalltalk como para encima meterme en un follón de ese calibre. A contexto, no sé en qué contexto te refieres jejejeje Sería para implementar una solución para tiendas, que muy probablemente requerirá también de un software de backoffice central. Y no, aunque debe haber una interfaz web para ciertas tareas, la aplicación debe funcionar en modo escritorio de manera autónoma en cada puesto (además, no me gusta el WEB :P) > > > Saludos > > > BTW, alguien conoce si alguna implementación de Map Reducing o NoSQL > integration (algo como por ejemplo big table ) Te refieres a algo como: http://nosql.mypopescu.com/post/656434885/smalltalk-and-couchdb-too-geeky-to-resist ?? -- Giuseppe Luigi http://www.lordzealon.com -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by gerard alis
El mar, 09-11-2010 a las 05:54 -0800, gerard escribió:
> > trabajar con puertos serie, scanners, generar informes... > > Hay alguna utilidad medianamente seria para mostrar informes en Pharo/ > Squeak?? Esa era mi siguiente pregunta :P -- -- Giuseppe Luigi http://www.lordzealon.com -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Persistencia en Squeak/Pharo
|
|
In reply to this post by gerard alis
Hola a todos. Perdón que me entrometa... encima es medio offtopic :P. Hace tiempo que me "jode" bastante este tema de los generadores de informes en las aplicaciones, sean con smalltalk o no, porque no tienen buen soporte o carecen de uniformidad entre diferentes alternativas. Y si te vas a otro IDE, tenés que aprender otra nueva herramienta (además del IDE en sí). En Smalltalk, un amigo me mostró uno que usaba que parece estar bueno, acá hay info:
Pero igual, como digo, es medio denso de aprender y bastante limitado esto de los generadores de informes. Mi solución es pensar a los informes como otra página web, que en lo posible no tiene las barras de navegación, un layout rígido que no cambia según el ancho del navegador, y esas cosas. Entonces el usuario si quiere el reporte para visualizarlo es esta, y si lo quiere imprimir imprime la página web (por supuesto que con un botón dentro de la página, no desde Archivo->Imprimir :). Y si hay que generar un PDF hay impresoras virtuales que generan un archivo en este formato como PDF Creator.
Incluso he usado aplicaciones de escritorio que crean todo el contenido de las ventanas como HTML, y se ve como una pagina web, aunque ni cuenta te das al principio:
Saludos. El 9 de noviembre de 2010 10:54, gerard <[hidden email]> escribió: > trabajar con puertos serie, scanners, generar informes... -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
=?ISO-8859-1?Q?=C1rea_de_trabajo_1=5F003=2Epng?= (256K) |
|
In reply to this post by Diogenes Moreira
Buenos días . Donde podría leer mas sobre técnicas o formas de usar
eficientemente pre-valencia en proyectos prácticos? Muchas gracias Pablo Digonzelli El mar, 09-11-2010 a las 09:39 -0300, Diogenes Moreira escribió: > Sobre persistencia tenes varios sabores... > > > Si va a priorizar la transparencia en el desarrollo Magma es tu > camino, > Ahora bien si lo que estas buscando es la interacción con otros > sistemas no Smalltalk y la consulta externa.. la recomendación es > GLORP con alguna DB Relacional. > Si el desarrollo no es muy grande podes usar Sandstone,por otro lado > no descartaría la pre-valencia, propia de la imagen,, dependiendo el > caso. > > > En lo personal, las mejores resultado los logre con soluciones > mixtas, es decir, no tes porque casarte con algo.. > > > Por ejemplo tenes una aplicación donde tenes datos propios de la > maquina que esta usando y tenes un repositorio de datos común para > todos los puestos (supongamos que no podemos usar seaside u otra > tecnologia web). Los datos locales los guardas en la propia imagen y > comunes una en la base de datos, usando Glorp. > > > No conozco el contexto sobre el que te estas moviendo, pero tenes > soluciones para lo que necesites,,, hasta tenes por ahí (desconozco el > grado de madures), una integración con Amazon WS DB. > > > Saludos > > > BTW, alguien conoce si alguna implementación de Map Reducing o NoSQL > integration (algo como por ejemplo big table ) > > 2010/11/9 Alejandro Pérez <[hidden email]> > ¿Por qué no Gemstone? Para plantearse un tema web. > > http://seaside.gemstone.com/docs/GLASS-Announcement.htm > > 2010/11/9 Giuseppe Luigi Punzi <[hidden email]> > > > Hola a todos, > > Tengo que presentar un informe a mis superiores sobre > herramientas de > desarrollo, y le toca el turno a Smalltalk, por > enésima vez. > > Tras ir evaluando distintas herramientas, tengo que > ponerme a hacer unas > pruebas, y me gustaría saber como está el tema de > persistencia en > Squeak/Pharo. Aunque aún ando en la tesitura de elegir > si Squeak o Pharo, por > lo que veo, al parecer, el movimiento "empresarial" > anda más por el lado de > Pharo, así que, quizás, sería la mejor elección, > aunque, ahora mismo, eso es > lo de menos. > > Básicamente, necesitaría algún tipo de almacenamiento > en local monopuesto que > sea rápido, pero a la vez, sea capaz de poder > trabajar, si lo necesitara, en > multipuestos con distintas imágenes trabajando (un > mismo local con distintos > puntos de trabajo). > > Nunca he trabajado con persistencia en Smalltalk, por > lo que desconozco qué > sería lo mejor. Me dá miedo que según vayan creciendo > los movimientos de la > aplicación se vuelva lenta. Había pensado en Magma, > pero quizás sea matar > moscas a cañonazos, por lo que insto a vuestra > experiencia. > > Por otro lado, siempre y cuando fuera posible, si los > datos pudieran > consultarse de manera externa a la imágen sería > excepcional (por ejemplo, para > acceder a ellos en caso de catástrofe o algo) > > Para que os hagáis a la idea, sería para una > aplicación para tiendas. Por lo > que necesitaré trabajar con puertos serie, scanners, > generar informes, > consultar datos históricos, manejar almacenes, > seguramente comunicar con una > aplicación central y un lago etcétera etc... > > -- > Giuseppe Luigi > http://www.lordzealon.com > > -- > To post to this group, send email to > [hidden email] > To unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org > > > -- > To post to this group, send email to > [hidden email] > To unsubscribe from this group, send email to clubSmalltalk > +[hidden email] > > http://www.clubSmalltalk.org > > > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to clubSmalltalk > +[hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
In reply to this post by gerard alis
Ahora que tengo un poco más de tiempo puedo explayarme :P
Hace tiempo, me digeron una vez...para qué reinventar la rueda, si ya existe algo que está muy bien hecho? Precisamente, fué respecto a una discusión sobre informes. Ya existen motores potentes (y opensource) exclusivamente para informes como JasperReport (no los usé nunca, pero he leido que son muy buenos), y a un report creo que puedes alimentarlo desde un XML. Lo que habría que ver, es, la velocidad en cargar el informe recuperando de ese XML claro está. Además, como han comentado, un report también puede generarse como un HTML, y supongo, que con las librerías que existen para manipular éstos sería algo sencillo. On Tuesday 09 November 2010 14:54:47 gerard wrote: > > trabajar con puertos serie, scanners, generar informes... > > Hay alguna utilidad medianamente seria para mostrar informes en Pharo/ > Squeak?? > No quiero ser pesimista pero no me imagino Pharo para aplicaciones de > gestión por detalles como éste. > > Saludos -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Persistencia en Squeak/Pharo
|
|
Sí estoy de acuerdo Giuseppe. Yo uso JasperReport a diario y te digo que vuelan. También use Agata Report, Crystal Report, y otros. Pero en todos tenes que meter mano en algo no-smalltalk.
Cuando yo decía de generar páginas web para cada informe me refería a usar Seaside por ejemplo, que si se fijan como trabaja Simbleron Report creo que es mas complicado al final, a pesar que el "generador de informes" debería simplificar la tarea entre otras ventajas.
Saludos. El 9 de noviembre de 2010 15:06, Giuseppe Luigi Punzi <[hidden email]> escribió: Ahora que tengo un poco más de tiempo puedo explayarme :P -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Aunque Seaside sea demasiado pesado sólo para informes, si, sería una opción.
Igualmente, el problema vendría con la personalización. Con Jasper por ejemplo, siempre puedes poner iReport en el cliente y que él se lo personalice..como se haría en un sistema como el que comentas? Habría que que generar un sistema que usara un fichero de intercambio para la generación y que pudiera ser editado por el cliente final. Es posible hacerlo, pero claro, no está hecho... On Wednesday 10 November 2010 00:34:18 Gastón Dall' Oglio wrote: > Sí estoy de acuerdo Giuseppe. > Yo uso JasperReport a diario y te digo que vuelan. También use Agata > Report, Crystal Report, y otros. > Pero en todos tenes que meter mano en algo no-smalltalk. > Cuando yo decía de generar páginas web para cada informe me refería a usar > Seaside por ejemplo, que si se fijan como trabaja Simbleron Report creo que > es mas complicado al final, a pesar que el "generador de informes" debería > simplificar la tarea entre otras ventajas. > > Saludos. > > El 9 de noviembre de 2010 15:06, Giuseppe Luigi Punzi < > > [hidden email]> escribió: > > Ahora que tengo un poco más de tiempo puedo explayarme :P > > > > Hace tiempo, me digeron una vez...para qué reinventar la rueda, si ya > > existe > > algo que está muy bien hecho? Precisamente, fué respecto a una discusión > > sobre > > informes. Ya existen motores potentes (y opensource) exclusivamente para > > informes como JasperReport (no los usé nunca, pero he leido que son muy > > buenos), y a un report creo que puedes alimentarlo desde un XML. Lo que > > habría > > que ver, es, la velocidad en cargar el informe recuperando de ese XML > > claro está. > > > > Además, como han comentado, un report también puede generarse como un > > HTML, y > > supongo, que con las librerías que existen para manipular éstos sería > > algo sencillo. > > > > On Tuesday 09 November 2010 14:54:47 gerard wrote: > > > > trabajar con puertos serie, scanners, generar informes... > > > > > > Hay alguna utilidad medianamente seria para mostrar informes en Pharo/ > > > Squeak?? > > > No quiero ser pesimista pero no me imagino Pharo para aplicaciones de > > > gestión por detalles como éste. > > > > > > Saludos > > > > -- > > To post to this group, send email to [hidden email] > > To unsubscribe from this group, send email to > > [hidden email]<clubSmalltalk%2Bunsubscribe@go > > oglegroups.com> > > > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Persistencia en Squeak/Pharo
|
|
> Aunque Seaside sea demasiado pesado sólo para informes, si, sería una opción.
mmmmm no se, yo llevo Seaside en un pendrive a todos lados :) Si te referís a la velocidad, puede ser mas pesado sí. Pero a veces un reporte muy largo y cargado es resultado de un error de diseño, pero eso es otro tema ya... Por otro lado, sirviendo el contenido estático con apache anda mejor la cosa. > Igualmente, el problema vendría con la personalización. Salvo que te estes refiriendo a modificar detalles estéticos del informe, no creo que eso pase mucho. Justamente en donde trabajo sucedió eso que decís, nos vendieron un sistema (Java puaj) y hasta que nos dieron los fuentes nos pasábamos personalizando los reportes con iReport conociendo el modelo de objetos a travez de los XML de Hibernate, Dios! Hasta que no pudimos mas, necesitabamos conocer el modelo de objetos entero para seguir (no solo los POJOS). Por eso creo también que puede estar evidenciando un error en algún punto del desarrollo si alguien tiene que meterle mano a los reportes exclusivamente. De todas maneras queda a gusto del consumidor :) > Es posible hacerlo, pero claro, no está hecho... Si te referís a crear algún tipo de editor de informes que cree código para Seaside, genial idea! O que genere una especificación del informe guardado dentro del ambiente, por ejemplo como método de clase, como se guardan normalmente los recursos en Smalltalk. Saludos! El 10 de noviembre de 2010 05:51, Giuseppe Luigi Punzi <[hidden email]> escribió: Aunque Seaside sea demasiado pesado sólo para informes, si, sería una opción. -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
On Wednesday 10 November 2010 16:16:45 Gastón Dall' Oglio wrote:
> > Aunque Seaside sea demasiado pesado sólo para informes, si, sería una > > opción. > > mmmmm no se, yo llevo Seaside en un pendrive a todos lados :) > Si te referís a la velocidad, puede ser mas pesado sí. Pero a veces un > reporte muy largo y cargado es resultado de un error de diseño, pero eso es > otro tema ya... Por otro lado, sirviendo el contenido estático con apache > anda mejor la cosa. > A pesado me refiero, que ayer intenté cargarlo en una imágen, y se tiró perfectamente unos 15-20 minutos de reloj instalar. Seaside es un proyecto grande, e incrustarlo exclusivamente para informes...Supongo que sería mejor algo ya integrado (HttpView se llamaba?) > > Igualmente, el problema vendría con la personalización. > > Salvo que te estes refiriendo a modificar detalles estéticos del informe, > no creo que eso pase mucho. Justamente en donde trabajo sucedió eso que > decís, nos vendieron un sistema (Java puaj) y hasta que nos dieron los > fuentes nos pasábamos personalizando los reportes con iReport conociendo > el modelo de objetos a travez de los XML de Hibernate, Dios! Hasta que no > pudimos mas, necesitabamos conocer el modelo de objetos entero para seguir > (no solo los POJOS). Por eso creo también que puede estar evidenciando un > error en algún punto del desarrollo si alguien tiene que meterle mano a > los reportes exclusivamente. De todas maneras queda a gusto del consumidor > :) No, pero imagina algo como facturación. Lo mismo el cliente quiere el logo aquí, los datos de cliente allí, etc.. es algo muy personal..... > > > Es posible hacerlo, pero claro, no está hecho... > > Si te referís a crear algún tipo de editor de informes que cree código para > Seaside, genial idea! O que genere una especificación del informe guardado > dentro del ambiente, por ejemplo como método de clase, como se guardan > normalmente los recursos en Smalltalk. Cuando llegue el momento, si estoy trabajando con Smalltalk, quizás le meta mano a este tema, pero queda muucho. > > Saludos! -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Persistencia en Squeak/Pharo
|
|
In reply to this post by Giuseppe
Hola G.L.
Creo que alguna vez hemos hablado de estos temas de generar informes y similares. A parte de las soluciones propuestas de utilizar herramientas no smalltalk, o el utilizar "lenguajes intermedios" como html... existen también otros lenguajes como laTeX o Lout que pueden servir como alternativa. Concretamente utilicé Lout como lenguaje intermedio para generar postcript con gráficos de barra y de tarta, y tablas de datos para una aplicación estadística en mi trabajo (creo que te lo comenté en alguna ocasión) y funcionaba bastante bien. En principio sería crear las plantillas que luego generarían el documento y parsearlo para conseguir el fichero .ps Un abrazo. On Nov 10, 9:51 am, Giuseppe Luigi Punzi <[hidden email]> wrote: > Aunque Seaside sea demasiado pesado sólo para informes, si, sería una opción. > > Igualmente, el problema vendría con la personalización. Con Jasper por > ejemplo, siempre puedes poner iReport en el cliente y que él se lo > personalice..como se haría en un sistema como el que comentas? > > Habría que que generar un sistema que usara un fichero de intercambio para la > generación y que pudiera ser editado por el cliente final. Es posible hacerlo, > pero claro, no está hecho... > > On Wednesday 10 November 2010 00:34:18 Gastón Dall' Oglio wrote: > > > > > > > > > Sí estoy de acuerdo Giuseppe. > > Yo uso JasperReport a diario y te digo que vuelan. También use Agata > > Report, Crystal Report, y otros. > > Pero en todos tenes que meter mano en algo no-smalltalk. > > Cuando yo decía de generar páginas web para cada informe me refería a usar > > Seaside por ejemplo, que si se fijan como trabaja Simbleron Report creo que > > es mas complicado al final, a pesar que el "generador de informes" debería > > simplificar la tarea entre otras ventajas. > > > Saludos. > > > El 9 de noviembre de 2010 15:06, Giuseppe Luigi Punzi < > > > [hidden email]> escribió: > > > Ahora que tengo un poco más de tiempo puedo explayarme :P > > > > Hace tiempo, me digeron una vez...para qué reinventar la rueda, si ya > > > existe > > > algo que está muy bien hecho? Precisamente, fué respecto a una discusión > > > sobre > > > informes. Ya existen motores potentes (y opensource) exclusivamente para > > > informes como JasperReport (no los usé nunca, pero he leido que son muy > > > buenos), y a un report creo que puedes alimentarlo desde un XML. Lo que > > > habría > > > que ver, es, la velocidad en cargar el informe recuperando de ese XML > > > claro está. > > > > Además, como han comentado, un report también puede generarse como un > > > HTML, y > > > supongo, que con las librerías que existen para manipular éstos sería > > > algo sencillo. > > > > On Tuesday 09 November 2010 14:54:47 gerard wrote: > > > > > trabajar con puertos serie, scanners, generar informes... > > > > > Hay alguna utilidad medianamente seria para mostrar informes en Pharo/ > > > > Squeak?? > > > > No quiero ser pesimista pero no me imagino Pharo para aplicaciones de > > > > gestión por detalles como éste. > > > > > Saludos > > > > -- > > > To post to this group, send email to [hidden email] > > > To unsubscribe from this group, send email to > > > [hidden email]<clubSmalltalk%2Bunsubscribe@go > > > oglegroups.com> > > > >http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
|
|
Oñe Notxor, pensaba que estabas desconectado del mundo smalltalkiano :P
Esas pruebas que hicistes las hiciste desde Smalltalk? No se me había ocurrido generar LaTeX sinceramente, y me suena que hay varias libs para generarlo desde Squeak/Pharo. Quizás podría ser una opción. Un saludo. On Wednesday 10 November 2010 17:08:06 Fernando Arroba wrote: > Hola G.L. > > Creo que alguna vez hemos hablado de estos temas de generar informes y > similares. A parte de las soluciones propuestas de utilizar > herramientas no smalltalk, o el utilizar "lenguajes intermedios" como > html... existen también otros lenguajes como laTeX o Lout que pueden > servir como alternativa. Concretamente utilicé Lout como lenguaje > intermedio para generar postcript con gráficos de barra y de tarta, y > tablas de datos para una aplicación estadística en mi trabajo (creo > que te lo comenté en alguna ocasión) y funcionaba bastante bien. En > principio sería crear las plantillas que luego generarían el documento > y parsearlo para conseguir el fichero .ps > > Un abrazo. > > On Nov 10, 9:51 am, Giuseppe Luigi Punzi <[hidden email]> > > wrote: > > Aunque Seaside sea demasiado pesado sólo para informes, si, sería una > > opción. > > > > Igualmente, el problema vendría con la personalización. Con Jasper por > > ejemplo, siempre puedes poner iReport en el cliente y que él se lo > > personalice..como se haría en un sistema como el que comentas? > > > > Habría que que generar un sistema que usara un fichero de intercambio > > para la generación y que pudiera ser editado por el cliente final. Es > > posible hacerlo, pero claro, no está hecho... > > > > On Wednesday 10 November 2010 00:34:18 Gastón Dall' Oglio wrote: > > > Sí estoy de acuerdo Giuseppe. > > > Yo uso JasperReport a diario y te digo que vuelan. También use Agata > > > Report, Crystal Report, y otros. > > > Pero en todos tenes que meter mano en algo no-smalltalk. > > > Cuando yo decía de generar páginas web para cada informe me refería a > > > usar Seaside por ejemplo, que si se fijan como trabaja Simbleron > > > Report creo que es mas complicado al final, a pesar que el "generador > > > de informes" debería simplificar la tarea entre otras ventajas. > > > > > > Saludos. > > > > > > El 9 de noviembre de 2010 15:06, Giuseppe Luigi Punzi < > > > > > > [hidden email]> escribió: > > > > Ahora que tengo un poco más de tiempo puedo explayarme :P > > > > > > > > Hace tiempo, me digeron una vez...para qué reinventar la rueda, si ya > > > > existe > > > > algo que está muy bien hecho? Precisamente, fué respecto a una > > > > discusión sobre > > > > informes. Ya existen motores potentes (y opensource) exclusivamente > > > > para informes como JasperReport (no los usé nunca, pero he leido que > > > > son muy buenos), y a un report creo que puedes alimentarlo desde un > > > > XML. Lo que habría > > > > que ver, es, la velocidad en cargar el informe recuperando de ese XML > > > > claro está. > > > > > > > > Además, como han comentado, un report también puede generarse como un > > > > HTML, y > > > > supongo, que con las librerías que existen para manipular éstos sería > > > > algo sencillo. > > > > > > > > On Tuesday 09 November 2010 14:54:47 gerard wrote: > > > > > > trabajar con puertos serie, scanners, generar informes... > > > > > > > > > > Hay alguna utilidad medianamente seria para mostrar informes en > > > > > Pharo/ Squeak?? > > > > > No quiero ser pesimista pero no me imagino Pharo para aplicaciones > > > > > de gestión por detalles como éste. > > > > > > > > > > Saludos > > > > > > > > -- > > > > To post to this group, send email to [hidden email] > > > > To unsubscribe from this group, send email to > > > > [hidden email]<clubSmalltalk%2Bunsubscrib > > > > e@go oglegroups.com> > > > > > > > >http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Persistencia en Squeak/Pharo
|
|
In reply to this post by Giuseppe
El 10-11-2010, a las 12:39, Giuseppe Luigi Punzi <[hidden email]> escribió: > > A pesado me refiero, que ayer intenté cargarlo en una imágen, y se t > iró > perfectamente unos 15-20 minutos de reloj instalar. Seaside es un > proyecto > grande, e incrustarlo exclusivamente para informes... ?Y no seria mejor tener alguna manera de cargar los bytecodes ya compilados en vez de subir los fuentes? Digo, si en Java se puede, que es el lenguaje de tipeo estático denostado thread por medio en esta lista, ?porque no hacerlo en smalltalk? ?A alguien se le ocurre como? Saludos, Gulermo. -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Persistencia en Squeak/Pharo
|
|
A quien corresponda: ¿hasta cuando hay que aguantar que el troll siga
abriendo posts con temas que no tienen nada que ver con el mensaje original y que sólo conducen a threads de cuasi-infinita longitud? Saludos y gracias, Andrés Guillermo Schwarz escribió: > > El 10-11-2010, a las 12:39, Giuseppe Luigi Punzi > <[hidden email]> escribió: >> >> A pesado me refiero, que ayer intenté cargarlo en una imágen, y se tiró >> perfectamente unos 15-20 minutos de reloj instalar. Seaside es un >> proyecto >> grande, e incrustarlo exclusivamente para informes... > > ?Y no seria mejor tener alguna manera de cargar los bytecodes ya > compilados en vez de subir los fuentes? > > Digo, si en Java se puede, que es el lenguaje de tipeo estático > denostado thread por medio en esta lista, ?porque no hacerlo en smalltalk? > > ?A alguien se le ocurre como? > > Saludos, > Gulermo. > -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
«
Return to Español (Spanish)
|
1 view|%1 views
| Free forum by Nabble | Edit this page |