<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" xmlns:ns1="*">
<mx:Button label="Saludo" id="btnSaludo" enabled="true" click="saludar()" />
<mx:Script >
<![CDATA[
import mx.controls.Alert;
import mx.rpc.events.ResultEvent;
private function saludar():void{
Alert.show('hola');
}
]]>
</mx:Script>
</mx:Application>
sábado, 1 de noviembre de 2008
Hola Flex
domingo, 22 de junio de 2008
datamapper
Pero había algo bastante feo en la version 0.3; cada vez que modificabas el modelo y le decías que actualice la base de datos, borraba todos los datos que tenías en ella.
Con la salida de la versión 0.9 de DataMapper se solucionó el problema de perder todos los datos de la base por cada dm:db:automigrate. Ahora existe dm:db:autoupgrade que se encarga de actualizar la base de datos según lo definición de los modelos preservando la información que está en las tablas. Parece ser una buena solución frente al problema que tiene ActiveRecord cuando no se trata de un proyecto de una sola persona (se crean muchos conflictos con los commits de los migrations). La solución de DataMapper es olvidarse de la base de datos, actualizo mis modelos aplicando patchs, haciendo merges, lo que fuera. Luego hago un upgrade y la base siempre corresponde a la definicón de los modelos.
Otro cambio importante es que ya no es necesario que las clases que nos interesa persistir hereden de una clase especial como sucede con la mayoría de los ORM's. Entonces nos queda la herencia disponible para algún uso más interesante.
class Page
include DataMapper::Resource
end
También perdió un poco de automagia que tenía respecto a la definición de las primary keys. Ahora hay que definir a mano la pk de cada modelo, como cualquier otro atributo:
class Page
include DataMapper::Resource
property :id, Integer, :serial => true
end
Está muy buena la sintaxis para definir las relaciones "has_many":
class Page
include DataMapper::Resource
property :id, Integer, :serial => true
has 1..3, :columns
has n, :html_controls
end
viernes, 11 de abril de 2008
árbol en rails
children() – all immediate children of current object
parent() – first ancestor of the current object
siblings() – all children of my parent excluding me
self_and_siblings() all children of my parent including me
ancestors() all parent, grandparent, etc… object up to root
root() the base object we descended from in the tree
class BoxAddReferenceToParent <>
class Box < ActiveRecord::Base
class Box < ActiveRecord::Base
miércoles, 6 de febrero de 2008
mootools: sortable of sortables
Armé una demo de un sortable que contiene a otros tres sortables. Hace un tiempo había hecho la misma prueba pero con prototype+scriptaculus, la verdad que es mucho mas transparente con mootools y el código queda mucho mas limpio:
var master = new Sortables('master', { handle: 'span'});
var mySortables = new Sortables([$('lista_A'), $('lista_B'), $('lista_C')], {
cloneOpacity: 0.4,
elementOpacity: 0.8
});
La demo está funcionando en opera, safari, firefox, iexplorer y camino sin tener que hacer ningún hack por el browser; mootools se encarga solito!
En la demo se pueden dragear los items dentro de una misma lista, entre las listas y también se puede hacer un drag desde la parte naranja para intercambiar una lista completa con otra.
Esta es otra demo que encontré pero usa scriptaculus.
martes, 5 de febrero de 2008
script tag
¿Qué pasó? No había cerrado el tag de script en forma explícita.
Para el tag script la w3c dice: Start tag: required, End tag: required
<script scr="mootools.js" />
La forma correcta es:
<script scr="mootools.js"></script>
Dejo 2 links al respecto: