Dependencias con nombre en sandro

En requirejs cuando un módulo tiene muchas dependencias a veces se complica saber qué variable corresponde a qué módulo. Para simplificar esto, ahora en sandro se pueden definir módulos así:

define({name1:"./dependency1", name2: "app/dependency2"}, function(m) {
   // m.name1 refers to ./dependency1 and m.name2 refers to app/dependency2
})

Podés usarlo en define y require, tanto en el cliente como el server.
Happy hacking,
Aureliano.

Utilidades para d3 en sandro

Estoy trabajando en sandro, y surgen cosas interesantes. Ahora empecé a hacer utilidades para d3. Lo más interesante es que hice un método que encapsula y da entidad al General Update Pattern de d3 e hice que los nodos updateados tengan que sí o sí ser hijos del nodo referenciado (en vez de cualquier descendiente), para evitar un montón de bugs que se dan eligiendo nodos.

Para usarlo en sandro es así:
define(["sandro/nadaMas/d3", function(d3h) {
  // Acá hay código tuyo, que hace aSelection
  aSelection.call( d3h.gupChildren, {
    tag: "line", // nombre del tag de la entidad a insertar (obligatorio)
    klass: "aClass", // nombre de la clase de las entidades insertadas (optional, sin clase si no está escrita)
    values: [1,2,3,4], // datos para la visualización (función o array, igual que en d3)
    key: function(d,i) {.....}, // key para los datos, opcional. Funciona igual que en d3
    onEnter: function(s, defaultOnEnter) {....}, // acciones a tomar con la selección de los nodos nuevos. Opcional. Si no es seteada solo hace append de los nodos y les setea la clase si querés hacer eso y algo más defaultOnEnter(s) hace eso y devuelve la selección para seguir operando.
    onUpdate: function(s, defaultOnUpdate) {.....}, // acciones a tomar sobre la selección de los nodos modificados (tanto agregados, como cambiados). Opcional.
    onExit: function(s, defaultOnExit) {.....}, // acciones a tomar con la selección de los nodos que no matchean con los nuevos datos. Opcional. Si no es seteada solo hace remove. Si querés hacer eso y algo más defaultOnExit(s) hace eso y devuelve la selección para seguir operando.
    onUpdateOld: function(s, defaultOnUpdateOld) {.....} // Igual que onUpdate pero solo aplica a los nodos viejos
  })
  // Y acá más código
}
Si quieren, pueden usar el código as-is si usan requirejs, o adaptarlo un toque y usarlo en el browser como más les plazca. Pero, si quieren usarlo en el server también, la mejor forma que conozco es que usen sandro.

Espero que les guste!

Módulos AMD en sandro

Ayer implementé en sandro módulos AMD, como los de requirejs. Esto debería hacer más fácil el uso de bibliotecas que usen commonjs. Acá les dejo el changeset donde está la implementación (con tests!).

Happy hacking,
Aureliano.

sandro reboot

Hace ya casi 4 años empecé un proyecto para hacer más fácil hacer páginas web seguras al que llamé sandro. Ahora estoy empezando el mismo proyecto de nuevo, siguiendo con mismas ideas rectoras:

• Un solo lenguaje en todos lados, JavaScript.
• Templating client-side y server side compartiendo código.
• Validación de datos en el cliente y server compartiendo código.
• Seguro por defecto. El diseño del framework debería hacer que sea más fácil hacer aplicaciones seguras que inseguras.

La primera versión va a estar basada en rhino, igual que la vez anterior, pero va a haber algunos cambios que creo que son importantes:

• No va a estar enfocado a correr en app-engine.
• Para mantener la idea de que haya JavaScript en todos lados, el motor de base de datos elegido va a ser mongodb.
• Para reconciliarme con la naturaleza asíncrona y mono-thread del browser, voy a cambiar el manejo de módulos de commonjs por requirejs en el cliente y una API compatible con requirejs en el server.

Si quieren ir viendo el avance del proyecto, está en un proyecto público de bitbucket.

Espero feedback y, sobre todo, pull requests.

Happy hacking,

Aureliano.