Especificaciones de interfaces

[Hernán Morales Durand]

Hola gente,
Si alguien tiene experiencia implementando constructores de
interface de usuario en Smalltalk, ¿podría comentar sobre algún buen
paper, reporte o simplemente ideas? Estoy interesado en lo que la
mayoría de los constructores solucionan con "Especificaciones".
Muchas gracias,

Hernán

[Gerard N. A.]

Yo estoy desarrollando un diseñador de UIs para Pharo, pero creo que en muchos aspectos es un grandísimo ejemplo de como no deben hacerse las cosas :)

No entiendo lo que son especificaciones. ¿Propiedades de los objetos?

Saludos

2009/11/27 Hernán Morales Durand <hernan....@gmail.com>

[GallegO]

Hernan:

¿Te referis a Descriptors o Aspects?

Saludos
GallegO

El día 26 de noviembre de 2009 23:26, Hernán Morales Durand
<hernan....@gmail.com> escribió:

[Hernán Morales Durand]

Hola Gallego,
Me refiero a la representación de la interface generada
dinámicamente (por un usuario) para que pueda ser regenerada por una
herramienta de edición luego.
En el constructor de SmallFaces, con Juan usamos Aspectos en el
generador de código para poder modificar en vivo un objeto de
interface, así que puede venir por el lado de lo que vos llamás
Descriptors, es decir, mi duda sería más si caminar un #windowSpec es
la mejor forma de trabajar en estos casos.
Saludos

Hernán

2009/11/27 GallegO <fxga...@gmail.com>:

[andres]

Si no me equivoco Jean Vanderdonckt
(http://www.isys.ucl.ac.be/bchi/members/jva/,
http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/v/Vanderdonckt:Jean.html,
http://www.namahn.com/resources/interview/jean-vanderdonckt-user-interface-description-languages)
trabajaba en cosas relacionadas. El objetivo creo que era, dada un spec
de GUI generar interfaces para diversos dispositivos (Desktop, mobile,
etc), pero tendrías que mirar un poco sus publicaciones.

Saludos,
Andrés

Hernán Morales Durand escribió:

[Facundo Vozzi]

Hernán,

a mí me gusta como guarda la descripción VS pero Dolphin lo serializa e igualmente funciona sin problemas.

Lo que no entiendo es porque deberías guardar la especificación de una ventana generada dinamicamente para luego modificarla con un constructor? Me podés contar como lo usan?

Un abrazo,

Facu

2009/11/27 Hernán Morales Durand <hernan....@gmail.com>

--
Facundo Vozzi
InfOil S.A.
Project Leader
(+54-11) 4542-9999 x108
fvo...@infoil.com.ar

[Hernán Morales Durand]

Algo así es exactamente lo que estaba buscando, gracias Andrés.
Saludos

Hernán

2009/11/27 andres <and...@lifia.info.unlp.edu.ar>:

[Esteban Lorenzano]

Hola Hernán,
Por ahí podrías pegarle una mirada a lo que hacen los de NakedObjects (http://www.nakedobjects.org)... no es Smalltalk, pero puede tener alguna idea que te sirva.

Saludos,
Esteban

[Hernán Morales Durand]

Hola Facundo,

2009/11/27 Facundo Vozzi <facun...@gmail.com>:

> Hernán,
> a mí me gusta como guarda la descripción VS pero Dolphin lo serializa e
> igualmente funciona sin problemas.

Sí, los Smalltalks más importantes invirtieron los recursos necesarios
para que funcione sin problemas, pero la forma en que esto es
implementado no parece ser de amplia difusión. Y sospecho que con el
tiempo se han quedado cortos, cuando la conga de las interfaces
basadas en documentos empezó a sonar, los constructores de interfaces
se quedaron sin pasta y sin baile. Es una pena porque hoy ya existen
cosas como "Ajaxificadores" y "Crawlers Ajax" y no precisamente en
Smalltalk (tampoco veo gente invirtiendo en esto, incluso gente que
quiere posicionar un modelo de negocios con Smalltalk)

> Lo que no entiendo es porque deberías guardar la especificación de una
> ventana generada dinamicamente para luego modificarla con un constructor?


Me
> podés contar como lo usan?

Sí, en estos días ensayo un resumen y te escribo.
Un abrazo

Hernán

[Hernán Morales Durand]

Hola Esteban!
Muy bueno conocerte durante Smalltalks (al igual que a muchos de
ustedes, Edgar, Alexandre, Mariano, etc). No lo conocía y parece
interesante, muchas gracias.
Saludos

Hernán

2009/11/27 Esteban Lorenzano <este...@gmail.com>:

[Hernán Morales Durand]

Para Gerard y otros interesados, aquí comenté un poco sobre (mi idea
de) especificaciones.

http://ar.groups.yahoo.com/group/smalltalking/message/17192

Saludos

Hernán

2009/11/27 Gerard N. A. <epi...@gmail.com>:

[Hernán Morales Durand]

Hola Facundo,
No sé con que nivel de detalle te interesa que te cuente, más o
menos así es como usamos el constructor de interfaces en SmallFaces,
aunque debo aclarar que es un trabajo que ha quedado por la mitad (no
era la prioridad en nuestro trabajo cotidiano) y no ha sido publicado.

El constructor se ejecuta sobre el mismo navegador web, para esto
usamos MooTools que es una librería JavaScript más rica en controles
que Scriptaculous (en ese momento no estaba portado jQuery) o al menos
fue más cómoda, en verdad había buenos argumentos a favor de MooTools
en el foro e iba a enviarles las referencias, pero el foro fue mudado
y se perdió el contenido. Fue un poco decepcionante todo esto de las
librerías JavaScript, tuvimos que armar tablas para traducir lo que
sabíamos de Scriptaculous a MooTools. Ahora la discusión es versus
jQuery...en fin, modas.

Sobre MooTools portamos a Seaside otro un par de librerías JavaScript
para el dibujado del árbol de controles y manejo de eventos,
retamañado de controles, y edición en grilla de propiedades de un
control. La interface estaba compuesta de 4 áreas: Una galería de
controles (cada control se corresponde con un objeto SmallFaces) en
forma de árbol, un área de edición de controles visual, una grilla de
edición de propiedades y un previsualizador del código generado. Todo
lo que es creación visual de controles está en el JavaScript, por ej:

var aDiv = createResizableElement("resizeImageField");
var aWidget = new Element("input", { "type": "image" });

para capturar todos los eventos en Seaside interceptamos #start:
redirigiendo el #initialRequest desde el root actual:

root visiblePresentersDo: [:ea | ea initialRequest: aRequest].

el Request estaba configurado como para obtener y actualizar todas las
propiedades modificables de un control, algo así

aControlProperty perform: (aRequest fields at: 'attribute') asMutator
with: (aRequest fields at: 'value')

La secuencia era más o menos:

-El usuario escribe el nombre de la clase a crear (WAExampleBuilded)
-Selecciona un control de una lista
-Se agrega un nodo en el árbol de la interface, esto también inserta
el control dentro de un retamañador.
-Se agrega un nodo en el árbol del modelo
-Se selecciona el nodo desde la interface
--Aparece un editor en grilla para el control seleccionado en la
interface (esto configura una cookie con el identificador del control
y un updater en la función addEvent de MooTools para dibujar un editor
de propiedades).
--Se configura el control desde la grilla, actualizando el editor de
código mediante un callback en el updater del paso anterior.
---La previsualización del control se realiza automáticamente con otro
updater que va actualizando a medida que se deselecciona cada campo de
entrada de la grilla.
---Durante la previsualización un acumulador de código genera la
cadena de creación y se compila este código.
-Al finalizar, se generaba el #renderContentOn: en WAExampleBuilded
recorriendo el árbol e instalando los método compilados en su
diccionario de clases.

También agregamos una papelera de reciclaje sobre la cual uno
arrastraba el control y desaparecía, esto significaba enlazar algunos
eventos JavaScript más, etc. Bueno, tal vez en estos días suba un
video si alguien está interesado.
Saludos

Hernán

2009/11/27 Facundo Vozzi <facun...@gmail.com>:

[Guillermo Sapaya]

Hola Hernan,

<gran SNIP>

> También agregamos una papelera de reciclaje sobre la cual uno
> arrastraba el control y desaparecía, esto significaba enlazar algunos
> eventos JavaScript más, etc. Bueno, tal vez en estos días suba un
> video si alguien está interesado.

Yo estoy interesado!

> Saludos
>
> Hernán

Saludos, Guiye

[Gerard N. A.]

Mis conocimientos sobre Smalltalk y programación en general son muy pobres, no so sorprendais de la cutrez de mis métodos :)).

En mi constructor de UIs lo que he hecho es especificar en la class side de cada widget los accesors que se tienen que "registrar" en el método que construye la interfaz ( lo que vendria a ser el "spec" de VisualWorks ) y unas clases "Designer" que se encargan de la serialización de cada widget y sus subwidgets. No es una manera muy correcta, pero dadas mis limitaciones quizás las más fácil de asumir para mí. Me imagino que el principal problema es que es dificilmente exportable a otros tipos de UI que no sean Morphic.

El resultado en código de una sencilla vista con dos botones, una caja de texto y un label puede ser -> http://paste.lisp.org/display/91343

La relación de eventos de los controles con los métodos que los gestionan se realiza en otro método, y el resultado es por ejemplo


specEvents

    | dict |

    dict := Dictionary new.

    dict add: #container->{#onDeleted -> #containerOnDeleted:args:.}.
    dict add: #btnAccept->{#onClick -> #btnAcceptOnClick:args:.}.
    dict add: #txtName->{#onKeyStroke -> #txtNameOnKeyStroke:args:.}.
    dict add: #btnCancel->{#onClick -> #btnCancelOnClick:args:.}.
   
    ^dict


Repito, no es la manera más correcta pero sí la que me ha permitido solucionarlo de una manera relativamente rápida  :|  y asequible para mis conocimientos.

PD.  No entenderé nunca que la gente de Pharo/Squeak no le dé practicamente ninguna importancia a temas como estos. Seria impensable un Visual Studio o cualquier entorno de desarrollo decente en el que no hubiera un constructor de formularios hecho y derecho. Las mentes más preclaras ( Ducasse y cía ) deberían de encargarse de cosas tan importantes como estas, y no pringados como yo :))

2009/12/1 Hernán Morales Durand <hernan....@gmail.com>

[GallegO]

Hernan:

No comprendo bien cuál es tu duda sobre los specs. Las distintas
formas de hacerlo tienen ventajas y desventajas pero siempre tenes que
pensar que tu spec seguramente referencie objetos que pueden llegar a
sufrir refactorings y eso es lo que tenes que soportar...

Nosotros estamos llevando casi toda la persistencia* a specs de
código. Eso es porque no tenemos Gemstone. Pero bueno suponiendo que
el spec de una GUI no tiene como prerequisito un Gemstone lo haria con
codigo St y, si queres laburar un poco menos, una serializacion en
literales como en Dolphin 6 que tiene la ventaja de ser vista por el
Refactoring Browser. Tenes que tener en cuenta las limitaciones del
compilador, por lo que lei ya lo tenes claro eso.

Espero haber entendido, sino, chifla :)

* Me refiero a persistencia de objetos que no son transacciones de los
usuarios, sino mas bien cosas de configuracion o e-spec-ificacion de
un sistema.

Saludos
GallegO

El día 1 de diciembre de 2009 10:10, Hernán Morales Durand
<hernan....@gmail.com> escribió:
>

[Facundo Vozzi]

Hernán, como va?

Bueno, primero que todo gracias por contar un poco lo que hacen. Si me parece interesante el tema así que si querés mandar un video estaría bueno.

Lo unico que no me queda claro es porque necesitas modificar, con el builder, una interfaz construida dinámicamente? Es decir, si se construyo dinámicamente (podria ser a la magritte) la idea sería que no se modifique (a "mano") después así la ventana se sigue comportando dinámicamente, no ?

O uds. le dan el editor de ventanas al usuario para que las modifique el mismo? Y si es así que pasa después con esas modificaciones cuando le agregas un nuevo descriptor al objeto esperando que dinámicamente aparezca en la GUI ?

Un Abrazo,

Facu

P.D.: a esta altura creo que yo te entendí mal en tu primer mail porque me parece que vos le decís dinámicamente a crearla con el builder (es más dinámico que hacerlo a manopla) y creo que yo estaba pensando en magritte o en algo de ese estilo.

2009/12/1 Hernán Morales Durand <hernan....@gmail.com>

[Hernán Morales Durand]

Hola Facundo, todo bien

2009/12/2 Facundo Vozzi <facun...@gmail.com>:

> Hernán, como va?
> Bueno, primero que todo gracias por contar un poco lo que hacen. Si me
> parece interesante el tema así que si querés mandar un video estaría bueno.
> Lo unico que no me queda claro es porque necesitas modificar, con el
> builder, una interfaz construida dinámicamente?

No, no la construimos dinámicamente, sino que usamos un editor visual
con el cual un supuesto diseñador de interfaces va armando una UI (en
la práctica, en el Estado uno mismo tiene que hacer las interfaces,
probarlas, etc) y se genera y escribe código a partir de lo que existe
en ese momento en el editor visual (al estilo de WindowBuilder Pro).

Creo que se está lejos de hacer algo de calidad con interfaces
inferidas a partir de modelos dinámicos, hay un libro muy bueno que te
puede gustar leer : "GUI Bloopers 2.0: Common User Interface Design
Don’ts and Dos" de Jeff Johnson

http://www.amazon.com/GUI-Bloopers-2-0-Second-Technologies/dp/0123706432/ref=dp_ob_title_bk

y hasta la especificación de CSS 2 está verde en varios aspectos.

> Es decir, si se construyo
> dinámicamente (podria ser a la magritte) la idea sería que no se modifique
> (a "mano") después así la ventana se sigue comportando dinámicamente, no ?
> O uds. le dan el editor de ventanas al usuario para que las modifique el
> mismo? Y si es así que pasa después con esas modificaciones cuando le
> agregas un nuevo descriptor al objeto esperando que dinámicamente aparezca
> en la GUI ?
> Un Abrazo,

Otro,

Hernán