On Nov 12, 2012, at 3:53 PM, "Esteban A. Maringolo" <[email protected]> wrote:
> El día 12 de noviembre de 2012 11:19, Esteban Lorenzano > <[email protected]> escribió: >> Bueno, por un lado si, y por otro no tiene sentido... >> >> Donde si? cuando valga la pena proveer en Smalltalk algo que esta afuera. >> >> El scaffolding, por ejemplo, me parece una porquería, que sirve para hacer >> ejemplos pero nunca para algo real. >> Magritte le rompe el totó de lejísimos. Y si, tenes que laburar un poco, >> pero los otros frameworks tenes que aprenderlos también, y aceptar sus >> restricciones. > > Para mi el scaffolding es como algo que completa huecos, te permite > salir con algo funcional y luego darle más vueltas de tuerca si hace > falta o si el uso real lo demanda. si, pero eso magritte te lo soluciona, con Seaside. Yo en general programo mis paginas web magritte-oriented :)... es muy dificil que haga una página que muestra/pide datos directamente en seaside, me resulta mucho mas cómodo (por lo acostumbrado que estoy) crear un nuevo componente de magritte, si lo que hay no satisface mis necesidades. Por ejemplo, yo hace rato le puse un layer más a seaside (reef), que me permite laburar a un nivel de componentes tambien en lo "micro" (cada elemento de html), y me permite crear componentes ajax etc. de forma simple. Ademas hago mas o menos lo mismo persistiendo (con Voyage, yo no uso relacional normalmente). De forma que, sin usar "scaffolding", tengo todo eso que decís. Y ahi es donde me permito afirmar que, en Smalltalk, scaffolding es una herramienta limitada, podemos hacer cosas mejores. Lo cual me lleva a una cosa que vengo pensando desde hace rato falta en Pharo (y probablemente en toda la comunidad de Smalltalk), además de la gente que tome el kernel y lo use para desarrollar herramientas (que coincido, es algo que falta). Falta también documentación. Y no solo lo básico. Habría que escribir un libro: "Pharo en la empresa", con patrones, arquitecturas, y herramientas típicas para una aplicación de negocios hecha con Pharo. El problema, claro (como siempre), es ¿quién le pone el cascabel al gato? porque escribir un libro lleva un montón de trabajo y el tiempo no es precisamente lo que sobra :) > > Nosotros en InfOil tenemos nuestro metamodelo descriptivo que genera > editores dinámicamente, muchos son simples y rudimentarios, pero para > la mayoría no tenemos que hacer NADA. > > Si existiese algo que, a nivel web, permitiese hacer eso "muy facil", > con las URLs correspondientes, que me permita armar CRUD's minimos no > solo a nivel GUI sino tambien con persistencia (asumamos una > relacional atras, despues te todo sigue dominando), con explorer de > elementos, paginacion, ganaría muchos adeptos. > > Tendriamos que hacer una estadística nuestra, para saber cuantas > clases usan editores específicos y cuantas uno "generico" creado > dinamicamente. > >> Y donde no tiene sentido? Como smalltalkers tenemos la tendencia de >> pretender replicar todo, y hay un montón de casos en los que no vale la pena >> perder ese tiempo. En ese sentido, como comunidad tenemos que aprender mucho >> de la de python: ellos no hacen la librería, simplemente la wrappean y la >> usan. >> Ahora con NativeBoost eso no solo es posible, sino trivial. > > Si, es muy util poder wrappear las cosas, asi fue que Dolphin > implementó mucha de su funcionalidad (respaldada por un buen modelo > del lado ST). Creo que es un punto fuerte, pero de nuevo, son cosas de > kernel, ahora falta que se empiecen a hacer cosas que generen las > librerías como spinoff de un producto concreto. > > Lo de trivial, dependerá para quien :) > >> Esteban (el otro) > > (el mismo) :) > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
