Con el incremento del trabajo que se realiza en el lado del cliente (navegador), también han empezado a aparecer patrones de programación que, hasta el momento, eran exclusivos del servidor de aplicaciones. Así, por ejemplo, la estructuración de código con MVC (Modelo-Vista-Controlador) ha sido ya implementada con Javascript (ver Javascript MVC o TrimPath [introducido aquí] ). Estos proyectos posibilitan crear complejos proyectos ejecutados y gestionados en el lado del cliente dejando únicamente al servidor el almacenamiento de la información.

Otro terreno que también ha sido portado en varias ocasiones es el de los patrones o templates, muy relacionado con las vistas en la distribución MVC. Contando con un sistema de este tipo podemos guardar segmentos de código HTML que, procesados desde Javascript y combinándolos con variables, permiten personalizar las vistas y reaccionar a las entrada del usuario directamente desde el cliente, eliminando el tiempo necesario para conectar con el servidor y que éste procese la información antes de enviarla de vuelta.

Se podría decir que esta es una pieza conveniente para llegar más allá de lo que supone Ajax. Si con Ajax es posible alcanzar el servidor sin perder el tiempo en tener que recargar la página, con esta técnica evitamos el tener que acudir al servidor (siempre que esto sea posible) ya sea cacheando la información en local (Google Gears o Yahoo! BrowserPlus) o manteniendo ya una conexión abierta con el servidor mediante Comet para reducir el tiempo de respuesta.

A continuación pueden verse unas cuantas de estas librerías:

• Javascript Micro-Templating de John Resig.

  <% for ( var i = 0; i < users.length; i++ ) { %>
    <li><a href="<%=users[i].url%>"><%=users[i].name%></a></li>
  <% } %>

var results = document.getElementById("results").innerHTML = tmpl("item_tmpl", dataObject);

• JavascriptTemplates forma parte del proyecto TrimPath Junction (MVC).

    <textarea id="cart_jst" style="display:none;">
      Hello ${customer.first} ${customer.last}.
    </textarea>
  

  var data = { customer : { first: "John", last: "Public", level: "gold" } }
  var result = TrimPath.processDOMTemplate("cart_jst", data);
  

• EcmaScriptTemplates (ESTE) es un sistema de templates alternativos también soportados por TrimPath Junction (MVC).

  BlogController = function() {}
  BlogController.prototype.show = function(req, res) {
    res.blog = Blog.find('first', req['objId']);
    res.render('blog/show'); 
  }
  

• Unobstrusive JavaScript Template Engine basado en jQuery confía en no usar una sintaxis especial para indicar los lugares de reemplazo. En su lugar utiliza el atributo classes del CSS y utiliza JSON para indicar los datos a reemplazar:

  <div id="hello">
    Hello <span class="who">World</span>
  </div>
  

  $('#hello').autoRender({ "who": "Mary" });
  

• EJS (Embedded JavaScript)

  var data={   title:   'Cleaning Supplies'
   supplies:  ['mop', 'broom', 'duster']  }
  html = new EJS({url: '/template.ejs'}).render(data)
  new EJS({url:'/todo.ejs'}).update('todo','/todo.json')
  

  <ul>
  <% for(var i=0; i
     <li><%= supplies[i] %></li>
  <% } %>
  </ul>
  

• Client-Side JavaScript Templates explica paso a paso como utilizar la técnica en el cliente con la ayuda de un archivo templates.js
• Este artículo de ParticleTree habla de varios sistemas como JST de TrimPath, AjaxPages, el sistema de templates de la librería Prototype, ESTE o SXOOP.
• Sxoop.template es otro sistema ligero. Aunque su código parece no estar disponible en la URL indicada, lo he encontrado aquí, junto con un ejemplo.
• JSLT es una librería que propone un estilo similar al del lenguaje XSLT. Ver ejemplo.

  [foreach('folder'){]
     [var c = count('file')]
     Folder {@name} has [%c] file[if(c>1)%'s']\n
     [sort('file','text()',sort_alpha){]\s
        File: [%$'text()'.toLowerCase();]
        [if(!last)%',']
     [}]\n
  [}]
  

• Chain.js es un sencillo plugin de jQuery que facilita la capacidad de asociar datos en formato JSON a los elementos del DOM (XHTML).
• Patroon utiliza el mismo sistema que Unobstrusive JavaScript Template Engine: utilizar clases CSS e identificadores para indicar dónde deben introducirse los datos.

  <div class="comments">  
    <div id="comments-template">
      <div class="comment">
        <div class="_ top">
          <a class="_" href="{website}">{name}</a> said
          <a class="_" title="{time}"></a>:
        </div>
        <div class="text"></div>
      </div>   
    </div>
  </div>
  

  var data = { 
    comment: [{
      date: "2008-09-07 12:28:33", 
      name: "David Beckham",
      website: "beckham.com",
      text: "I watched the euro finals on tv..." 
    }]
  };
  var template = new Template('comments-template');
  $('.comments').expand(template, data); // con jQuery
  

• Aunque jsAwesome no es exactamente un sistema de templates, aporta una herramienta similar ya que permite especificar mediante Json un formulario completo con distintos tipos de validaciones.

Por cierto, interesante el método que propuso en su día John Resig para incluir segmentos de código XHTML en la página sin que sea interpretado por el navegador, algo ideal para guardar los templates:

<script type="text/html" id="item_tmpl">
Este texto <strong>NO</strong> aparecería en la página
</script>

Hace unos años estuve leyendo sobre programación genética. Al igual que Gaudí y sus estructuras que imitan la naturaleza, se trata de aprovechar los problemas que la naturaleza ya ha resuelto y aplicar su metodología a las ciencias humanas para intentar alcanzar un óptimo. Aplicado a un algoritmo, se trataría de identificar una serie de variables de entrada y una serie de indicadores que puedan utilizarse para calcular la idoneidad de unas variables de entrada en concreto. Es decir, un algoritmo genético se basa en hacer pruebas con un primer conjunto de variables de entrada aleatorias y evaluar numéricamente la salida, de forma que aquellos conjuntos de entrada que tengan mejores resultados tendrán más valores de entrada respetados para la siguiente iteración de pruebas. Con una cantidad suficiente de iteraciones, los valores de entrada idóneos empezarán a perfilarse hasta que se alcancen óptimos.

Un último ajuste de estos algoritmos es evitar los óptimos relativos (es decir, que por el conjunto de valores de entrada inicial no se descubra que con cierta combinación hay un óptimo mejor que el que se conseguiría si sólo se utilizase el mecanismo de la adaptación) así que, siguiendo a la naturaleza de nuevo, incorporaríamos el mecanismo de la mutación que espontáneamente introduciría un conjunto de valores de entrada con fuertes variaciones respecto al resto.

John Resig mencionó hace poco la existencia de una librería Javascript llamada Genetify con la finalidad de utilizar la programación genética en el cliente para, mediante CSS, mostrar disposiciones distintas de los elementos según la visita. Aunque menciona como finalidad la de averiguar la posición idónea para ubicar publicidad en una página, existen multitud de usos en los que una tecnología como ésta puede resultar útil: resultados de un buscador, recomendadores, etc.

Un ejemplo de página que utilice Genetify sería el siguiente:

<html>

<head>

<script src="genetify.js"></script>
<style>
  .v { display: none; }
  .genetify_disabled { display: none !important; }
  .genetify_enabled { display: block !important; }
</style> 

</head>
<body>


<div class="sentence">One way of saying something</div>           
<div class="sentence v anotherway">Another way of saying something</div>

<input type="button" onclick="continuar()" value="continuar..." />

<script>
// cuando el usuario haya realizado las acciones que
// comporten suficiente información como para evaluar "esta variación"
// se utiliza 
function continuar() {
  genetify.record.goal('signup', 100); // donde 100 es la valoración de esta variación
  location.href="pantallasiguiente.html";
}
</script>

<script>
// la siguiente línea genera la variación "genética" de la página
// basada en datos de idoneidad anteriores y en mutaciones aleatorias
genetify.vary();
</script>

</body>
</html>

Con la aparición en los últimos tiempos de los problemas de seguridad en los navegadores, potenciados por la misma permisividad que ha hecho crecer la web hasta lo que es hoy, han ido surgiendo voces que piden empezar a planear el futuro y evitar que se llegue a un punto sin retorno en el que la web abierta tal y como la conocemos empiece a ceder terreno ante otras alternativas propietarias como Flash, Flex, Silverlight o similares.

En este post de Brad Neuberg en Ajaxian se propone un plan de actuación basado en los siguientes puntos:

1. Hacer que el desarrollo web sea aún más fácil y potente, atacando cuatro puntos:
   
   
   • Layout o distribución del contenido buscando un método alternativo al CSS para definir capas, columnas, etc. y que no sea necesario ser un experto para poder obtener el resultado buscado.
   • Potenciar Javascript para que soporte proyectos más grandes.
   • Mejor soporte multimedia nativo en el navegador con soporte de vídeo, gráficos vectoriales y animaciones fluidas.
   • Mejores herramientas de desarrollo como IDEs.
2. Resolver el problema de los estándares dado que hay una desconexión real entre las necesidades de los desarrolladores y lo que el W3C propone, generando un peligroso vacío que una empresas podría rellenar.
3. Resolver el problema de la distribución de los componentes necesarios, algo que tanto Google Gears como Yahoo! BrowserPlus (a los que dedicaré otro artículo) están intentando resolver. Mucha de la culpa la tiene IE, históricamente empeñado en huir de cualquier acuerdo estándar o de facto que respeten el resto de competidores.
4. Resolver el problema de la innovación. Lamentablemente, muchas de las novedades que han surgido en los últimos tiempos tienen a Flash o a Silverlight como soporte necesario. Aunque Mozilla ha realizado una labor excelente proponiendo nuevas tecnologías, no es suficiente.

En una línea parecida, John Resig hablaba hace unos días de los avances en la compleja tecnología que blindará el control de accesos a recursos de vídeos de forma que se pueda indicar desde qué dominios se permitirá acceso a un vídeo alojado en una página propia. Sin duda, esto acarreará más complejidad a la hora de controlar quién y cómo se tiene acceso a los recursos, un sistema de control que debería haberse implementado desde el principio de la web, pero que también hubiese implicado una complejidad mucho mayor frenando su desarrollo.

Ya hace muchos meses que disfrutamos del estándar OpenID, de hecho hace unos pocos apareció la versión 2.0 con importantes novedades. Si tenemos una cuenta con un proveedor OpenID (como Yahoo!, Google o el mismo Openid.com, por ejemplo), podemos utilizar los servicios ofrecidos para autenticarnos en otro sitio que acepte dicho estándar.

RPX es una compañía que aprovecha dicha posibilidad para facilitar aún más la implementación del sistema de registro para un nuevo proyecto o para facilitar la identificación de nuevos usuarios en proyectos ya existentes. Puesto que la mayoría de sitios únicamente necesitan un nombre de usuario para identificar a sus visitantes y la contraseña sólo es utilizada para verificar la propiedad de dicho nombre de usuario, la inmensa mayoría de los sitios deberían tener suficiente con un sistema de registro gestionado por terceros, eliminando así una de las necesidades a la hora de crear y mantener un proyecto.

Funcionamiento

Al pulsar sobre el botón de registro (1), el usuario es dirigido a la página del proveedor elegido (2) para que se autentique allí (3). El proceso se gestiona desde RPX que redirige a nuestra página con las credenciales del usuario (4 y 5). Para que la información no viaje en el navegador, se facilita un token que será usado en nuestro servidor para obtener más información sobre el usuario (5 y 6). Finalmente, en nuestro servidor se actualizan los datos del usuario sin necesidad de guardar su clave (7). Opcionalmente, es posible utilizar RPX como almacén de las identidades del usuario para no tener que hacerlo en el servidor propio (por ejemplo cuando hay varios proveedores OpenID para un mismo usuario).

Enlace: rpxnow.com

...y además es una aplicación web creada enteramente con Javascript: En el servidor, en el cliente, y hasta en la base de datos. Los responsables de AppJet (un excelente servicio online de alojamiento de aplicaciones Javascript abiertas) han creado un producto que demuestra al 100% la filosofía y la forma de pensar que inunda la compañía. Utiliza tecnología Comet (conexión persistente entre cliente y servidor) para difundir los cambios entre todos los clientes que estén editando el documento.



Junto con Helma y Aptana Jaxer, AppJet supone una sólida alternativa para la extensión del lenguaje Javascript al servidor.

Link: Eherpad.

Aunque ya tiene un tiempo, resulta curioso comentar este antiguo proyecto de Brendan Eich (uno de los inventores de JavaScript), que en la actualidad puede cobrar importancia debido a los problemas de seguridad que están apareciendo por confiar en código introducido por los usuarios.

Narcissus es un motor que interpreta Javascript, como el del propio navegador, pero con la pecualiaridad de estar escrito con ese lenguaje. En este caso, Eich, como autor de SpiderMonkey, el motor de Firefox, utiliza muchas extensiones específicas que no son estándar, de las cuales una ha sido creada a propósito para hacer posible este motor. Se trata, por tanto, de otro motor más para el lenguaje, pero con ese mérito que, pese a esas extensiones, demuestra la flexibilidad del código sin recurrir al evidente eval() que ya incorpora el lenguaje.

Narcissus.

Una de las razones por las que se habla tanto de CouchDB es que supone una rotura importante con todo aquello que durante años hemos considerado sagrado: que las bases de datos relacionales eran el camino correcto.

Ciertamente, ha existido una clasificación no oficial de las bases de datos en la que Access resultaría ser un juguete, MySql sería el simpático, potente y gratuito equivalente a Linux y Oracle sería el no va más, el último escalón. Sin embargo, esa clasificación basada en marcas esconde el hecho de que todas ellas son bases de datos relacionales. Quizás nunca se hubiese llegado al punto actual de replanteamiento de alternativas de no ser por la cantidad de sitios web que, obligados a servir millones de páginas diarias, han chocado con una más que importante limitación: la escalabilidad.

Tanto CouchDB, como Graphd (la base de datos usada por Freebase), como muchas otras que estan surgiendo, siguen un patrón muy similar orientado a facilitar la escalabilidad de los servidores. La idea es seguir un modelo en el que cualquier modificación (inserción, modificación o eliminación) implica escribir un nuevo registro al final del espacio disponible pero sin eliminar el registro anterior, de tal forma que queda documentado en un histórico de modificaciones al estilo de un wiki, pudiendo conocer el estado de un registro en cualquier momento del pasado.

En general, estas bases actuan como un almacén de tuplas en las que se incluyen, entre otros campos, un identificador y un campo de tipo texto capaz de albergar datos de cualquier tipo de un modo 'semi-estructurado'. Por ejemplo, CouchDB apuesta por Json. Un buen ejemplo es lotsofwords.com, proyecto de Carlos Villela que ha utilizado CouchDB para guardar los 120GB de datos de la wikipedia (más de 21 millones de documentos) y permitir búsquedas de todo tipo en unos 200 milisegundos.

Para realizar una consulta, algunos optan por utilizar un registro en el que se dejan vacíos los campos que se quieren consultar y se rellenan los campos que se quieran introducir para filtrar la búsqueda. Otros solicitan una función de filtrado. Posteriormente, se usan distintas técnicas (como Map+Reduce) para filtrar los registros y clasificarlos.

Además, se plantea una relajación del estándar ACID (Atomicidad, Consistencia, aIslamiento y Durabilidad) en favor de la disponibilidad y alejándose de la consistencia en lo que se conoce como BASE. El objetivo es aumentar el rendimiento mediante el uso de una 'cola de cambios' que es tratada posteriormente por otro proceso o en un momento de menor carga del sistema. La consecuencia inmediata es la aparición de posibles incoherencias entre el momento de la operación y el momento en el que el procesamiento de los mensajes de la cola que aseguran que los datos recuperan su coherencia.

En cualquier caso, se trata de importantes novedades a la hora de almacenar la información después de décadas en las que las bases de datos relacionales han sido prácticamente la única alternativa disponible.

Addendum: Lo explica con mucho mayor detalle Enrique Barreiro.

---

Increíble pero cierto, aunque suene a tópico, algo tan irreal está convirtiéndose en realidad. Las titulaciones en ingeniería informática dejarán de tener valor ni ser convalidables con ninguna otra carrera presente o futura, aunque se mantienen, pierden la posibilidad de tener un documento referencial sobre el que basarse, introduciendo una heterogeneidad que puede condenar definitivamente a la carrera. El intrusismo que los informáticos hemos denunciado toda la vida (cualquier matemático, teleco, industrial, físico o químico se atribuía automáticamente los mismos conocimientos) no sólo se ha convertido en oficial, es que ha anulado completamente la ingeniería como tal. Quiero pensar que es sólo una broma pesada y esto no se va a quedar así... Tomado de BandaAncha.eu: El pasado 23 de octubre el Ministerio de Educación presentó las fichas de los nuevos títulos de grado y master de todas las ingenierías menos la de informática cumpliendose así los peores presagios. La excusa ha sido que nuestra ingeniería no tiene atribuciones y que la informática es una materia transversal y por lo tanto no debe de concentrarse en una titulación concreta. Al día de hoy las consecuencias de esta situación son:

• Desaparece la ingeniería en informática. Se cumple el deseo de muchos. Por fin desapareceremos y dejamos el camino libre al ejercito de aficionados y "reciclados" para erigirse como los nuevos y verdaderos informáticos. Dejaremos de ser un problema.
• Nuestros títulos no serán homologables a ninguno al no existir correspondencia con los nuevos títulos.
• Nunca tendremos atribuciones profesionales. No la hemos tenido hasta ahora y al desaparecer ya no las tendremos nunca. No sabemos que pasará con los nuevos títulos aunque por su caracter local a cada universidad no parece posible que lleguen a tener atribuciones.
• Los títulos actuales no tendrán validez. Al no poder homologarnos con los nuevos títulos que pudieran aparecer en el futuro nuestros actuales títulos iran perdiendo validez y se quedarán como el recuerdo del mayor engaño del sistema educativo español.
• Los actuales estudiantes están siendo objeto de engaño. Las universidades no informan temiendo una huida en masa que dejarían vacías a las escuelas de informática.
• No podremos trabajar en Europa. Al no existir por lo dicho en los puntos anteriores, nuestros títulos no se corresponderán a ningún título europeo. Las nuevas fichas de ingenieros de telecomunicación recogen las competencias de la informática por lo que serán ellos quién se queden con nuestra parcela de trabajo.
• Las universidades tendrán autonomía para inventar títulos relacionados con la tecnología de forma local y diferente entre ellas. Las universidades privadas harán su agosto y por fin todo el sistema universitario cumplirá su sueño de que todo el mundo pueda ser informático con independencia de sus estudios.

Evidentemente no nos vamos a quedar quietos viendo como nos pisotean. El próximo sabado 8 de noviembre se ha convocado una reunión de los Decanos de todos los Colegios de España en Madrid para coordinar las medidas a tomar. De igual manera nos estamos coordinando con la CODDI (COnferencia de Decanos y Directores de Informática), con ALI, AII2 y RITSI. Las acciones que se barajan pasan por todas las posibles, desde acciones legales a movilizaciones. Pero hay una actividad fundamental que hay que realizar y que está nuestra mano. Ahora más que nunca solicitamos la colaboración de todos los ingenieros en informática para que se difunda esta información. Es necesario que todos sepan lo que está pasando. La táctica que ha seguido el Gobierno ha sido la de la desinformación. De hecho la incredulidad ha provocado que muchos ingenieros en informática no hayan creido que esto pudiera ocurrir y estamos seguro que todavía existen dudas. Esta situación es real y está ocurriendo ahora mismo.

Pregunta para Robert O'Callahan de Mozilla.org, via Ajaxian: Conforme los navegadores intentan alcanzar a los servicios de escritorio a través de las nuevas APIs, de las grandes aplicaciones de navegador de una sola página, y del uso de la tecnología web en el escritorio (estilo AIR), ¿empezamos a mezclar el mundo del escritorio y la Web de forma que no se pueda ver la diferencia?
¿Se van a converger completamente?

No lo creo. Aquí están las características que creo que son esenciales para hablar de aplicaciones Web:

• Direccionamiento por URL: Se accede a una aplicación Web cargando una URL. Puedes enlazar a la aplicación web desde otras páginas Web, puedes guardar su URL en favoritos o crear accesos directos en el escritorio, y se pueden pasar las URL a tus amigos.
• Siempre ejecutada controladamente (sandboxed): Los usuarios no pueden tomar buenas decisiones que sean de confianza, de modo que las aplicaciones deben estar siempre controladas en una caja de arena (sandbox). Uno de los temas de la evolución de la plataforma Web es encontrar formas de diseñar APIs e interfícies de usuario de navegador para que podamos conceder el acceso a características de la plataforma a aplicaciones no fiables. Por ejemplo, a las aplicaciones Web no se les puede conceder acceso general al sistema de archivos, pero podemos satisfacer a la mayoría de las necesidades con almacenamiento persistente por dominio y un control <input type="file" /> que sea fiable para permitir el acceso de una aplicación a archivos particulares
• Área del navegador: Las aplicaciones web se utilizan en el contexto de un navegador. Los botones de avanzar y retroceder están disponibles (y por lo general ¡funcionan!), ofreciendo una interfície de usuario universal de navegación a través de las aplicaciones. Los favoritos están disponibles, el estado está disponible, el historial está disponible, recargar, detener, organizar en pestañas, etc. Muchos de los diseñadores desearían poder escapar del área del navegador, pero los requisitos del sandbox lo hacen poco realista, y la comodidad de la interfície común del navegador no debería subestimada.
• Caja abierta: Las aplicaciones Web tienen una estructura interna que está expuesta al navegador y a las herramientas basadas en el navegador. Esto permite que herramientas como Greasemonkey alcancen y manipulen el contenido Web. Permite características del navegador como zoom del texto o "encontrar en la página". Permite el trabajo de los motores de búsqueda. Permite hojas de estilo de usuario y otros tipos de personalización de la experiencia Web. También crea un entorno de pseudo-código-abierto, donde los autores pueden aprender como funcionan otras aplicaciones, incluso aunque no puedan modificar o reutilizar ese código directamente.

Via Ajaxian. El JavaScript Infovis Toolkit(JIT) es una librería Javascript que permite la visualización animada de información arbórea (con forma de árbol) siguiendo ciertas estructuras como grafos radiales o mapas arbóreos. Últimamente también permite representar grafos con arcos y nodos como se puede ver en este ejemplo. Además permite trabajar con datos mutables (que varían con el tiempo) de forma que, mediante suaves animaciones, es posible observar los cambios de estado de un grafo. El usuario puede interactuar navegando entre los distintos niveles de profundidad y alterando la información en tiempo real. Algunos ejemplos:

Hace unas semanas probé algunos de los problemas de Google Code Jam y, me quedé en cierta fase en parte por culpa de la falta de rendimiento del motor de Javascript del navegador sobre el que estaba probando (Firefox).

Hoy la cosa pinta bien distinta. A parte de que prácticamente todos los navegadores (Chrome, Firefox, Safari, y Opera) han multiplicado el rendimiento de dichos motores con muy buenas optimizaciones, empiezan a aparecer herramientas como JSLibs.

Se trata de un entorno de desarrollo para usar JavaScript como un lenguaje interpretado de propósito general. Utiliza el motor SpiderMonkey (Firefox) aunque en breve se actualizará al más optimizado TraceMonkey. Facilita una serie de módulos nativos que contiene varias clases y funciones como: zlib, SQLite, FastCGI, NSPR _{(Netscape Portable Runtime)} , ODE _{(Open Dynamics Engine)} , libpng, libjpeg, librsvg, SDL, libiconv, OpenGL, OpenAL, ogg vorbis, libTomCrypt, libffi _{(Foreign function interface)} , ... con funciones como: Print(), Load(), Exec(), Seal(), Expand(), Buffer class, Blob class, Sandbox class, ...

Un pequeño programa de acceso por consola (jshost) puede ser utilizado para ejecutar archivos Javascript, mientras que hay una versión para Windows (jswinhost) sin consola.  


Como ejemplo, el siguiente código muestra un icono en la barra de tareas de Windows que muestra un menú con dos opciones ("agregar" y "salir"), con la función de agregar elementos de programas para poder lanzarlos desde ese menú.

LoadModule('jsstd');
LoadModule('jswinshell');

var s = new Systray();
s.icon = new Icon( 0 );
s.menu = { add:'Add', exit:'Exit', s1:{ separator:true } };
s.onmousedown = s.PopupMenu;

s.oncommand = function( id, button ) {

 switch ( id ) {
  case 'exit':
   return true;
  case 'add':
   var fileName = FileOpenDialog( 'Programas|*.exe;*.com;*.cmd;*.bat|todos los archivos|*.*' );
   if ( !fileName )
    return;
   s.menu[fileName] = { 
    icon: ExtractIcon( fileName ), 
    text: fileName.substr( fileName.lastIndexOf( '\\' ) + 1 )
   };
   break;
  default:
   if ( button == 1 ) // left-click to run.
    CreateProcess( id );
   else // right-click to remove.
    if ( MessageBox( 'Eliminar elemento: ' + id + '? ', 'Question', MB_YESNO) == IDYES )
     delete s.menu[id];
  }
}

do { Sleep(100) } while ( !s.ProcessEvents() ); // bucle indefinido con pausas de 100 ms