import sys, pdb
for attr in ('stdin', 'stdout', 'stderr'):
    setattr(sys, attr, getattr(sys, '__%s__' % attr))
pdb.set_trace()

Yo lo he encapsulado en un fichero, así puedo usarlo más o menos como antes. Lo he llamado gpdb.py:

import sys
import pdb

def set_trace():
    for attr in ('stdin', 'stdout', 'stderr'):
        setattr(sys, attr, getattr(sys, '__%s__' % attr))

    return pdb.set_trace()

Y para usarlo, en mi código añado:

            import gpdb; gpdb.set_trace()

TODOs:

• L&F, ponerle el css adecuado
• Corregir los últimos cambios de app_bij.py que ha hecho David
• Uno, dos o tres pasos?
• Añadir todas las funcionalidades extras: Recuperar el sorteo, ver con quien juegas, comentar lo que quieres que te regalen…
• Añadir AdSense (y forrarme)
• …
• Y cuando todo vaya bien, mover el DNS para que www.amigoinvisibleonline.com apunte a la nube

PD. Tengo un límite de 2000 emails por día. Esto puede ser un problema, estas navidades estuve enviando más de 4000 al día, tendré que preguntar precios.

• Te bajas el GAE SDK y te lo instalas
• Te bajas Django, si no lo tuvieras y quieres usar una versión moderna (>0.96)
• Crea tu proyecto django, donde quieras: django-admin.py startproject xxx
• Modifica el settings.py quitar todas las referencias a la BBDD, sessions, auth y admin. Ver esta nota
• Copiar django framework y todo su contenido en la raiz del proyecto
• Añade un fichero app.yaml, descriptor del proyecto, que contenga:

application: aio
version: 1
runtime: python
api_version: 1
handlers:
- url: /static
static_dir: site_media
- url: /.*
  script: main.py

• Crea un fichero main.py, conteniendo lo siguiente:

import logging, os, sys

# Google App Engine imports.
from google.appengine.ext.webapp import util

# Remove the standard version of Django.
for k in [k for k in sys.modules if k.startswith('django')]:
  del sys.modules[k]

# Force sys.path to have our own directory first, in case we want to import
# from it.
sys.path.insert(0, os.path.abspath(os.path.dirname(__file__)))

# Django imports and other code go here...
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
import django.core.handlers.wsgi

def main():
  # Run Django via WSGI.
  application = django.core.handlers.wsgi.WSGIHandler()
  util.run_wsgi_app(application)

if __name__ == '__main__':
  main()

• Crea los modelos usando los Types y Properties delGAE
• Si vas a usar ModelForms también. Recuerda que los forms normales y los formset son los de django.
• Para hacer las queries, usa estos comandos.
• Para ejecutar el proyecto: ./dev_appserver.py <projecto>
• Para acceder al admin, y a una consola interactiva, puedes verlo desde aquí: http://localhost:8080/_ah/admin
• Todo lo demás funciona igual. Eso sí, ojo con la librería contrib.auth, que tampoco existe, se usan cuentas de google.
• Por supuesto, la mayoría de pluggables fallarán, porque hay que migrar a los nuevos modelos…

Tengo el amigo invisible más o menos listo, tengo que probar el envío de mails, y luego lo subiré a los servidores de Google. A ver si mañana lo termino.

Las diferencias con django se producen en la parte de BBDD, ya que se sustituyen los models de django por el sistema de Google. La definición es sencilla, pero los métodos para hacer queries dejan mucho que desear. Y las exceptions lanzadas también son diferentes.

Ojo también con los forms. Los ModelForms se extienden de un paquete de GAE, mientras que los forms normales son los de Django.

Por último, es posible y fácil utilizar Django en su versión actual. Simplemente hay que definir un archivo main.py (y declararlo en el app.yaml), con el siguiente contenido:

import logging, os, sys

# Google App Engine imports.
from google.appengine.ext.webapp import util

# Remove the standard version of Django.
for k in [k for k in sys.modules if k.startswith('django')]:
  del sys.modules[k]

# Force sys.path to have our own directory first, in case we want to import
# from it.
sys.path.insert(0, os.path.abspath(os.path.dirname(__file__)))

# Django imports and other code go here...
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
import django.core.handlers.wsgi

def main():
  # Run Django via WSGI.
  application = django.core.handlers.wsgi.WSGIHandler()
  util.run_wsgi_app(application)

if __name__ == '__main__':
  main()

Con el Admin cada editor tiene los permisos de acceso a lo que le corresponde, tienen filtros y búsquedas a su medida, formularios muy fáciles de rellenar (hasta campos autotext!), histórico de modificaciones… Es una plataforma que con muy poco esfuerzo nos ha ofrecido una solución potentísima, que un desarrollo a medida no lo habría hecho mejor (y a que coste…)

Pues bien, el otro día James Bennett proponía un par de trucos interesantes para hackear aún más el admin. Yo completo ese tutorial con otro truco interesante. Cómo mostrar un formulario para el alta y otro para la modificación de un mismo modelo. Este caso puede ser interesante para simplificar el alta de un objeto, pero mantener el control completo en caso de la modificación.

Simplemente hay que sobreescribir los métodos add_view() y change_view() del ModelAdmin. Siguiendo con el ejemplo propuesto por Bennett, si queremos que en el alta solo tuviéramos que entrar title, slug y body, y en la modificación quisieramos ocultar el slug (para evitar que se modifique la url) y la fecha podríamos hacer esto:

class EntryAdmin(admin.ModelAdmin):
    ...
    def add_view(self, *args, **kwargs):
        self.fields = ('title','slug','body')
        return super(EntryAdmin, self).add_view(*args, **kwargs)

    def change_view(self, *args, **kwargs):
        self.fields = ('title','body','subject','author')
        return super(EntryAdmin, self).change_view(*args, **kwargs)

Por supuesto, podemos ser aún más vagos y sobreescribir solo uno de los métodos, y dejar que el otro coja los parámetros por defecto:

class EntryAdmin(admin.ModelAdmin):
    ...
    fields = ('title','body','subject','author')

    def add_view(self, *args, **kwargs):
        self.fields = ('title','slug','body')
        return super(EntryAdmin, self).add_view(*args, **kwargs)

Esto también funcionaría

Funciona cuando quieres filtrar un campo genérico (un numérico, un string…) y este campo es nullable. Si no tuvieras este filtro te aparecen todos los valores posibles (completamente inutil en este tipo de campo). Si el campo no es nullable, este filtro no se activa.

El filtro hay que aplicarlo como parche sobre un fichero de django.

Festuc y dooplan tienen mucho en común, además de que ambas plataformas serán Django, compartiremos un mismo objetivo, convertirnos en referencia del ocio. Sin embargo el enfoque es ligeramente diferente. Mientras ellos van a por un target de twenty something, fiesteros, aves nocturnas…, nosotros desde dooplan intentaremos posicionarnos en un rango de edad superior y con una oferta de ocio más variada. No queremos centrarnos en fiestas exclusivamente, queremos también llegar a esos que disfrutan con una buena exposición, una conferencia, una feria, con sus hijos, con su pareja… Un público diferente.