[View] [Edit] [Lock] [References] [Attachments] [History] [Home] [Changes] [Search] [Help]
Newsletter Vol. 1 Septiembre 2012
Automated translation facilities
Secciones sugeridas para newsletter vol. 1 - Septiembre 2012 (no necesariamente van todas...)
El contenido generado aqui es volcado a la maqueta
Frameworks
- Articulo sobre algun framework incluyendo una breve descripcion. Entrevista al/los autores. Link(s) a contribuciones referentes.
- Framework a decidir: PG8, A8, Google Earth Application framework, JQueryUI, etc
Plataformas en U8
Descripción de las plataformas disponibles en U8
U8 propone como inicio, 5 modalidades de ejecución de S8, llamadas plataformas.
Web
La plataforma Web provee dos modalidades:
WebBrowser: Desarrollo web, basado en imagen. La imagen inicial (u8.image.js) contiene S8, con agregados necesarios para manipular recursos del browser (DOM framework) y una herramienta básica para hacer desarrollo en la misma pagina web (en pantallas pequeñas). [Start Coding]
Headless: Desarrollo web, modular basado en contenidos de carga dinámica y bajo demanda. Headless en su forma mínima contiene la base de S8 y una expresión de booteo que determina la carga dinámica de un sistema modular, de forma eficiente y bajo demanda. El conjunto de herramientas de base es identico a la modalidad WebBrowser, aunque dinámicamente, el usuario puede cargar herramientas adicionales y/o reemplazar desde el instante de booteo el contenido del sistema; en ciclos iterativos de desarrollo. [Start Coding]
A8 Android: Ambiente de ejecución en dispositivos Android. Es un montaje de S8, sobre una interfaz nativa de booteo. Permite el uso e intercambio de objetos smalltalk a todos los niveles de la plataforma (total acceso a nivel javascript y java). A nivel de aplicación no se requiere mas que S8, gracias a las capacidades reflexivas del sistema, la interacción con elementos nativos permite el desarrollo interactivo. [Start coding]
PG8 (A8+PhoneGap): Extensión de A8 para soporte de ejecución múltiples dispositivos (iOS, Android, Blackberry, Windows Phone, Palm WebOS, Bada, Symbian). Será descripto en detalle en un artículo que publicaremos mas adelánte.
Consola
En esta plataforma se provee una versión modificada de la máquina virtual v8 de google (llamada s8vm) con el soporte mínimo de S8. El desarrollo aquí es basado en archivos, siendo la forma mas básica de desarrollar en S8. Aquí tambien es posible enlazar dinamicamente librerias externas. [Start Coding]
Server Node
En esta plataforma se provee una version de la maquina virtual Node.js con el core de S8 y facilidades para implementar aplicaciones cliente servidor en smalltalk. Tiene además soporte de llamadas API de alta eficiencia, expresables totalmente en Smalltalk (FFI framework). [Start Coding]
U8 platforms
U8 suggest as a baseline, 5 execution modes, called platforms:
The Web platform comes in two modes. WebBrowser, web development image based. An initial image (u8.image.js) contains S8, with the added resources needed to manipulate the browser (DOM framework) and a minimal tool for "in-page" development (small screens).
And Headless, modular web development, based on demand and dynamic content. Headless in its most minimal form contains the S8 core and a booting expression determining the dynamic loading of a system that is modular and efficiently mounted on demand. The basic tool set is identical to WebBrowser, but dynamically, the user can load additional tools and / or replace system contents on booting time, allowing iterative cycles of development.
A8 Android, execution enviroment for Android devices. It is a S8 montage on a native booting interface. Allows the use and exchange of smalltalk objects at all levels of the platform (total level access javascript and java). At the application level does not require more than S8, and thanks to the reflective capabilities of the system, the interaction with native elements allows the interactive development.
PG8 (PhoneGap) A8 Extension for runtime support multiple devices (iPhone OS, Android, Blackberry, Windows Phone, Palm WebOS, Bada, Symbian). It will be described in detail in future newsletter.
Console, this platform provides a modified version of the Google V8 virtual machine (called S8VM) with the S8 core. Here, development is based on files,
being the most primitive form of development in S8. On this platform you can dynamically link native libraries from third parties.
Server (Node)
This platform provides a virtual machine version of Node.js with the S8 core and facilities to develop smalltalk client-server applications. A high performance API calls mechanism is implemented at VM level and a fined grained model of foreign calls and structures (FFI framework) at smalltalk level.
Marquesina
Tomar datos automaticamente de las contribuciones y presentar las contribuciones en forma de rotator
Ultimas contribuciones
Breve descripcion de al menos las ultimas 3 contributions relevantes. Hablar con los autores, etc.
Entrevista
A definir
Adelantos/Editorial
Futuros desarrollos en U8, experimentaciones, pensamientos, visiones, direcciones tomadas en S8 & U8
Habia una vez
Desde septiembre del 2011 hemos estado trabajado duro para construir la plataforma U8. Aquí esta condensado todo nuestro esfuerzo,
sueños, y visiones compartidas. Smalltalking esta orgulloso de comenzar este newsletter y compartir con todos los usuarios de U8
el estado actual del desarrollo como asi también las futuras direcciones de este proyecto.
Es nuestro anhelo que U8 no sea una herramienta mas, sino aquella que nos permita protagonismo y autodeterminación
en las futuras direcciones de la tecnología de objetos. Como solemos decir, una herramienta para el auto desarrollo.
Once upon a time
Since september 2011 we have been working hard building U8 platform. Here is the condensation of our efforts,
dreams and shared visions. Smalltalking is proud to begin this newsletter and share with all U8 users the
U8/S8 state of the art as well the future direction of this project.
We suggest to consider U8 as a smalltalk medium to reach the next level of understanding of systems under the point of view of Object Technology. We experienced that the most powerfull features of Smalltalk emerges at early stages of U8 adoption and it is a comfortable medium for self-development.
Adelanto: MVP en U8
Pequeña charla con el autor, Miguel Isasmendi. Detalles y pormenores, etc.
Hay un trabajo reciente sobre MVP para U8/S8. Miguel Isasmendi nos cuenta detalles de este desarrollo ¿Miguel que podes contarnos de este proyecto?
Desde hace un mes y medio estoy desarrollando un framework de GUI basado en MVP. La elección de ese modelo de arquitectura por sobre otros, como un MVC clasico o Application Models, esta basada en las ventajas del modelado de una gui utilizando el concepto de MVP, la separación en capas que realiza de sus componentes, y la posiblidad de realizar tests del mismo framework.
Los features principales a los que apunto y me gustaría llegar son: serializar configuraciones de la gui (JSON), generar una arquitectura rehusable para suportar una capa de objetos nativos flexible, manejo de eventos optimizado para el uso en browsers y generar aplicaciones "desktop like" o "browser like".
¿Hasta el momento cuanta cobertura de lo que seria un GUI tradicional hay hecho?
Hasta el momento puedo instanciar un hierarchy browser utilizando presenters y vistas complejas y simples, con las cuales se implementa los widgets básicos de la gui. La idea tambien es salir un poco del concepto de gui "tradicional" (ventanas, botones, links, etc) y poder soportar vistas mas complejas con miras a, en un futuro, realizar guis realmente portables desde y/o hacia dispositivos móviles, por ejemplo.
Básicamente estoy armando las capas de abstracción superiores al framework de DOM existente para U8, aunque se podría utilizar otro framework de base de ser necesario.
Un caso testigo del cambio del contexto de desarrollo es el hecho de que el concepto de ventanas tiene que ser redefinido debido a que tenemos dos tipos de ventanas, las ventanas del browser, las cuales tienen ciertas propiedades y operaciones disponibles, y de las cuales no se puede controlar demasiado, y las ventanas "internas" las cuales pueden ser controladas casi en su totalidad.
¿Seria posible que el framework sea portable? que implicaria?
A nivel de framework si. Por debajo, en la zona de mas bajo nivel de las views (cercano al browser) aparece una capa que llamo "native views" (NativeXXXView), a este nivel es portable, es decir, este framework podria utilizarse con views que configuren objetos DOM, como con widgets de otro framework.
Una referencia obligada con respecto a MVP es Dolphin, ¿cuales serian las diferencias/similitudes?
Los puntos en comunes son ciertos protocolos de creacion manipulacion de arboles y listas de views y presenters, a pesar de que hubo cambios al ser los dominios y restricciones del ambiente distintas. Tambien la serialización de views (en nuestro caso utilizaríamos JSON).
El "bootstrap" de una view es distinto debido a tweaks de eficiencia y a lo incipiente del framework. El manejo de eventos es distinto, dado que tenemos que tratar de mantener un ambiente lo mas liviano posible, no nos seria para nada beneficioso tener demasiados manejadores de eventos para cada handle, con lo que los eventos asociados a un objeto no podrian (en principio) capturarse al sobreescribir un método #onClick por ejemplo, para el caso de querer capturar un evento de click. Los manejadores de eventos hasta ahora deben instanciarse explicitamente.
[continua en el siguiente newsletter...]
¿Se podria portar algo hecho en Dolphin?
En principio, seria dificil portar la view serializada de dolphin a este framework porque además de utilizar otro formato de serializaciòn, el modelo de views es mas liviano en terminos de responsabilidades que el de dolphin, dado que el handle es el encargado de almacenar aquellas configuraciones de estilo. Mas alla de eso y algun cambio de nombre de clase, no debería representar demasiada dificultad.
[no queda claro si es simple o complejo portar algo]
There is a recent work on MVP for U8/S8. Miguel Isasmendi talk about this development. Miguel can you tell us something about this project?
For a month and a half I am developing a GUI framework based on MVP. The choice of this architecture model over others, like a classic MVC or Application Models, is based on the advantages of modeling a gui using the concept of MVP, the separation into layers of its components, and the possibility of performing tests of the same framework.
The main features I aim and I would like are: serialize settings gui (JSON), generating a reusable architecture to support a native flexible objects layer, event handling optimized for use in browsers and building applications "desktop like "or" browser like ".
How much coverage of a traditional GUI is done?
At the moment I can instantiate a hierarchy browser using presenters and simple or complex views, which implements the basic widgets gui. I think the idea would be leave the "traditional" gui concept (windows, buttons, links, etc.) and support more complex views looking forward to make gui's truly portable from/to mobile devices, for example.
Basically i am building the abstraction layer above the DOM framework present in U8, although it could be use another framework if necessary.
A "test case" of development context change is the fact that windows concept has to be redefined because we have two types of windows, browser windows, which have certain properties and operations available, which we do not have much control, and "internal" windows which can be controlled almost entirely.
Is it possible a portable framework?
Yes. Below, in the lower level of views (close to the browser) there is a mini layer I called "native views" (NativeXXXView), at this level it is portable, ie, this framework could be used with views configuring DOM objects, as well other widgets framework.
A MVP point of reference is Dolphin. Could you mention some differences / similarities?
The common points are certain trees creation protocols and lists of views and presenters manipulation, although there were changes to be different domains and environmental constraints. Also the view serialization (in our case we would use JSON).
The "bootstrap" of a view is different because efficiency tweaks and the usual character of a budding framework. Event handling is different, since we have to try to maintain as lightweight as possible, it would not be beneficial to have too many event handlers for each handle, so events associated with an object could not (in principle ) captured by overwriting a method #onClick for example. At the moment, event handlers must be instantiated explicitly.
[continue on next newsletter...]
U8, un Smalltalk moderno.
A definir
Reuniones y charlas
Promocionar nuestras reuniones/charlas fisicas y virtuales.
Quienes somos?
Tomar un usuario de U8 y hacerle una mini entrevista
_