Web de Hormicasa en Alemán

Enlaces relacionados

• Web Corporativa de Hormicasa Servicios Inmobiliarios
• Blog de Hormicasa
• Hormicasa y C2 Gestión Inmobiliaria se publicitan mediante Mediasand

La Escuela de Turismo de Lanzarote se une a la lista de empresas y organismos que confían en DELL y en Cibernatural, su socio en Lanzarote – Islas Canarias.

Puede ver más detalles de los ordenadores de sobremesa DELL Optiplex 380 mediante la Galería de Imágenes del DELL Optiplex 380 DT

Con ella, se puede gestionar una empresa fácilmente en cualquier momento, lugar y desde cualquier dispositivo que disponga de un navegador e Internet (ordenador, portátil, teléfono móvil, etc.), sin necesidad de ninguna instalación, etc.

La aplicación permite la búsqueda y edición de cualquier cliente, factura, presupuesto, etc., de forma rápida y sencilla, así como la generación en PDF de cualquiera de estos elementos personalizados para la empresa usuaria de la aplicación. Además, permite realizar varias tareas con un solo click, como volcar un presupuesto en una factura, etc., y proporciona multitud de listados estadísticos en PDF como por ejemplo, resúmenes de facturación por meses, por trimestres, por años, por clientes, etc.

Algunas empresas como La Sillita de Canarias ya están utilizando esta aplicación, que pretende simplificar la facturación de la empresa y llevarla a la “nube” para gestionar su empresa cuándo y donde quiera.

Los formularios HTML son la columna vertebral de sitios Web interactivos. Este capítulo comprende cómo se puede utilizar Django para acceder a los datos de formulario emitidos por el usuario, validarlos, y hacer algo con ellos. En el camino, cubriremos los objetos HttpRequest y Form.

Obtener datos del objeto Request

Los objetos HttpRequest, tienen una serie de atributos y de métodos que son interesantes y debería familiarizarse con ellos para saber lo que es posible hacer con ellos.

Puede usar estos atributos para obtener información acerca de la petición actual (por ejemplo el usuario / navegador web que está cargando la página actual en su sitio Django) en el momento en que se ejecuta la la función de la vista.

Información sobre la URL

Los objetos HttpRequest contienen varias piezas de información sobre la URL solicitada actualmente:

Usar siempre los atributos / métodos en lugar de codificar las direcciones URL en sus vista. Esto hace que el código sea más flexible y que pueda ser reutilizado en otros lugares. He aquí un simple ejemplo:

# BAD!
def current_url_view_bad(request):

return HttpResponse(“Welcome to the page at /current/”)

# GOOD
def current_url_view_good(request):

return HttpResponse(“Welcome to the page at %s” % request.path)

Otra información sobre la petición

request.META es un diccionario Python que contiene todas las cabeceras HTTP disponibles para la solicitud dada, incluyendo la dirección IP del usuario y el agente de usuario (generalmente el nombre y la versión del navegador Web).  Las siguientes son algunas claves comunes en este diccionario:

• HTTP_REFERER: La URL de referencia, si la hubiese.
• HTTP_USER_AGENT: La cadena de agente de usuario (si existe) del navegador del usuario. Esto se parecerá a algo como lo siguiente: “Mozilla 5.0 (X11; U; Linux i686) Gecko/20080829 Firefox/2.0.0.17″
• REMOTE_ADDR: La dirección IP del cliente.

Usted debe usar una cláusula try / except, o un método get() para manejar el caso de claves indefinidas, como en este ejemplo:

# BAD!
def ua_display_bad(request):

ua = request.META['HTTP_USER_AGENT'] # Might raise KeyError!
return HttpResponse(“Your browser is %s” % ua)

# GOOD (VERSION 1)
def ua_display_good1(request):

try:

ua = request.META['HTTP_USER_AGENT']

except KeyError:

ua = ‘unknown’

return HttpResponse(“Your browser is %s” % ua)

# GOOD (VERSION 2)
def ua_display_good2(request):

ua = request.META.get(‘HTTP_USER_AGENT’, ‘unknown’)
return HttpResponse(“Your browser is %s” % ua)

Le animamos a escribir una pequeña vista que muestra todos los datos de request.META para que pueda conocer lo que está disponible. Se podría parecer a esto:

def display_meta(request):

values = request.META.items()
values.sort()
html = []
for k, v in values:

html.append(‘<tr><td>%s</td><td>%s</td></tr>’ % (k, v))

return HttpResponse(‘<table>%s</table>’ % ‘\n’.join(html))

Información sobre datos emitidos

Más allá de los metadatos básicos acerca de la solicitud, los objetos HttpRequest tienen dos atributos que contienen la información que envía el usuario: request.GET y request.POST. Ambas son objetos como diccionarios que le dan acceso a los datos GET y POST.

Los datos POST generalmente son emitidos desde un formulario HTML, mientras que los datos GET pueden provenir de un formulario o del querystring de la URL de la página.

Un ejemplo simple de gestión de formulario

Creemos una vista simple que permita a los usuarios buscar en nuestra base de datos de libros por el título.

En general, hay dos partes para el desarrollo de un formulario: la interfaz de usuario HTML y el código de la vista que procesa los datos presentados. La primera parte es fácil, vamos a crear una vista que muestre un formulario de búsqueda:

from django.shortcuts import render_to_response

def search_form(request):

return render_to_response(‘search_form.html’)

Esta vista puede residir en cualquier parte de su ruta de acceso Python. Para este ejemplo, colocarla en books/views.py.

La plantilla de acompañamiento, search_form.html, podría tener este aspecto:

<html>
<head>

<title>Search</title>

</head>
<body>

<form action=”/search/” method=”get”>

<input type=”text” name=”q”>
<input type=”submit” value=”Search”>

</form>

</body>
</html>

El patrón URL en urls.py podría ser algo como esto:

urlpatterns = patterns(”,

# …
(r’^search-form/$’, views.search_form),
# …

)

Ahora, si ejecuta el runserver y visita http://127.0.0.1:8000/search-form/, verá la interfaz de búsqueda. Bastante simple.

Intente emitir el formulario, sin embargo, y obtendrá un error 404 de Django. El formulario apunta a la URL /search/, que aún no ha sido implementada. Vamos a arreglar eso con una segunda función de vista:

# urls.py
urlpatterns = patterns(”,

# …
(r’^search-form/$’, views.search_form),
(r’^search/$’, views.search),
# …

)

# views.py
def search(request):

if ‘q’ in request.GET:

message = ‘You searched for: %r’ % request.GET['q']

else:

message = ‘You submitted an empty form.’

return HttpResponse(message)

Por el momento, esto sólo muestra el término de búsqueda del usuario de modo que pueda asegurarse que los datos se presentan a Django correctamente y para que pueda tener una idea de cómo los términos de la búsqueda fluyen a través del sistema. En resumen, esto es lo que sucede:

1. El formulario HTML define una variable q. Cuando se emite, el valor de q se envía a través de GET (method = “get”) a la URL /search/.
2. La vista Django que se encarga de la dirección /search/ tiene acceso al valor de q en request.GET.

Tenga en cuenta que comprobamos explícitamente que ‘q’ existe en request.GET. Como hemos señalado, usted no debe confiar en nada presentado por los usuarios. Si no ha añadido esta verificación, cualquier emisión de un formulario vacío lanzaría KeyError en la vista:

# BAD!
def bad_search(request):

# The following line will raise KeyError if ‘q’ hasn’t
# been submitted!
message = ‘You searched for: %r’ % request.GET['q']
return HttpResponse(message)

Los datos POST funcionan de la misma manera que los datos GET. ¿Cuál es la diferencia entre GET y POST?  Utilice GET cuando el acto de emitir el formulario es sólo una solicitud para “obtener” datos. Utilice POST siempre que el acto de emitir el formulario tenga algunos efectos secundarios de actualización de datos o enviar un e-mail, o algo más de la simple exhibición de los datos.  En nuestro ejemplo de búsqueda de libro, estamos utilizando GET porque la consulta no cambia ningún dato en nuestro servidor. Ahora que hemos verificado que request.GET se está pasando correctamente, vamos a conectar la consulta de búsqueda del usuario con nuestra base de datos de libros (de nuevo, en views.py):

from django.http import HttpResponse
from django.shortcuts import render_to_response
from mysite.books.models import Book

def search(request):

if ‘q’ in request.GET and request.GET['q']:

q = request.GET['q']
books = Book.objects.filter(title__icontains=q)
return render_to_response(‘search_results.html’, {‘books’: books, ‘query’: q})

else:

return HttpResponse(‘Please submit a search term.’)

El código de la plantilla search_results.html podría ser algo como esto:

<p>You searched for: <strong>{{ query }}</strong></p>

{% if books %}

<p>Found {{ books|length }} book{{ books|pluralize }}.</p>
<ul>

{% for book in books %}
<li>{{ book.title }}</li>
{% endfor %}

</ul>

{% else %}

<p>No books matched your search criteria.</p>

{% endif %}

Mejorar nuestro ejemplo de gestión de formulario simple

En primer lugar, nuestra gestión de la vista search() de una consulta vacía es pobre – estamos mostrando solo un mensaje “Por favor, envíe un término de búsqueda”, que requiere que el usuario pulse el botón Atrás del navegador. Esto es horrible y poco profesional.

Sería mucho mejor volver a mostrar el formulario, con un error sobre él, de modo que el usuario pueda volver a intentarlo inmediatamente. La forma más sencilla de hacerlo sería la de renderizar la plantilla de nuevo, de esta forma:

from django.http import HttpResponse
from django.shortcuts import render_to_response
from mysite.books.models import Book

def search_form(request):

return render_to_response(‘search_form.html’)

def search(request):

if ‘q’ in request.GET and request.GET['q']:

q = request.GET['q']
books = Book.objects.filter(title__icontains=q)
return render_to_response(‘search_results.html’, {‘books’: books, ‘query’: q})

else:

return render_to_response(‘search_form.html’, {‘error’: True})

Hemos mejorado search() renderizando la plantilla search_form.html de nuevo, si la consulta está vacía. Y ya que tenemos que mostrar un mensaje de error en esa plantilla, pasamos una variable de plantilla. Ahora podemos editar search_form.html para comprobar la variable de error:

<html>
<head>

<title>Search</title>

</head>
<body>

{% if error %}
<p style=”color: red;”>Please submit a search term.</p>
{% endif %}
<form action=”/search/” method=”get”>

<input type=”text” name=”q”>
<input type=”submit” value=”Search”>

</form>

</body>
</html>

Todavía podemos utilizar esta plantilla desde nuestra vista original, search_form(), ya que search_form() no pasa el error a la plantilla – el mensaje de error no se mostrará en ese caso.

Con este cambio es una aplicación mejor, pero ahora surge la pregunta: ¿es una vista search_form() dedicada realmente necesaria? Tal como está, una solicitud a la dirección URL /search/ (sin los parámetros GET) mostrará el formulario vacío (pero con un error). Podemos eliminar la vista search_form(), junto con su patrón URL asociado, siempre y cuando cambiemos search() para ocultar el mensaje de error cuando alguien visite /search/ sin parámetros GET:

def search(request):

error = False
if ‘q’ in request.GET:

q = request.GET['q']
if not q:

error = True

else:

books = Book.objects.filter(title__icontains=q)
return render_to_response(‘search_results.html’, {‘books’: books, ‘query’: q})

return render_to_response(‘search_form.html’, {‘error’: error})

En esta vista actualizada, si un usuario visita /search/ sin parámetros GET, verá el formulario de búsqueda sin mensaje de error. Si un usuario envía el formulario con un valor vacío para ‘q’, verá el formulario de búsqueda con un mensaje de error. Y, por último, si un usuario envía el formulario con un valor no vacío de ‘q’, verá los resultados de búsqueda.

Podemos hacer una mejora final a esta aplicación, para quitar un poco de redundancia. Ahora que hemos mezclado las dos vistas y URLs en una sola y /search/ maneja tanto la pantalla del formulario de búsqueda como la del resultado, el formulario HTML en search_form.html no tiene que codificar una URL a pelo. En lugar de esto:

puede cambiarse a:

El action = “” significa “Enviar el formulario a la misma URL que la página actual.” Con este cambio, usted no tendrá que acordarse de cambiar la acción, incluso si alguna vez la vista search() apunta a otra URL.

Validación simple

Nuestro ejemplo de búsqueda es todavía bastante simple, especialmente en términos de validación de sus datos, hacemos una mera comprobación para asegurar que la consulta de búsqueda no está vacía. Muchos de los formularios HTML incluyen un nivel de validación que es más complejo que asegurar que el valor no está vacío. Todos hemos visto la siguientes mensajes de error en los sitios Web:
“Por favor introduzca una dirección de correo electrónico”.
“Por favor, introduzca un código postal de cinco dígitos válido EE.UU.”
“Por favor, introduzca una fecha válida con formato AAAA-MM-DD”.
“Por favor, introduzca una contraseña que sea por lo menos de 8 caracteres de longitud y contenga al menos un número”.

Vamos a afinar la vista search() para validar que el término de búsqueda sea menor o igual a 20 caracteres de largo. ¿Cómo podemos hacerlo? Lo más sencillo sería integrar la lógica directamente en la vista, así:

def search(request):

error = False
if ‘q’ in request.GET:

q = request.GET['q']
if not q:

error = True

elif len(q) > 20:

error = True

else:

books = Book.objects.filter(title__icontains=q)
return render_to_response(‘search_results.html’,{‘books’: books, ‘query’: q})

return render_to_response(‘search_form.html’, {‘error’: error})

Ahora bien, si se intenta emitir una consulta de búsqueda mayor de 20 caracteres de largo, obtendrá un mensaje de error. Pero ese mensaje de error en search_form.html actualmente dice: “Por favor, introduzca un término de búsqueda.”, así que tendremos que cambiarlo para ser exactos en ambos casos (una búsqueda vacía o un término de búsqueda demasiado largo).

<html>
<head>

<title>Search</title>
</head>
<body>

{% if error %}
<p style=”color: red;”>

Please submit a search term
20 characters or shorter.

</p>
{% endif %}
<form action=”/search/” method=”get”>

<input type=”text” name=”q”>
<input type=”submit” value=”Search”>

</form>

</body>
</html>

Hay algo mal en esto. Nuestro único mensaje de error es potencialmente confuso. ¿Por qué el mensaje de error para un valor vacío menciona nada sobre un límite de 20 caracteres? Los mensajes de error deben ser específicos y claros.

El problema es que estamos utilizando un solo valor boolean para el error, cuando habría que utilizar una lista de cadenas de mensajes de error. He aquí cómo podemos solucionarlo:

def search(request):

errors = []
if ‘q’ in request.GET:

q = request.GET['q']
if not q:

errors.append(‘Enter a search term.’)

elif len(q) > 20:

errors.append(‘Please enter at most 20 characters.’)

else:

books = Book.objects.filter(title__icontains=q)
return render_to_response(‘search_results.html’, {‘books’: books, ‘query’: q})

return render_to_response(‘search_form.html’, {‘errors’: errors})

Entonces tenemos que hacer un pequeño ajuste en la plantilla search_form.html para reflejar que se pasó una lista de errores, en lugar de un error boolean:

<html>
<head>

<title>Search</title>
</head>
<body>

{% if errors %}
<ul>

{% for error in errors %}

<li>{{ error }}</li>

{% endfor %}

</ul>
{% endif %}
<form action=”/search/” method=”get”>

<input type=”text” name=”q”>
<input type=”submit” value=”Search”>

</form>

</body>
</html>

Hacer un formulario de contacto

Aunque hemos reiterado en el ejemplo del formulario de búsqueda de libros varias veces y lo hemos mejorado, sigue siendo muy sencillo: basta con un solo campo, ‘q’. Al ser tan simple, ni siquiera usamos la librería de formularios de Django para tratar con él. Pero las formas más complejas requieren tratamientos más complejos, y ahora vamos a desarrollar algo más complejo: un formulario de contacto de la web que permite a los usuarios del sitio envíar comentarios, junto con un e-mail de retorno. Después que el formulario es emitido y los datos son validados, automáticamente le enviaremos un mensaje por correo electrónico al personal del sitio.

Empezaremos con nuestra plantilla, contact_form.html:

<html>
<head>

<title>Contact us</title>

</head>
<body>

<h1>Contact us</h1>
{% if errors %}
<ul>

{% for error in errors %}
<li>{{ error }}</li>
{% endfor %}

</ul>
{% endif %}

<form action=”/contact/” method=”post”>

<p>Subject: <input type=”text” name=”subject”></p>
<p>Your e-mail (optional): <input type=”text” name=”e-mail”></p>
<p>Message: <textarea name=”message” rows=”10″ cols=”50″></textarea></p>
<input type=”submit” value=”Submit”>

</form>

</body>
</html>

Hemos definido tres campos: el asunto, la dirección de correo electrónico y el mensaje. El segundo es opcional, pero los otros dos campos son obligatorios. Tenga en cuenta que estamos usando method = “post” aquí en lugar de method = “get” ya que este formulario de emisión tiene un efecto secundario – que envía un e-mail. Si seguimos el camino establecido por nuestra vista search() de la sección anterior, una versión de nuestra vista contact() podría tener este aspecto:

from django.core.mail import send_mail
from django.http import HttpResponseRedirect
from django.shortcuts import render_to_response

def contact(request):

errors = []
if request.method == ‘POST’:

if not request.POST.get(‘subject’, ”):

errors.append(‘Enter a subject.’)

if not request.POST.get(‘message’, ”):

errors.append(‘Enter a message.’)

if request.POST.get(‘e-mail’) and ‘@’ not in request.POST['e-mail']:

errors.append(‘Enter a valid e-mail address.’)

if not errors:

send_mail(request.POST['subject'], request.POST['message'],
request.POST.get(‘e-mail’, ‘noreply@example.com’),
['siteowner@example.com'],

)
return HttpResponseRedirect(‘/contact/thanks/’)

return render_to_response(‘contact_form.html’,{‘errors’: errors})

Varias cosas nuevas están sucediendo aquí:

• Comprobamos que request.method es ‘POST’. Esto será cierto sólo en el caso de una emisión del formulario, no será cierto si alguien está solamente viendo el formulario de contacto. Esto hace que sea una buena forma de aislar el caso de “pantalla del formulario” del caso de”transformación del formulario”.
• En lugar de request.GET, estamos usando request.POST para acceder a los datos del formulario emitido. Esto es necesario porque el código de contact_form.html usa method = “post”.
• Contamos con dos campos obligatorios, asunto y mensaje, así que tenemos que validar ambos. Notar que estamos utilizando request.POST.get() y proporcionando una cadena en blanco como el valor por defecto.
• Aunque el campo de correo electrónico no es obligatorio, debemos aún validarlo si es emitido. Nuestro algoritmo de validación aquí es frágil – estamos comprobando que la cadena contiene un carácter @. En el mundo real, necesitaríamos una validación más robusta.
• Estamos usando la función django.core.mail.send_mail para enviar un e-mail. Esta función tiene cuatro argumentos necesarios: el asunto del e-mail, el cuerpo del correo electrónico, la dirección del emisor, y una lista de direcciones de los destinatarios. send_mail está contenida en la clase de Django E-mailMessage, que proporciona características avanzadas tales como archivos adjuntos, emails multiplart, y el control total de los encabezados del correo electrónico.
• Después de enviar el e-mail, redirigimos a una página de “éxito” devolviendo un objeto HttpResponseRedirect. Usted siempre debe enviar una redirección para el éxito de las peticiones POST. Es una de las mejores prácticas del desarrollo web.

Esto vista funciona, pero las funciones de validación son enrevesadas. Imagine la tramitación de un formulario con una docena de campos, ¿de verdad quieres tener que escribir todas esas sentencias if?

Otro problema es volver a mostrar el formulario. En el caso de errores de validación, es mejor práctica volver a mostrar el formulario con los datos presentados anteriormente ya rellenados para que el usuario puede ver lo que hizo mal (y no tener que volver a introducir los datos en los campos que ha emitido correctamente). Nosotros manualmente podríamos pasar los datos POST de nuevo a la plantilla, pero habría que editar cada campo HTML para insertar el valor adecuado en el lugar adecuado:

# views.py
def contact(request):

errors = []
if request.method == ‘POST’:

if not request.POST.get(‘subject’, ”):

errors.append(‘Enter a subject.’)

if not request.POST.get(‘message’, ”):

errors.append(‘Enter a message.’)

if request.POST.get(‘e-mail’) and ‘@’ not in request.POST['e-mail']:

errors.append(‘Enter a valid e-mail address.’)

if not errors:

send_mail(
request.POST['subject'],
request.POST['message'],
request.POST.get(‘e-mail’, ‘noreply@example.com’),
['siteowner@example.com'],
)

return HttpResponseRedirect(‘/contact/thanks/’)

return render_to_response(‘contact_form.html’, {‘errors’: errors,’subject’: request.POST.get(‘subject’, ”),

‘message’: request.POST.get(‘message’, ”),’e-mail’: request.POST.get(‘e-mail’, ”),

})

# contact_form.html
<html>
<head>

<title>Contact us</title>

</head>
<body>

<h1>Contact us</h1>
{% if errors %}
<ul>

{% for error in errors %}
<li>{{ error }}</li>
{% endfor %}

</ul>
{% endif %}
<form action=”/contact/” method=”post”>

<p>Subject: <input type=”text” name=”subject” value=”{{ subject }}”></p>
<p>Your e-mail (optional):

<input type=”text” name=”e-mail” value=”{{ e-mail }}”>

</p>
<p>Message:

<textarea name=”message” rows=”10″ cols=”50″>
**{{ message }}**
</textarea>

</p>
<input type=”submit” value=”Submit”>

</form>

</body>
</html>

Se trata de una gran cantidad de código, e introduce un montón de posibilidades de error humano. Veremos alguna librería de alto nivel que gestione las tareas relacionadas con los formularios y la validación.

Su primera clase de formulario

Django viene con una librería de formularios, llamada django.forms, que se encarga de muchas de las cuestiones que hemos estado viendo en este capítulo – desde la muestra de formularios HTML a la validación. Volvamos a hacer nuestro formulario de contacto utilizando el marco de formularios de Django.

La principal manera de utilizar el marco de formularios es definir una clase Form por cada
HTML. En nuestro caso, sólo tenemos una
, así que tendremos una clase Form. Esta clase puede residir en cualquier lugar, incluyendo directamente en el archivo views.py, pero la convención es mantener las clases Form en un archivo llamado forms.py. Cree este archivo en el mismo directorio que el views.py, y escriba lo siguiente:

from django import forms

class ContactForm(forms.Form):

subject = forms.CharField()
e-mail = forms.EmailField(required=False)
message = forms.CharField()

Esto es bastante intuitivo, y es similar a la sintaxis de modelo de Django. Cada campo en el formulario está representado por un tipo de clase Field – Charfield y EmailField son los únicos tipos Field utilizados aquí – como atributos de una clase Form. Cada campo es obligatorio por defecto, así que para hacer e-mail opcional, especificamos required = False.

Vayamos al intérprete interactivo de Python y veamos lo que esta clase puede hacer. Lo primero que puede hacer es mostrarse como HTML:

<<< from contact.forms import ContactForm
<<< f = ContactForm()
<<< print f
<tr><th><label for=”id_subject”>Subject:</label></th><td>
<input type=”text” name=”subject” id=”id_subject” /></td></tr>
<tr><th><label for=”id_e-mail”>E-mail:</label></th><td>
<input type=”text” name=”e-mail” id=”id_e-mail” /></td></tr>
<tr><th><label for=”id_message”>Message:</label></th><td>
<input type=”text” name=”message” id=”id_message” /></td></tr>

Django añade una etiqueta a cada campo, junto con las etiquetas para accesibilidad. La idea es hacer que el comportamiento por defecto sea tan satisfactorio como sea posible.

Esta es la salida por defecto en el formato de un <table> HTML, pero hay otras salidas preconstruidas:

<<< print f.as_ul()
<li><label for=”id_subject”>Subject:</label>
<input type=”text” name=”subject” id=”id_subject” /></li>
<li><label for=”id_e-mail”>E-mail:</label>
<input type=”text” name=”e-mail” id=”id_e-mail” /></li>
<li><label for=”id_message”>Message:</label>
<input type=”text” name=”message” id=”id_message” /></li>

<<< print f.as_p()
&ltp>&ltlabel for=”id_subject”>Subject:&lt/label>
&ltinput type=”text” name=”subject” id=”id_subject” />&lt/p>
&ltp>&ltlabel for=”id_e-mail”>E-mail:&lt/label>
&ltinput type=”text” name=”e-mail” id=”id_e-mail” />&lt/p>
&ltp>&ltlabel for=”id_message”>Message:&lt/label>
&ltinput type=”text” name=”message” id=”id_message” />&lt/p>

Tenga en cuenta que la etiquetas de apertura y cierre <table>, <ul>, y <form> no son incluidas en la salida, de forma que usted puede agregar las filas adicionales si es necesario.

Estos métodos son métodos abreviados para el caso común de “mostrar todo el formulario.” Usted también puede mostrar el código HTML de un campo particular:

<<< print f['subject']
<input type=”text” name=”subject” id=”id_subject” />
<<< print f['message']
<input type=”text” name=”message” id=”id_message” />

La segunda cosa que podemos hacer con los objetos Form es validar los datos. Para ello, crear un nuevo objeto Form y pasarle un diccionario de datos que asigne los nombres de campo a los datos:

<<< f = ContactForm({‘subject’: ‘Hello’, ‘e-mail’: ‘adrian@example.com’,
… ‘message’: ‘Nice site!’})

Una vez ha asociado los datos con una instancia Form, ha creado un Form bound (ligado):

<<< f.is_bound
True

Llame al método is_valid() de cualquier Form ligado para averiguar si sus datos son válidos. Hemos pasado un valor válido para cada campo, por lo que el formulario en su totalidad es válido:

<<< f.is_valid()
True

Si no se pasa el campo de correo electrónico, sigue siendo válido, porque hemos especificado required = False para ese campo:

<<< f = ContactForm({‘subject’: ‘Hello’, ‘message’: ‘Nice site!’})
<<< f.is_valid()
True

Pero si dejamos fuera el asunto o el mensaje, el formulario ya no es válido:

<<< f = ContactForm({‘subject’: ‘Hello’})
<<< f.is_valid()
False
<<< f = ContactForm({‘subject’: ‘Hello’, ‘message’: ”})
<<< f.is_valid()
False

Usted puede ver los detalles obteniendo mensajes de error específicos por campo:

<<< f = ContactForm({‘subject’: ‘Hello’, ‘message’: ”})
<<< f['message'].errors
[u'This field is required.']
<<< f['subject'].errors
[]
<<< f['e-mail'].errors
[]

Cada instancia Form ligada tiene un atributo errors que proporciona un diccionario que asigna nombres de campos a listas de mensajes de error:

<<< f = ContactForm({‘subject’: ‘Hello’, ‘message’: ”})
<<< f.errors
{‘message’: [u'This field is required.']}

Por último, para los casos de instancias de formulario cuyos datos se ha encontrado ser válidos, está disponible el atributo cleaned_data. Este es un diccionario de los datos emitidos, “limpiado”. El marco de formularios de Django, no sólo valida los datos, sino que los limpia para convertir de valores a los tipos de Python adecuados, como se muestra aquí:

<<< f = ContactForm({‘subject’: ‘Hello’, ‘e-mail’: ‘adrian@example.com’,
… ‘message’: ‘Nice site!’})
<<< f.is_valid()
True
<<< f.cleaned_data
{‘message’: u’Nice site!’, ‘e-mail’: u’adrian@example.com’, ‘subject’: u’Hello’}

Nuestro formulario de contacto trata sólo con cadenas, que son “limpiadas” a objetos Unicode, pero si tuviéramos que utilizar un IntegerField o un DateField, el marco de formularios garantizaría que cleaned_data utiliza enteros Python adecuados u objetos datetime.date para los campos dados.

Vincular objetos Form en vistas

Ahora que tiene algunos conocimientos básicos sobre las clases Form, veremos cómo podemos utilizar esta infraestructura para sustituir algo en nuestra vista contact(). He aquí cómo podemos reescribir contacto() para utilizar el marco de formularios:

# views.py

from django.shortcuts import render_to_response
from mysite.contact.forms import ContactForm

def contact(request):

if request.method == ‘POST’:

form = ContactForm(request.POST)
if form.is_valid():

cd = form.cleaned_data
send_mail(

cd['subject'],
cd['message'],
cd.get(‘e-mail’, ‘noreply@example.com’),
['siteowner@example.com'],

)
return HttpResponseRedirect(‘/contact/thanks/’)

else:

form = ContactForm()
return render_to_response(‘contact_form.html’, {‘form’: form})

# contact_form.html

<html>
<head>

<title>Contact us</title>

</head>
<body>

<h1>Contact us</h1>
{% if form.errors %}

<p style=”color: red;”>

Please correct the error{{ form.errors|pluralize }} below.

</p>

{% endif %}
<form action=”" method=”post”>

<table>

{{ form.as_table }}

</table>
<input type=”submit” value=”Submit”>

</form>

</body>
</html>

El marco de formularios de Django gestiona la pantalla del HTML, la validación, la limpieza de los datos, y el volver a mostrar el formulario con errores.

Trate de ejecutar esto en local. Cargue el formulario, emítalo sin rellenar ningun campo, emítalo con una dirección inválida de correo electrónico, y finalmente emítalo con los datos válidos.

Cambiar como se renderizan los campos

Probablemente lo primero que notará cuando renderiza el formulario localmente es que el campo mensaje se muestra como un <input type=”text”>, y debería ser un <textarea>. Podemos arreglar esto mediante el establecimiento del widget del campo:

from django import forms

class ContactForm(forms.Form):

subject = forms.CharField()
e-mail = forms.EmailField(required=False)
message = forms.CharField(widget=forms.Textarea

El marco de formularios separa la lógica de presentación de cada campo en un conjunto de widgets. Cada tipo de campo tiene un widget por defecto, pero se puede reemplazar la configuración predeterminada o proporcionar un widget personalizado.

Piense en las clases Field como la representación de la lógica de validación, mientras que los widgets representan la lógica de presentación.

Establecer una longitud máxima

Una de las necesidades de validación más común es comprobar que un campo es de un tamaño determinado.Mejoremos nuestro formulario de contacto limitando el asunto a 100 caracteres. Para hacer eso, proporcionar un max_length al Charfield, de esta forma:

from django import forms

class ContactForm(forms.Form):

subject = forms.CharField(max_length=100)
e-mail = forms.EmailField(required=False)
message = forms.CharField(widget=forms.Textarea)

Un argumento opcional min_length también está disponible.

Establecer valores iniciales

Como una mejora a este formulario, vamos a añadir un valor inicial para el campo Asunto: “I love your site! “. Para hacer esto, podemos utilizar el argumento initial cuando creamos una instancia Form:

def contact(request):

if request.method == ‘POST’:

form = ContactForm(request.POST)
if form.is_valid():

cd = form.cleaned_data
send_mail(

cd['subject'],
cd['message'],
cd.get(‘e-mail’, ‘noreply@example.com’),
['siteowner@example.com'],

)
return HttpResponseRedirect(‘/contact/thanks/’)

else:

form = ContactForm(initial={‘subject’: ‘I love your site!’})
return render_to_response(‘contact_form.html’, {‘form’: form})

Tenga en cuenta que hay una diferencia entre pasar datos inicialmente y pasar datos que se ligan al formulario. Si sólo pasa los datos iniciales, el formulario será independiente, lo que significa que no tendrá ningún mensaje de error.

Añadir reglas de validación personalizadas

Decidimos adoptar una nueva política de validación: cuatro palabras o más, por favor.

Hay varias maneras de conectar la validación personalizada a un formulario Django. Si nuestra regla es algo que volverá a utilizar una y otra vez, podemos crear un tipo de campo personalizado. La mayoría de las validaciones personalizadas son asuntos de una sola vez, sin embargo, y puede vincularse directamente a la clase Form.

Queremos validación adicional en el campo del mensaje, por lo que añadimos un método clean_message() a nuestra clase Form:

from django import forms

class ContactForm(forms.Form):

subject = forms.CharField(max_length=100)
e-mail = forms.EmailField(required=False)
message = forms.CharField(widget=forms.Textarea)

def clean_message(self):

message = self.cleaned_data['message']
num_words = len(message.split())
if num_words < 4:

raise forms.ValidationError(“Not enough words!”)

return message

El sistema de formularios de Django busca automáticamente cualquier método cuyo nombre empieza con clean_ y termina con el nombre de un campo. Si existe alguno, se llama durante la validación.

En concreto, el método clean_message() será llamado después de la lógica de validación por defecto para un campo determinado (en este caso, la lógica de validación para un CharField obligatorio).Debido a que los datos del campo ya han sido parcialmente procesados, hay que sacarlos de self.cleaned_data. Además, no tiene que preocuparse de comprobar que el valor existe y no es vacío, el validador lo hace de forma predeterminada.

Nosotros, utilizamos una combinación de len() y split() para contar el número de palabras. Si el usuario ha introducido muy pocas palabras, lanzamos un forms.ValidationError. La cadena adjunta a la excepción se muestra al usuario como un elemento de la lista de errores.

Es importante que devolvamos explícitamente el valor limpiado para el campo al final del método. Esto nos permite modificar el valor (o convertirlo a un tipo diferente de Python) dentro de nuestro método de validación personalizado. Si olvidamos de la instrucción de retorno, entonces será devuelto None y el valor original se perderá.

Especificar etiquetas

Por defecto, las etiquetas del formulario HTML autogenerado por Django se crean mediante la sustitución de los guiones bajos por espacios y capitalizando la primera letra, por lo que la etiqueta para el campo e-mail es “E-mail”. ¿Suena familiar? Es el mismo algoritmo simple que los modelos Django utilizan para calcular los valores verbose_name de los campos por defecto.

Pero, como con los modelos Django, podemos personalizar la etiqueta de un campo determinado. Sólo tiene que utilizar la etiqueta, de este modo:

class ContactForm(forms.Form):

subject = forms.CharField(max_length=100)
e-mail = forms.EmailField(required=False, label=’Your e-mail address’)
message = forms.CharField(widget=forms.Textarea)

Personalizar el diseño de los formularios

Nuestra plantilla contact_form.html usa {{ form.as_table }} para mostrar el formulario, pero podemos visualizarlo de otras formas para conseguir un control más detallado sobre la pantalla.

La forma más rápida para personalizar la presentación de los formularios es con CSS. Las listas de error, en particular, podían realizarse con algunas mejoras visuales, y las listas de error autogeneradas usan <ul class = “errorlist”> precisamente para que se pueda apuntar a ellas con CSS. El siguiente CSS hace realmente que nuestros errores destaquen:

<style type=”text/css”>

ul.errorlist {

margin: 0;
padding: 0;

}

.errorlist li {

background-color: red;
color: white;
display: block;
font-size: 10px;
margin: 0 0 3px;
padding: 4px 5px;

}

</style>

Aunque es conveniente disponer de nuestro HTML de formulario generado para nosotros, en muchos casos, usted deseará reemplazar la representación por defecto.

Cada widget de campo (<input type=”text”>, <select>, <textarea>, etc) pueden ser renderizado individualmente mediante el acceso a {{ form.fieldname }} en la plantilla, y los errores asociados con un campo están disponibles como {{ form.fieldname.errors }}. Con esto en mente, podemos construir una plantilla personalizada para nuestro formulario de contacto con el siguiente código de plantilla:

<html>
<head>

<title>Contact us</title>

</head>
<body>

<h1>Contact us</h1>
{% if form.errors %}

<p style=”color: red;”>

Please correct the error{{ form.errors|pluralize }} below.

</p>

{% endif %}
<form action=”" method=”post”>

<div class=”field”>

{{ form.subject.errors }}
<label for=”id_subject”>Subject:</label>
{{ form.subject }}

</div>

<div class=”field”>

{{ form.e-mail.errors }}
<label for=”id_e-mail”>Your e-mail address:</label>
{{ form.e-mail }}

</div>

<div class=”field”>

{{ form.message.errors }}
<label for=”id_message”>Message:</label>
{{ form.message }}

</div>

<input type=”submit” value=”Submit”>

</form>

</body>
</html>

{{ form.message.errors }} muestra una <ul class=”errorlist”> si hay errores y una cadena en blanco si el campo es válido (o el formulario no está ligado). También puede tratar form.message.errors como un valor booleano o incluso iterar sobre él como una lista. Considere este ejemplo:

<div class=”field{% if form.message.errors %} errors{% endif %}”>

{% if form.message.errors %}

<ul>
{% for error in form.message.errors %}

<li><strong>{{ error }}</strong></li>

{% endfor %}
</ul>

{% endif %}

<label for=”id_message”>Message:</label>
{{ form.message }}

</div>

En el caso de errores de validación, esto añadirá una clase errors al <div> y muestra la lista de errores en una lista desordenada.

Enlaces Relacionados:

• Tutorial de Django I
• Tutorial de Django II
• Tutorial de Django III
• Tutorial de Django IV
• Tutorial de Django V
• Tutorial de Django VI

http://www.excavacionestiagua.com

En ella se pretende ir mostrando todos y cada uno de los productos y servicios que ofrece la empresa, entre los que destacan todo tipo de trabajos de Excavaciones, Movimiento de Tierras, Demoliciones, Cimentaciones, etc., así como de Transportes y Grúas para toda la isla de Lanzarote.

También, la página permite realizar comentarios de cada una de las noticias o novedades mostradas, con objeto de acercar al cliente o proveedor a la empresa, en cualquier momento y en cualquier lugar.

Dell lanza el nuevo Latitude™ E5410/E5510

Portátiles de altas prestaciones: consiga negocios de bajo coste

Los portátiles Dell™ Latitude™ E5510 y E5410 ponen en sus manos una fiable tecnología informática portátil caracterizada por una mayor flexibilidad y una probada durabilidad, además de una reducción del tiempo de implementación y las labores de mantenimiento.

Resistencia inigualable
Todos los portátiles Latitude de la gama E se someten a rigurosas pruebas de durabilidad, lo que garantiza una vida útil prolongada. Esto se consigue gracias a su dureza y sofisticación, sus sólidas bisagras, sus resistentes pestillos, sus compactas pantallas reforzadas y la protección de datos críticos gracias al amortiguador de golpes Dell StrikeZone™.

Fácil de usar
Revele a sus clientes cómo disparar la productividad gracias a las últimas opciones de conexión inalámbrica y una prolongada duración de la batería para poder colaborar prácticamente desde cualquier lugar. Gracias a los controles inteligentes, trabajar con estos sistemas resulta muy intuitivo; el teclado antimicrobiano, por su parte, reduce la proliferación de bacterias y hongos.

Organización sencilla
Simplifique la infraestructura de tecnología informática de sus clientes con características como la estabilidad de los productos de esta gama, su intercompatibilidad, la asistencia global y un control de nivel empresarial; con todo ello, ahorrarán dinero y tiempo al departamento informático.

Es hora de pasar a la acción
Póngase en marcha y empiece a sentar los sólidos cimientos de su negocio hoy mismo.

Dell lanza el nuevo Latitude™ E4310

Un sistema ligero, aunque cargado de funciones

Este modelo de clase empresarial, que se encuentra disponible con una selección de procesadores Intel Core i5, proporciona al cliente un fantástico conjunto de ventajosas características con las que trabajar de un modo inteligente, productivo y organizado.

Inteligencia
Si un ordenador está diseñado para utilizarse allí donde vaya el usuario, lo más sensato es fabricarlo para que cumpla totalmente dicho propósito. Por ello, al igual que con el resto de los portátiles Latitude de la gama E, se efectúan comprobaciones de la durabilidad del E4310 y se le somete a pruebas aceleradas de vida útil que emulan un uso realista del sistema. Un amortiguador de golpes Dell StrikeZone brinda una protección adicional a los datos del cliente en caso de caída del sistema (aun cuando el portátil esté apagado). Asimismo, una amplia gama de puertos y opciones de conexión posibilita múltiples formas de colaboración para poder trabajar sin que importe dónde.

Productividad
Con el E4310, los clientes pueden aprestarse a trabajar con suma rapidez (bien individualmente, bien con compañeros vinculados a una red de portátiles). Sus clientes disfrutarán de una duración de la batería más prolongada, procesadores con alta eficiencia energética y la tecnología Latitude ON™, que permite comprobar el correo electrónico, el calendario y los contactos sin necesidad de iniciar el sistema (el tipo de funciones que ayudarán a sus clientes a ser más productivos).

Organización
El nuevo Latitude E4310 puede contribuir a lograr una organización más eficiente de la infraestructura de tecnología informática de sus clientes haciendo hincapié en la estabilidad, la intercompatibilidad, la asistencia global y un control de nivel empresarial. Ahora, más que nunca, las organizaciones deben hacer frente a la necesidad de canalizar el dinero y el tiempo invertidos en tecnología informática hacia actividades productivas. El Latitude E4310 puede contribuir a este propósito reduciendo los gastos, el tiempo de implementación y las labores de mantenimiento.

Dell lanza el nuevo Latitude™ E2110

Una hermosa fusión de forma, funcionalidad y diversión

Funcionalidad inteligente
Aumente las oportunidades de aprendizaje en cualquier momento y lugar gracias a opciones integradas de banda ancha móvil. Incorpore una línea defensiva adicional frente a las bacterias con el teclado opcional a prueba de manipulaciones y con protección antimicrobiana.

Auténtica flexibilidad
Satisfaga las necesidades de sus estudiantes con opciones como una pantalla táctil de alta definición o una cámara web opcional. Ponga en sus manos la capacidad de elegir entre la opción de batería de formato ligero o con una duración de hasta 9 horas y 27 minutos.

Características básicas
El Dell Latitude 2110 constituye una asequible solución informática y de aprendizaje portátil que incorpora las características básicas de la gama Dell Latitude de orientación empresarial; gracias a ellas, los departamentos de tecnología informática logran ahorrar tiempo y dinero.

Cibernatural es nuevo proveedor de bonos tecnológicos del Gobierno de Canarias para la isla de Lanzarote en la modalidad TIC2 – Desarrollo en implantación de innovaciones.
Puede contactar con Cibernatural si quiere acogerse al programa con objeto de mejorar la infraestructura tecnológica de su empresa.

Información completa del programa de subvenciones

http://www.gobiernodecanarias.org/aciisi/bonos/

Para una cierta clase de sitios Web, una interfaz de administración es una parte esencial de la infraestructura. Se trata de una interfaz basada en Web, limitada a los administradores del sitio de confianza, que permite la adición, la edición, y la eliminación de contenido del sitio.

Los paquetes django.contrib

La administración automática de Django es parte de una gran suite de funcionalidad de Django llamada django.contrib – la parte de código de Django que contiene diversas utilidades para el núcleo. Usted puede pensar en django.contrib como el equivalente de Django de la librería estándar de Python. Está integrado con Django de modo que no tenemos que reinventar la rueda en nuestras propias aplicaciones.

El sitio de administración se llama django.contrib.admin. Otras características disponibles en django.contrib incluyen un sistema de autenticación de usuarios (django.contrib.auth), soporte para sesiones anónimas (django.contrib.sessions), e incluso un sistema de comentarios de usuarios (django.contrib.comments).

Activar la interfaz de administración

El sitio de administración de Django es totalmente opcional, ya que sólo ciertos tipos de sitios necesitan esta funcionalidad. Eso significa que usted tendrá que dar unos pasos para activarlo en su proyecto.

En primer lugar, hacer unos cuantos cambios a su archivo de configuración:

1. Añadir ‘django.contrib.admin’ a la propiedad INSTALLED_APPS.
2. Asegúrese de que INSTALLED_APPS contiene ‘django.contrib.auth’, ‘django.contrib.contenttypes’, y ‘django.contrib.sessions’. El sitio de administración de Django requiere de estos tres paquetes.
3. Asegúrese de que MIDDLEWARE_CLASSES contiene los valores ‘django.middleware.common.CommonMiddleware’,
   ‘django.contrib.sessions.middleware.SessionMiddleware’, y ‘django.contrib.auth.middleware.AuthenticationMiddleware.

En segundo lugar, ejecutar python manage.py syncdb. Este paso permitirá instalar las tablas extra de base de datos que utiliza el interfaz de administración. La primera vez que ejecute syncdb con ‘django.contrib.auth’ en INSTALLED_APPS, se le preguntará sobre la creación de un super-usuario. Si usted no hace esto, tendrá que para ejecutar python manage.py createsuperuser por separado para crear una cuenta de usuario administrador, de lo contrario usted no será capaz de entrar en el sitio de administración.

En tercer lugar, agregue el sitio de administración a su URLconf (en urls.py, recuerde). Por defecto, el urls.py generado por django-admin.py startproject contiene el código comentado para la administración de Django, y todo lo que tiene que hacer es quitar los comentarios.

# Include these import statements…
from django.contrib import admin
admin.autodiscover()

# And include this URLpattern…
urlpatterns = patterns(”,

# …
(r’^admin/’, include(admin.site.urls)),
# …

)

Con esa poca configuración, ahora usted puede ver el sitio de administración de Django en acción.  Simplemente ejecute el servidor de desarrollo (python manage.py runserver) y visite http://127.0.0.1:8000/admin/ en su navegador Web.

Usar el sitio de administración

Inicie sesión con el nombre de usuario y contraseña que agregó cuando creó el superusuario. Si usted no puede abrir una sesión, asegúrese de que ha creado realmente un super-usuario ejecutando python manage.py createsuperuser.

Una vez que esté conectado, lo primero que verá será la página de inicio de administración. Esta página muestra todos los tipos de datos disponibles que se pueden editar en el sitio de administración. En este punto, ya que no ha activado ninguno de nuestros modelos, la lista es escasa: sólo incluye Grupos y Usuarios, que son los dos modelos de administración por defecto editables.

Cada tipo de datos en el sitio de administración de Django tiene una lista de cambios y un formulario de edición. Las listas de cambios muestran todos los objetos disponibles en la base de datos, y los formularios de edición le permiten añadir, cambiar o eliminar registros particulares en su base de datos.

Haga clic en el vínculo Cambiar en la fila de los usuarios para cargar la página de lista de cambios de los usuarios. Esta página muestra todos los usuarios de la base de datos.

Pulse un nombre de usuario, y verá el formulario de edición de ese usuario. Esta página le permite cambiar los atributos del usuario.

Añadir modelos al sitio de administración

Vamos a añadir nuestros propios modelos a la página de administración a fin de que podemos agregar, modificar y eliminar objetos en nuestras tablas de bases de datos personalizadas utilizando esta interfaz agradable.

Vamos a seguir el ejemplo de los libros, donde definimos tres modelos: Publisher, Author, y Book.

En el directorio de libros (mysite/books), cree un archivo llamado admin.py, y escriba las siguientes líneas de código:

from django.contrib import admin
from mysite.books.models import Publisher, Author, Book

admin.site.register(Publisher)
admin.site.register(Author)
admin.site.register(Book)

Este código le indica al sitio de administración de Django que ofrezca una interfaz para cada uno de estos modelos.

Una vez que haya hecho esto, vaya a la página de inicio de administración en su explorador Web (http://127.0.0.1:8000/admin/). Usted debe ver una sección de Libros con enlaces a los autores, libros y editores. Tendrá que reiniciar runserver para que los cambios tengan efecto.

Un aspecto digno de mencionar aquí es el manejo de las claves ajenas y las relaciones muchos-a-muchos por el sitio de administración, las cuales aparecen en el modelo Book.

En la página Add Book del sitio de administración de Django (http://127.0.0.1:8000/admin/books/book/add/), el editor (una ForeignKey) es representado por una caja de selección, y el campo de los autores (un ManyToManyField) es representado por un cuadro de selección múltiple. Ambos campos están al lado de un signo más verde que te permite añadir los registros relacionados de ese tipo. Por ejemplo, si hace clic en el signo más verde junto al campo Publisher, obtendrá una ventana emergente que le permite añadir un editor.

Cómo trabaja el sitio de administración

Cuando Django carga su URLconf de urls.py al arrancar el servidor, se ejecuta la setencia admin.autodiscover() que añadimos como parte de la activación de la administración. Esta función itera sobre la configuración de INSTALLED_APPS y busca un archivo llamado admin.py en cada aplicación instalada. Si un admin.py existe en una aplicación dada, se ejecuta el código de ese fichero.

En el admin.py de nuestra aplicación books, cada llamada a admin.site.register() simplemente registra el modelo dado con la administración. El sitio de administración mostrará una interfaz de edición/modificación para cada modelo que se haya registrado de forma explícita.

La aplicación django.contrib.auth incluye su propio admin.py, por lo que usuarios y grupos se mostraron de forma automática en la administración.

El sitio de administración de Django es sólo una aplicación Django, con sus propios modelos, plantillas, vistas, y patrones URL. Usted puede examinar sus plantillas, vistas, y patrones URL hurgando en django / contrib / admin en su copia del código base de Django.

Hacer campos opcionales

Usted notará probablemente una limitación – los formularios de edición requieren que se rellenen todos los campos, mientras que en muchos casos le gustaría que determinados campos fuesen opcionales. Digamos, por ejemplo, que queremos que nuestro campo email del modelo Author sea opcional, es decir, que se permita una cadena en blanco. En el mundo real, usted no podría tener una dirección de correo electrónico en archivo para cada autor.

Para especificar que el campo de correo electrónico es opcional, modificar el modelo Author. Basta con añadir blank = True para el campo email, así:

class Author(models.Model):

first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=40)
email = models.EmailField(blank=True)

Al añadir blank = True, hemos comenzado la expansión de nuestro modelo más allá de una simple definición de la tabla de base de datos. Ahora, nuestra clase de modelo está empezando a convertirse en una rica colección de conocimiento sobre lo que los objetos Author son y qué pueden hacer. No sólo está el campo email representado por una columna VARCHAR en la base de datos, sino que es también un campo opcional en contextos como el sitio de administración de Django.

Hacer a fechas y campos numéricos opcionales

SQL tiene su propia forma de especificar los valores en blanco, un valor especial llamado NULL. NULL puede significar “desconocido” o “inválido”, o algún otro significado específico de la aplicación. En SQL, un valor de NULL es diferente de una cadena vacía, al igual que el objeto especial de Python None es diferente de la una cadena vacía (“”).

Esto puede causar confusión y ambigüedad no deseados: ¿Por qué este disco tiene un valor NULL, pero este otro tiene una cadena vacía? ¿Hay una diferencia, o se introdujeron los datos de manera distinta?. Y ¿Cómo puedo obtener todos los registros que tienen un valor en blanco, debería buscar tanto los registros NULL como las cadenas vacías, o debo elegir sólo los que tienen cadenas vacías?

Para evitar esa ambigüedad, Django genera automáticamente sentencias CREATE TABLE añadiendo un valor explícito NOT NULL a cada definición de columna.

En la mayoría de los casos, este comportamiento predeterminado es óptimo para su aplicación y le ahorrará dolores de cabeza por inconsistencia de los datos. Y funciona muy bien con el resto de Django, tales como el sitio de administración de Django, que inserta una cadena vacía (no un valor NULL) cuando se deja un campo de carácter en blanco.

Pero hay una excepción con los tipos de columna de base de datos que no aceptan cadenas vacías como valores válidos, tales como fechas, horas y números. Si intenta insertar una cadena vacía en una columna de fecha o número entero, lo más probable es obtener un error de base la de datos. En este caso, NULL es la única manera de especificar un valor vacío. En los modelos Django, usted puede especificar que se permite NULL añadiendo null = True a un campo.

En resumen, si desea permitir valores en blanco en un campo de fecha (por ejemplo, DateField, TimeField, DateTimeField) o campo numérico (por ejemplo, IntegerField, DecimalField, FloatField), tendrá que utilizar tanto null = True como blank = True.

Cambiemos nuestro modelo Book para permitir una fecha de publicación en blanco:

class Book(models.Model):

title = models.CharField(max_length=100)
authors = models.ManyToManyField(Author)
publisher = models.ForeignKey(Publisher)
publication_date = models.DateField(blank=True, null=True)

Agregar null = True es más complicado que añadir blank = True, porque null = True cambia la semántica de la base de datos, es decir, cambia la sentencia CREATE TABLE para eliminar el NOT NULL del campo publication_date. Para completar este cambio, necesitaremos actualizar la base de datos.

Por varias razones, Django no trata de automatizar los cambios en los esquemas de base de datos, por lo que es su propia responsabilidad ejecutar el ALTER TABLE adecuado siempre que se realice un cambio a un modelo. Recuerde que puede utilizar python manage.py dbshell para entrar en la shell de su servidor de base de datos. He aquí cómo quitar el NOT NULL en este caso en particular:

ALTER TABLE books_book ALTER COLUMN publication_date DROP NOT NULL;

Ahora el formulario de edición Add Book debería permitir valores de fecha de publicación vacíos.

Personalizar etiquetas de campo

En los formularios de edición del sitio de administración, la etiqueta de cada campo se genera a partir del nombre de campo del modelo. El algoritmo es simple: Django simplemente reemplaza los guiones bajos con espacios y coloca en mayúsculas el primer carácter. Así, por ejemplo, el campo publication_date del modelo Book tiene la fecha Publicación Date.

Sin embargo, los nombres de campo no siempre se prestan a etiquetas de campo agradables en administración, así que en algunos casos es posible que desee personalizar una etiqueta. Usted puede hacer esto especificando verbose_name en el campo del modelo adecuado. Por ejemplo, así es cómo podemos cambiar la etiqueta del campo Author.email a “e-mail”, con guión:

class Author(models.Model):

first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=40)
email = models.EmailField(blank=True, verbose_name=’e-mail’)

Por último, tenga en cuenta que puede pasar el verbose_name como un argumento de posición, para una sintaxis más compacta. Este ejemplo es equivalente al anterior:

class Author(models.Model):

first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=40)
email = models.EmailField(‘e-mail’, blank=True)

Esto no funcionará con campos ManyToManyField o ForeignKey, debido a que requieren que el primer argumento sea una clase modelo. En esos casos, especificar verbose_name explícitamente.

Personalizar clases ModelAdmin

Los cambios que hemos hecho hasta ahora – blank = True, null = True, y verbose_name- son realmente cambios de nivel de modelo, no cambios de nivel de administración. Es decir, estos cambios son, fundamentalmente, una parte del modelo y sólo para ser utilizados por el sitio de administración, no hay nada específico de administración en ellos.

Más allá de estos, el sitio de administración de Django ofrece una gran cantidad de opciones que permiten personalizar la forma en que el sitio de administración trabaja para un modelo en particular. Tales opciones residen en clases ModelAdmin, que son clases que contienen la configuración de un modelo específico en una instancia del sitio de administración específica.

Personalizar listas de cambios

Entremos en la personalización de administración, especificando los campos que se muestran en la lista de cambios para el modelo Author. De forma predeterminada, la lista de cambios muestra el resultado de __unicode__() para cada objeto.

Podemos mejorar este comportamiento predeterminado, añadiendo algunos campos más a la muestra de la lista de cambios. Sería útil, por ejemplo, ver cada e-mail del autor en esta lista, y sería bueno poder ordenarla por nombre y apellido.

Para que esto ocurra, vamos a definir una clase ModelAdmin para el modelo de Autor. Esta clase es la clave para personalizar la administración, y una de las cosas más básicas que le permite hacer es especificar la lista de campos a mostrar en las páginas de lista de cambios. Editar admin.py para realizar estos cambios:

from django.contrib import admin
from mysite.books.models import Publisher, Author, Book

class AuthorAdmin(admin.ModelAdmin):

list_display = (‘first_name’, ‘last_name’, ‘email’)

admin.site.register(Publisher)
admin.site.register(Author, AuthorAdmin)
admin.site.register(Book)

Volver a cargar la página de lista de cambios del autor, y verá que ahora se muestran tres columnas: el nombre, el apellido y la dirección de correo electrónico. Además, cada una de esas columnas es ordenable haciendo clic en el encabezado de la columna.

Ahora agreguemos una barra de búsqueda simple. Añadir a search_fields a AuthorAdmin, así:

class AuthorAdmin(admin.ModelAdmin):

list_display = (‘first_name’, ‘last_name’, ‘email’)
search_fields = (‘first_name’, ‘last_name’)

Actualice la página en su navegador, y debería ver una barra de búsqueda en la parte superior. Hemos incluido una barra de búsqueda que busca en los campos first_name y last_name. Ahora agreguemos algunos filtros de fecha para nuestra página de lista de cambios del modelo Book:

from django.contrib import admin
from mysite.books.models import Publisher, Author, Book

class AuthorAdmin(admin.ModelAdmin):

list_display = (‘first_name’, ‘last_name’, ‘email’)
search_fields = (‘first_name’, ‘last_name’)

class BookAdmin(admin.ModelAdmin):

list_display = (‘title’, ‘publisher’, ‘publication_date’)
list_filter = (‘publication_date’,)

admin.site.register(Publisher)
admin.site.register(Author, AuthorAdmin)
admin.site.register(Book, BookAdmin)

Hemos utilizado list_filter, que fija en una tupla los campos a utilizar para crear filtros en el lado derecho de la página de lista de cambios. Para los campos fecha, Django proporciona accesos directos para filtrar la lista por “Hoy”, “Últimos 7 días”, “Este mes”, y “Este año”.

list_filter también trabaja en campos de otros tipos, no sólo DateField. (Pruebe con los campos BooleanField y ForeignKey, por ejemplo.) Los filtros se muestran siempre que haya por lo menos dos valores a elegir.

Otra manera de ofrecer filtros de fecha es utilizar la opción de administración date_hierarchy, así:

class BookAdmin(admin.ModelAdmin):

list_display = (‘title’, ‘publisher’, ‘publication_date’)
list_filter = (‘publication_date’,)
date_hierarchy = ‘publication_date’

Tenga en cuenta que date_hierarchy toma una cadena, no una tupla, porque sólo un campo de fecha puede utilizarse para la jerarquía.

Por último, vamos a cambiar el orden por defecto en que se muestran los libros en la página de lista de cambios a siempre ordenado descendente por la fecha de su publicación.

class BookAdmin(admin.ModelAdmin):

list_display = (‘title’, ‘publisher’, ‘publication_date’)
list_filter = (‘publication_date’,)
date_hierarchy = ‘publication_date’
ordering = (‘-publication_date’,)

Usando estas opciones, usted puede hacer una interfaz de edición de datos muy potente, lista para producción, con sólo unas pocas líneas de código.

Personalizar los formularios de edición

En primer lugar, vamos a personalizar la manera en que se ordenan los campos. De forma predeterminada, el orden de los campos en un formulario de edición corresponde al orden en que están definidas en el modelo. Nosotros podemos cambiar eso utilizando la opción fields en nuestra subclase ModelAdmin:

class BookAdmin(admin.ModelAdmin):

list_display = (‘title’, ‘publisher’, ‘publication_date’)
list_filter = (‘publication_date’,)
date_hierarchy = ‘publication_date’
ordering = (‘-publication_date’,)
fields = (‘title’, ‘authors’, ‘publisher’, ‘publication_date’)

Otra cosa útil de la opción fields es que permite excluir a ciertos campos de la edición. Sólo dejando fuera los campo(s) que desea excluir. Por ejemplo, en nuestra base de datos de libros, se podría impedir que el campo publication_date fuese editable:

class BookAdmin(admin.ModelAdmin):

list_display = (‘title’, ‘publisher’, ‘publication_date’)
list_filter = (‘publication_date’,)
date_hierarchy = ‘publication_date’
ordering = (‘-publication_date’,)
fields = (‘title’, ‘authors’, ‘publisher’)

Otro uso común de personalizar los formularios de edición tiene que ver con los campos muchos a muchos. El sitio de administración representa cada ManyToManyField como una caja de selección múltiple. Si desea seleccionar varios elementos, hay que mantener pulsada la tecla Control. El sitio de administración amablemente inserta un fragmento de texto que explica esto, pero, aún así, se hace difícil de manejar cuando su campo contiene cientos de opciones. La solución del sitio de administración es filter_horizontal.

class BookAdmin(admin.ModelAdmin):

list_display = (‘title’, ‘publisher’, ‘publication_date’)
list_filter = (‘publication_date’,)
date_hierarchy = ‘publication_date’
ordering = (‘-publication_date’,)
filter_horizontal = (‘authors’,)

Recomendamos el uso filter_horizontal para cualquier ManyToManyField que tenga más de diez elementos. Es mucho más fácil de utilizar.También, recuerde que puede usar filter_horizontal en múltiples campos, especificando solamente cada nombre en la tupla. Las clases ModelAdmin también tienen una opción filter_vertical. Funciona exactamente como filter_horizontal, pero la interfaz coloca las dos casillas verticalmente en vez de horizontalmente. Es una cuestión de gusto personal.

filter_horizontal y filter_vertical funcionan sólo en los campos ManyToManyField, no en campos ForeignKey. Por defecto, el sitio de administración usa <select> simples para los campos ForeignKey, pero, como para ManyToManyField, a veces usted no quiere incurrir en la sobrecarga de tener que seleccionar todos los objetos relacionados con la pantalla en el menú desplegable. Por ejemplo, si nuestra base de datos de libros crece para incluir a miles de editores, el formulario Add Book podría tardar bastante en cargar, ya que tiene que cargar cada editor a mostrar en el cuadro <select>.

Puedes solucionar este problema con una opción llamada raw_id_fields. Ponga esto en una tupla de nombres de campo ForeignKey, y los campos se mostrarán en el administrador con una caja de entrada de texto simple (<input type = “text”>) en lugar de un <select>.

class BookAdmin(admin.ModelAdmin):

list_display = (‘title’, ‘publisher’, ‘publication_date’)
list_filter = (‘publication_date’,)
date_hierarchy = ‘publication_date’
ordering = (‘-publication_date’,)
filter_horizontal = (‘authors’,)
raw_id_fields = (‘publisher’,)

¿Qué introduciría en este cuadro de entrada? El identificador de la base de datos del editor.Teniendo en cuenta que los seres humanos normalmente no memorizan identificadores base de datos, hay un icono en el que puede hacer clic para iniciar una ventana desde la que puede seleccionar el editor.

Usuarios, grupos y permisos

Ya que está conectado como super-usuario, tiene acceso a crear, editar y eliminar cualquier objeto. Naturalmente, los diferentes entornos requieren de sistemas de autorización diferentes, no todos pueden o deben ser un superusuario. El sitio de administración de Django utiliza un sistema de permisos que se puede utilizar para dar acceso específico a los usuarios a las partes de la interfaz que necesitan.

Estas cuentas de usuario están destinadas a ser lo suficientemente generales como para utilizarse fuera de la interfaz de administración, pero las trataremos como cuentas de usuario de administración por ahora.

Puede editar los usuarios y los permisos a través de la interfaz de administración al igual que cualquier otro objeto. Los objetos de usuario tiene los campos nombre de usuario estándar, contraseña, e-mail, y nombre real, junto con un conjunto de campos que definen lo que el usuario puede hacer en la interfaz de administración. En primer lugar, hay un conjunto de 3 banderas boolean:

• El flag “activo” controla si el usuario está activo.
• El flag “staff” controla si el usuario tiene permiso para acceder a la interfaz de administración.
• El flag “superusuario” proporciona al usuario acceso completo a agregar, crear y eliminar cualquier elemento de la interfaz de administración.

Los usuarios de administración “normales” – es decir, los miembros activos, no superusuarios – se les concede acceso de administración a través de los permisos asignados. Cada objeto editable a través de la interfaz de administración (por ejemplo, libros, autores, editores) tiene tres permisos: crear, editar y eliminar. La asignación de permisos a un usuario concede al usuario el correspondiente nivel de acceso.

Al crear un usuario, dicho usuario no tiene permisos. Por ejemplo, usted puede dar a un usuario permiso para agregar y cambiar los editores, pero no para eliminarlos. Tenga en cuenta que estos permisos se definen por el modelo, no por objeto, de forma que usted diga, “Juan puede hacer cambios en cualquier libro,” pero no le permite decir, “Juan puede hacer los cambios de cualquier libro publicado por Apress. ”

También puede asignar usuarios a grupos. Un grupo es simplemente un conjunto de permisos que se aplican a todos los miembros de ese grupo. Los grupos son útiles para la concesión de permisos idénticos a un subconjunto de usuarios.

Enlaces Relacionados:

• Tutorial de Django I
• Tutorial de Django II
• Tutorial de Django III
• Tutorial de Django IV
• Tutorial de Django V
• Tutorial de Django VI

Latitude™ E6410/E6510 y E6410 ATG

Una nueva dimensión de libertad en el trabajo

Los distintos entornos de trabajo requieren distintos ordenadores y la gama de portátiles Dell Latitude™ aumenta sus posibilidades empresariales con el control de clase empresarial de los servicios informáticos, el diseño y la productividad para satisfacer casi cualquier necesidad de informática portátil profesional.

Diseño fiable

• Compacto, ligero y duradero gracias al diseño Dell TriMetal™, a Dell StrikeZone™ y al sensor de caída de respuesta rápida

Productividad inteligente

• Nuevas CPU Intel Core™ i5 e i7 con la tecnología Turbo Boost, memoria DDR3 y gráficos actualizados
• Cámara web de alta definición, micrófono digital y altavoces mejorados para una mejor experiencia de colaboración
• Movilidad optimizada gracias a las baterías de mayor duración

Control de clase empresarial

• Gama compatible entre sí con estaciones base comunes, periféricos intercambiables y adaptadores de CA compatibles
• Nueva batería de 3 años con garantía de que mantiene la vida óptima de la batería durante más tiempo

Presentación del nuevo Dell Precision M4500

Potencia cuando y donde la necesita

¿Sus clientes desean maximizar el rendimiento? El nuevo Dell Precision M4500 permite a los ingenieros y a los usuarios creativos ser productivos en cualquier parte. Dell ha incluido la máxima capacidad de rendimiento posible que se puede dar en una estación de trabajo portátil de 15″. También incluye más recursos para las aplicaciones con la certificación ISV y un diseño que permite gestionar las aplicaciones más exigentes para los usuarios finales creativos y profesionales más minuciosos.

¿Qué otras ventajas le ofrece el Dell Precision M4500?

• Movilidad y gran capacidad de ampliación. La estación de trabajo portátil de 15” con gran capacidad de ampliación innova con las últimas opciones de almacenamiento para satisfacer las necesidades de los usuarios que llevan enormes cantidades de datos en sus portátiles.
• Control total de la propiedad. Permite que las estaciones de trabajo portátiles sean tan seguras y fáciles de gestionar y de mantener como cualquier otro cliente comercial.
• Certificación de proveedores de software independientes para 95 aplicaciones de 35 proveedores clave del sector.
• Procesadores Intel® Core™ i5, Core™ i7 y Core™ i7 de núcleo cuádruple Extreme Edition para obtener un rendimiento excepcional.
• Gráficos avanzados en 3D con los motores de gráficos NVIDIA Quadro® FX 880M o Quadro® FX 1800M con 1 GB de memoria gráfica dedicada para las tareas más exigentes, como por ejemplo la edición de vídeo, animaciones y CAD.
• Memoria de hasta 8 GB con 2 ranuras DIMM que permite que las aplicaciones que requieren gran cantidad de memoria funcionen sin problemas.
• Dos unidades de almacenamiento (un disco duro y una minitarjeta SSD) con una capacidad de almacenamiento de hasta 500 GB.

Estas son sólo algunas de las ventajas de Dell Precision M4500.

Se han realizado múltiples mejoras, entre las cuales destacan:

• Mejoras en la indexación del contenido y de los elementos gráficos de las páginas
• Aumento de la indexabilidad en los sistemas de navegación del sitio web
• Alta y notificación de modificaciones en buscadores genéricos
• Generación de etiquetas

Enlaces Relacionados

• http://www.agentescomercialesdegestion.com