Newforms ya es forms en Django
Posted July 20, 2008 
Comments(0)
Comments(0) Unida la rama de newforms con forms en django, en septiembre version 1.0.
Si queréis probarlos este screencast os ayudara.
Archive for the 'django' Category
Version 1.0 de Django, para Septiembre
Posted June 12, 2008 Comments(0)
Comments(0) Muy rápido, Django 1.0 roadmap and timeline
Tickets ineludibles
- ‘newforms-admin’ esta casi terminado, ya hemos empezado a hablar de unificar el trunk, para su publicacion en la versión 1.0
- Eliminar completamente ‘oldforms’.
- Hacer Django 100% WSGI compatible.
Liberando la versión 1.0 para el 2 de septiembre del 2008. guauuuuu,
Ale a seguir desarrollando con nuestro framework favorito y vemos que tiene seguimiento y no para de crecer…
Django avanza imparable, recibe soporte en Google App Engine
Posted April 8, 2008 Comments(3)
Comments(3) Pues si, revisando mis rss, me encuentro con el post de Joe Heck sobre Django and the google App Engine.
Empieza a medio entender lo que esta diciendo y empiezo a alucinar, resulta que google ha lanzado un nuevo servicio llamado App Engine (no se si hace mucho hace poco), en el cual te permite ejecutar tus aplicaciones en la infrastuctura de google.
Esto ya de por si es bastante bueno, pero cuando he empezado a leer un poco mas en la documentacion, un vistazo rápido. En la sección de Articulos, me encuentro con ejecuta Django en App Engine, leñe!!!!.
Haze poco que he comenzado con Django, pero esto para mi demuestra una apuesta clara y publica sobre un framework web, esto solo va a ser más que beneficioso, cuantos mas seamos mas nos reiremos y mas ayuda encontraremos.
Que google en sus faq recomiende claramente a django es alucinante.
Lo mismo que le ha pasado Joe, rápidamente e intentado apuntarme a ver si colaba y no ha habido suerte, solo toca esperar e ir leyendo la documentación para valorar posibles cambios de infraestructura en el proyecto que esto haciendo.
Tengo la duda sobre las limitaciones del servicio lo estoy repasando todavia, a ver que encuentro, ¿alguien sabe algo sobre esto?.
Lo comentan tambien, Erro500 y highscalability
Modelo de datos de Django - I
Posted March 17, 2008 Comments(1)
Comments(1) Otra de mis traducciones libres ;-)
Fuente: http://www.djangoproject.com/documentation/model-api/
Modelo de datos
El modelo es único, es el código definitivo de los datos sobre tu información. Contiene los campos esenciales y los comportamientos de la información que almacenas. Generalmente cada modelo mapea a una uncia tabla de base de datos.
Básicamente
Cada modelo es una clase python que es una subclase de django.db.models.Model. Cada atributo del modelo representa un campo de la Base de Datos. El Metadata del modelo (información sin campo) se incluye en una clase interna llamada Meta. El Metadata usado por el site de Administración de Django se incluye en una clase interna llamada Admin. Con todo esto, Django proporciona una API de Acceso a Base de datos generado de manera automática, esto esta explicado en la Database API reference
Un documento adjunto a este es el repositorio oficial de ejemplos de modelo de datos. En el código fuente de Django estos ejemplos se encuentran en el directorio test/modeltest.
Ejemplo rápido.
En este ejemplo se hace el modelo de Persona, con los atributos first_name y last_name:
PYTHON:
-
from django.db import models
-
-
class Person(models.Model):
-
first_name = models.CharField(max_length=30)
-
last_name = models.CharField(max_length=30)
first_name y last_name son campos del modelo. Cada campo esta especificado como un atributo de clase y cada atributo mapea una columna de la base de datos.
El anterior modelo de Person la orden de create table sera asi:
PYTHON:
-
CREATE TABLE myapp_person (
-
"id" serial NOT NULL PRIMARY KEY,
-
"first_name" varchar(30) NOT NULL,
-
"last_name" varchar(30) NOT NULL
-
);
Algunas notas tecnicas:
- El nombre de la tabla, myapp_person, deriva automaticamente del metadata puede ser sobreescrito, mirar Table names a continuación.
- El campo "id" es añadido automaticamente, pero este comportamiento puede ser sobreescrito, mirar Automatic primary key fields a continuación.
- La sentencia SQL CREATE TABLE en este ejemplo esta formateada usando PostgreSql syntax, pero es digno de mención decir que Django usa Sqls Adaptados a la Base de datos especificada en tu fichero de configuración.
Campos
La parte más importante del modelo, y la única parte requerida por el modelo es la lista de campos definida. Los campos son especificados como atributos de clase.
Ejemplo:
PYTHON:
-
class Musician(models.Model):
-
first_name = models.CharField(max_length=50)
-
last_name = models.CharField(max_length=50)
-
instrument = models.CharField(max_length=100)
-
-
class Album(models.Model):
-
artist = models.ForeignKey(Musician)
-
name = models.CharField(max_length=100)
-
release_date = models.DateField()
-
num_stars = models.IntegerField()
Restricciones de nombre.
Django solo tiene dos restricciones en el nombre de los campos del modelo:
-
- Un campo no se puede llamar como una palabra reservada de Python, porque daria un resultado de Syntax Error Python :
PYTHON:
-
class Example(models.Model):
-
pass = models.IntegerField() # 'pass' is a reserved word!
-
- Un campo no puede contener mas de un guion bajo por linea, Debido a la forma de trabajar Django con la sintaxis de las querys.
PYTHON:
-
class Example(models.Model):
-
foo__bar = models.IntegerField() # 'foo__bar' has two underscores!
-
Estas son las limitaciones para trabajar, tenga en cuenta también que los nombres de los campos no tienen que coincidir necesariamente con el nombre de la columna de la base de datos.
Mirar db_column a continuación.
Tipos de Campo
Cada campo el modelo debe ser una instancia apropiada de un atributo de una clase, Django utiliza los tipos de atributo de clase para determinar unas pocas cosas:
- El tipo de la columna de la BD (INTEGER, VARCHAR)
- El tipo de objeto a usar en la interface de administración de django ("Text",
- Las validaciones requeridas mínimas, usando la Admin de django y los manipuladores.
Todos los tipos disponibles de campos
BooleanField
Un campo de verdadero/falso, en la admin se representa como un checkbox
CharField
Un campo de texto para pequeñas cadenas, para mas grandes usar TextField. En la admin se representa como un "Text". Este campo tiene un requerimiento extra como argumento, max_length, longitud máxima en caracteres del campo, el atributo max_length se aplica en la BBDD y como validación en django.
CommaSeparatedIntegerField
Un integer separado por comas como el CharField el argumento max_length es requerido.
DateField
Un campo de Fecha, tiene algunos argumentos extra opcionales
auto_now automáticamente se da el valor del momento en el que el objeto es grabado, muy util para valores como "ultima modificación", siempre se utilizara la (current date) fecha actual, no es valor que puedas sobreescribir
auto_now_add automáticamente se da el valor del momento en el que el objeto se Crea, muy útil para valores como "creado el" siempre se utilizara la (current date) fecha actual, no es valor que puedas sobreescribir.
En el Admin esto se representa como un "text" con un calendario en Javascript, y un link a "Today", El Calendario empieza en Domingo.
DateTimeField
Un campo de Hora y Fecha, tiene las mismas opciones extra que el campo DateTime, en el Admin se representa con 2 campos "text", con links en Javascript.
DecimalField
Nuevo en la versión de desarrollo
Un numero decimal de precisión fija, representado en Python con una instancia de Decimal, Tiene 2 argumentos requeridos:
max_digits El numero máximo de dígitos permitido en el numero.
decimal_places El numero de posiciones decimales que tendrá el numero.
Por ejemplo, para almacenar numeros superiores a 999 con 2 posiciones decimales tu usarías:
models.DecimalField(..., max_digits=5, decimal_places=2)
Y para números superiores aproximadamente a un billón con 10 decimales:
models.DecimalField(..., max_digits=19, decimal_places=10)
El admin lo representa con un "Text" (en una entrada de una unica linea).
EmailField
Un campo CharField que chequea que el valor sea una dirección de email valida.
En la versión 0.96 no acepta max_length, automáticamente sera de 75, en la versión en desarrollo, viene por defecto a 75 pero se puede sobrescribir este comportamiento.
FileField
Un campo para subir ficheros, tiene un argumento requerido
upload_to Una ruta del sistema local que puedes añadir a la propiedad MEDIA_ROOT para determinar la salida de la función de ayuda get_
El admin es representado con un "file",
Podemos usar el FileField o ImageField en pocos pasos:
- En tu fichero de configuración, necesitar definir en MEDIA_ROOT el path completo al directorio donde quieres almacenar los ficheros subidos (Por rendimiento, estos ficheros no estan almacenados en la BD). Definir MEDIA_URL como una URL publica del directorio. Asegurarnos que en este directorio tiene permisos de escritura la cuenta de usuario del web server
- Añadir FileField o ImageField a tu modelo, asegurandonos que tenemos definida la opcion upload_to apuntando al subdirectorio MEDIA_ROOT donde se deben subir los ficheros.
- Todo sera almacenado en la BD como path del fichero (relativo al MEDIA_ROOT), puede utilizar la funcion del framework get_
_url . Por ejemplo, si tienes un ImageField llamado mug_shot, puedes acceder a la URL absoluta de tu imagen en la template con {{ object.get_mug_shot_url }}.
Continuara...