Cibernatural S.L. » Web

Gestión web de clientes y facturación en Django

admin — Fri, 16 Jul 2010 16:33:00 +0000

Cibernatural S.L. estrena una nueva y sencilla aplicación web de Gestión de clientes y facturas, presupuestos, partes de entrega y abonos, desarrollada completamente a partir del Sitio de Administración de Django, que proporciona una interfaz limpia y eficiente.

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.

Descargar en PDF

Web Corporativa de Transportes y Excavaciones Tiagua

admin — Mon, 05 Jul 2010 17:44:27 +0000

Cibernatural S.L. estrena la nueva web corporativa de la importante empresa del sector de la construcción en Lanzarote Transportes y Excavaciones Tiagua.

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.

Descargar en PDF

Optimización de motores de búsqueda de Agentes Comerciales de Gestión

admin — Thu, 22 Apr 2010 10:59:45 +0000

La empresa de Representación Comercial en Canarias ACG Representaciones, con objeto de mejorar el posicionamiento en buscadores, ha vuelto a confiar en Cibernatural para realizar el SEO (Optimización de motores de búsqueda) a la web corporativa de la empresa.

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

Descargar en PDF

Directorio de Casas Rurales en Lanzarote

admin — Wed, 07 Apr 2010 17:31:49 +0000

Cibernatural S.L. estrena el nuevo portal de Casas Rurales de la isla de Lanzarote.

http://www.casasruraleslanzarote.com

Dicho portal pretende servir como directorio de las Casas Rurales en Lanzarote que sus propietarios quieran poner en Alquiler, para que los clientes potenciales puedan acceder a toda la información de cada una de las casas rurales del directorio, así como a otra información relacionada con el turismo rural en Lanzarote como el Entorno, las Actividades a realizar (Senderismo, Rutas, etc.), Guias de transporte, etc.

Está disponible de momento en 5 idiomas: Castellano, Inglés, Fránces, Alemán y Catalán.

En breve, se pondrá en marcha un módulo de gestión de reservas on-line de las Casas Rurales de Lanzarote, para que los clientes puedan realizar su reserva de forma sencilla y cómoda.

Descargar en PDF

Tutorial de Django – III

admin — Mon, 29 Mar 2010 12:26:31 +0000

Plantillas – Templates

No es una buena idea codificar el HTML directamente en las vistas.

Es mucho más limpio y más fácil de mantener separar el diseño de la página del código Python. Podemos hacer esto con el sistema de plantillas de Django.

Base del Sistema de Plantillas

Una plantilla de Django es una cadena de texto para separar la presentación de un documento de sus datos. Una plantilla define contenedores y varios bits de lógica básica (etiquetas) que regulan la forma en que el documento debe ser mostrado. Por lo general las plantillas se utilizan para producir HTML, pero las plantillas Django plantillas son igualmente capaces de generar cualquier otro formato basado en texto.

Comencemos con una plantilla sencilla de ejemplo. Esta plantilla Django describe una página HTML que, da las gracias a una persona por hacer un pedido a la empresa.

Ordering notice

Ordering notice

Dear {{ person_name }},

Thanks for placing an order from {{ company }}. It’s scheduled to
ship on {{ ship_date|date:”F j, Y” }}.

Here are the items you’ve ordered:

{% for item in item_list %}

{{ item }}

{% endfor %}

{% if ordered_warranty %}

Your warranty information will be included in the packaging.

{% else %}

You didn’t order a warranty, so you’re on your own when
the products inevitably stop working.

{% endif %}

Sincerely,
{{ company }}

Esta plantilla es HTML básico con algunas variables y etiquetas de plantilla dentro de ella. Cualquier texto rodeado por un par de llaves (por ejemplo, {{ person_name }}) es una variable. Esto significa “insertar el valor de la variable con el nombre dado.” ¿Cómo podemos especificar los valores de las variables?Llegaremos a eso después.

Cualquier texto que está rodeado de llaves y porcentaje (por ejemplo, {% if ordered_warranted %}) es una etiqueta de plantilla. La definición de una etiqueta es bastante amplia: una etiqueta sólo le dice al sistema de plantillas “haz algo”.

Por último, el segundo párrafo de esta plantilla contiene un ejemplo de filtro, que es la forma más conveniente de modificar el formato de una variable. En este ejemplo, {{ ship_date | date: “F j, Y” }}, estamos pasandole a la variable ship_date el filtro date, dándole al filtro date el argumento “F j, Y”. El formato de filtro date formatea las fechas a un formato dado, como se especifica en el argumento. Los filtros son adjuntados con un carácter de canalización (|).

Cada plantilla Django tiene acceso a varias etiquetas y filtros incorporados, muchos de los cuales serán discutidos en las siguientes secciones.

Usando el sistema de plantillas

Entremos en el sistema de plantillas de Django para que cómo funciona, pero no estamos todavía para integrarlo con las vistas que hemos creado en el capítulo anterior. Nuestro objetivo aquí es mostrar cómo funciona el sistema independiente del resto de Django. (Por lo general vamos a usar el sistema de plantillas dentro de una vista de Django, pero hay que dejar claro que el sistema de plantillas es sólo una librería de Python que se puede utilizar en cualquier lugar, no sólo en las vistas de Django.)

Esta es la forma más básica en que se puede utilizar el sistema de plantillas de Django:

Crear un objeto Template proporcionando el código de la plantilla raw como una cadena.
Llamar al método render () del objeto Template con un conjunto de variables (el contexto). Esto devuelve una plantilla renderizada completamente como una cadena, con todas las variables y etiquetas de plantilla evaluadas de acuerdo al contexto.

>>> from django import template
>>> t = template.Template(‘My name is {{ name }}.’)
>>> c = template.Context({‘name’: ‘Adrian’})
>>> print t.render(c)
My name is Adrian.

>>> c = template.Context({‘name’: ‘Fred’})
>>> print t.render(c)
My name is Fred.

Crear objetos Template

La forma más fácil de crear un objeto Template es crear una instancia directamente. La clase Template reside en el módulo django.template, y el constructor toma un argumento, el código de plantilla raw.

Veamos algunos aspectos básicos del sistema de plantillas:

>>> from django.template import Template
>>> t = Template(‘My name is {{ name }}.’)
>>> print t

Si lo estamos haciendo de forma interactiva, veremos algo como esto:

Cuando se crea un objeto Template, el sistema de plantillas compila el código de la plantilla raw internamente de forma optimizada, preparándolo para el renderizado. Pero si el código de la plantilla incluye cualquier error de sintaxis, la llamada a Template() producirá una excepción TemplateSyntaxError.

Renderizar un Template

Una vez que tiene un objeto Template, puede pasarle datos, dándole un contexto. Un contexto es simplemente un conjunto de nombres de variables de plantilla y sus valores asociados. Una plantilla usa un contexto para rellenar sus variables y evaluar sus etiquetas.

Un contexto es representado en Django por la clase Context, que reside en el módulo django.template. Su constructor toma un argumento opcional: un diccionario que mapea los nombres de variables a los valores de las variables. Llamar al método render() del objeto Template con el contexto para rellenar la plantilla:

>>> from django.template import Context, Template
>>> t = Template(‘My name is {{ name }}.’)
>>> c = Context({‘name’: ‘Stephane’})
>>> t.render(c)
u’My name is Stephane.’

Debemos señalar aquí que el valor de retorno de t.render(c) es un objeto Unicode – no una cadena Python normal. Django utiliza objetos Unicode en lugar de cadenas normales en todo el framework.

He aquí un ejemplo de compilar y renderizar una plantilla, usando una plantilla similar a la ejemplo del principio de este capítulo:

>>> from django.template import Template, Context
>>> raw_template = “”"

Dear {{ person_name }},

…
…
Thanks for placing an order from {{ company }}. It’s scheduled to
… ship on {{ ship_date|date:”F j, Y” }}.

…
… {% if ordered_warranty %}
…
Your warranty information will be included in the packaging.

… {% else %}
…
You didn’t order a warranty, so you’re on your own when
… the products inevitably stop working.

… {% endif %}
…
…
Sincerely,
{{ company }}
“”"
>>> t = Template(raw_template)
>>> import datetime
>>> c = Context({‘person_name’: ‘John Smith’,
… ‘company’: ‘Outdoor Equipment’,
… ‘ship_date’: datetime.date(2009, 4, 2),
… ‘ordered_warranty’: False})
>>> t.render(c)
u”
Dear John Smith,
\n\n
Thanks for placing an order from Outdoor Equipment. It’s scheduled to\nship on April 2, 2009.
\n\n\n
You didn’t order a warranty, so you’re on your own when\nthe products inevitably stop working.
\n\n\n
Sincerely,Outdoor Equipment
”

Primero importamos las clases Template y Context, ambas residen en el módulo django.template.
Guardamos el texto raw de nuestra plantilla en la variable raw_template. Tenga en cuenta que usamos comillas triples para designar a la cadena, ya que se extiende por varias líneas, por contra, las cadenas entre comillas sencillas no pueden ser envueltas en varias líneas.
A continuación creamos un objeto plantilla, t, pasando raw_template al constructor de la clase Template.
Importamos el módulo de fecha y hora de la librería estándar de Python, porque la necesitaremos en la siguiente declaración.
Creamos un objeto Context, c. El constructor de Context, toma un diccionario Python, que mapea los nombres de variable a los valores. Aquí, por ejemplo, se especifica que persona_name es ‘John Smith’, company es ‘Outdoor Equipment “, y así sucesivamente.
Por último, llamamos al método render () de nuestro objeto plantilla, pasándole el contexto. Esto devuelve la plantilla renderizada, es decir, que reemplaza las variables de la plantilla con los valores actuales de las variables, y ejecuta cualquier etiqueta de la plantilla.

Esos son los fundamentos del uso del sistema de plantillas de Django: simplemente escribir una cadena de plantilla, crear un objeto Template, crear un Context, y llamar al método render().

Múltiples contextos, misma plantilla

Una vez que tiene un objeto Template, usted puede renderizar múltiples contextos a través de él. Considere este ejemplo:

>>> from django.template import Template, Context
>>> t = Template(‘Hello, {{ name }}’)
>>> print t.render(Context({‘name’: ‘John’}))
Hello, John
>>> print t.render(Context({‘name’: ‘Julie’}))
Hello, Julie
>>> print t.render(Context({‘name’: ‘Pat’}))
Hello, Pat

Cada vez que usted está utilizando la misma plantilla para renderizar múltiples contextos, es más eficiente crear el objeto plantilla una vez, y luego llamar a render() sobre él varias veces:

# Bad
for name in (‘John’, ‘Julie’, ‘Pat’):
t = Template(‘Hello, {{ name }}’)
print t.render(Context({‘name’: name}))

# Good
t = Template(‘Hello, {{ name }}’)
for name in (‘John’, ‘Julie’, ‘Pat’):
print t.render(Context({‘name’: name}))

Búsqueda de variable de Contexto

En los ejemplos hasta ahora, hemos pasado valores simples a los contextos – en su mayoría cadenas, además de un datetime.date. Sin embargo, el sistema de plantillas maneja estructuras de datos complejas, tales como listas, diccionarios, y objetos personalizados.

La clave para atravesar estructuras complejas de datos en las plantillas Django es el carácter de punto (.). Utilice un punto para acceder a las claves del diccionario, atributos, métodos, o índices de un objeto.

Por ejemplo, supongamos que usted está pasando un diccionario Python a una plantilla. Para acceder a los valores de ese diccionario por clave de diccionario, use el punto:

>>> from django.template import Template, Context
>>> person = {‘name’: ‘Sally’, ‘age’: ’43′}
>>> t = Template(‘{{ person.name }} is {{ person.age }} years old.’)
>>> c = Context({‘person’: person})
>>> t.render(c)
u’Sally is 43 years old.’

Del mismo modo, los puntos también permiten el acceso a los atributos de los objetos. Por ejemplo, un objeto datetime.date de Python tiene atributos año, mes, día, y puede utilizar un punto para acceder a esos atributos en una plantilla Django:

>>> from django.template import Template, Context
>>> import datetime
>>> d = datetime.date(1993, 5, 2)
>>> d.year
1993
>>> d.month
5
>>> d.day
2
>>> t = Template(‘The month is {{ date.month }} and the year is {{ date.year }}.’)
>>> c = Context({‘date’: d})
>>> t.render(c)
u’The month is 5 and the year is 1993.’

Este ejemplo utiliza una clase personalizada, lo que demuestra que los puntos permiten también el acceso a atributos de objetos arbitrarios:

>>> from django.template import Template, Context
>>> class Person(object):

def __init__(self, first_name, last_name):

self.first_name, self.last_name = first_name, last_name

>>> t = Template(‘Hello, {{ person.first_name }} {{ person.last_name }}.’)
>>> c = Context({‘person’: Person(‘John’, ‘Smith’)})
>>> t.render(c)
u’Hello, John Smith.’

Los puntos también puede hacer referencia a métodos de objetos. Por ejemplo, cada cadena Python tiene los métodos upper() y isdigit(), y usted puede llamarlos en las plantillas Django, usando la misma sintaxis del punto:

>>> from django.template import Template, Context
>>> t = Template(‘{{ var }}—{{ var.upper }}—{{ var.isdigit }}’)
>>> t.render(Context({‘var’: ‘hello’}))
u’hello—HELLO—False’
>>> t.render(Context({‘var’: ’123′}))
u’123—123—True’

Tenga en cuenta que no se incluyen los paréntesis en las llamadas a métodos. Además, no es posible pasar argumentos a los métodos, sólo puede llamar a métodos que no requieren argumentos.

Por último, los puntos también se utilizan para acceder a los índices de lista, como en este ejemplo:

>>> from django.template import Template, Context
>>> t = Template(‘Item 2 is {{ items.2 }}.’)
>>> c = Context({‘items’: ['apples', 'bananas', 'carrots']})
>>> t.render(c)
u’Item 2 is carrots.’

Las búsquedas de puntos se pueden resumir así: cuando la plantilla se encuentra con un punto en un nombre de variable, trata las búsquedas siguientes, en este orden:

Diccionario (por ejemplo, foo["bar"])
Atributo (por ejemplo, foo.bar)
Llamada a método (por ejemplo, foo.bar())
Índice de Lista (por ejemplo, foo[2])

El sistema utiliza el tipo de búsqueda que funciona primero. Es una falta de lógica del circuito.
Las búsquedas del punto se pueden anidar varios niveles de profundidad. Por ejemplo, el ejemplo siguiente utiliza {{ person.name.upper() }}, que se traduce en una búsqueda de diccionario (person['name']) y luego
una llamada al método (upper()):

>>> from django.template import Template, Context
>>> person = {‘name’: ‘Sally’, ‘age’: ’43′}
>>> t = Template(‘{{ person.name.upper }} is {{ person.age }} years old.’)
>>> c = Context({‘person’: person})
>>> t.render(c)
u’SALLY is 43 years old.’

Comportamiento de llamada a método

Las llamadas a los métodos son un poco más complejas que el de otros tipos de búsqueda. Aquí hay algunas cosas a tener en cuenta.

Si, durante la búsqueda de métodos, un método produce una excepción, la excepción se propagará a menos que la excepción tenga un atributo silent_variable_failure a True. Si la excepción tiene un atributo silent_variable_failure, la variable se renderizará como una cadena vacía, como en este ejemplo:

>>> t = Template(“My name is {{ person.first_name }}.”)
>>> class PersonClass3:

def first_name(self):

raise AssertionError, “foo”

>>> p = PersonClass3()
>>> t.render(Context({“person”: p}))
Traceback (most recent call last):
…
AssertionError: foo
>>> class SilentAssertionError(AssertionError):
… silent_variable_failure = True
>>> class PersonClass4:
…
def first_name(self):

…
raise SilentAssertionError

>>> p = PersonClass4()
>>> t.render(Context({“person”: p}))
u’My name is .’

Una llamada al método sólo funcionará si el método no requiere argumentos. De lo contrario, el el sistema se moverá al siguiente tipo de búsqueda (índice de lista).
Obviamente, algunos métodos tienen efectos colaterales y sería absurdo, y, posiblemente, incluso un agujero de seguridad, permitir al sistema de plantillas acceder a ellos. Digamos, por ejemplo, que tiene un objeto BackAccount que tiene un método delete(). Si una plantilla incluye algo como {{ account.delete() }}, donde account es un objeto BankAccount, el objeto sería eliminado al procesar la plantilla. Para evitar esto, establezca el atributo de función alters_data en el método:

def delete(self):

# Delete the account

delete.alters_data = True

El sistema de plantillas no ejecutará cualquier método marcado de esta manera. Continuando con el ejemplo actual, si una plantilla incluye {{ account.delete }} y el método delete() tienen alters_data = True, entonces el método delete() no se ejecutará cuando la plantilla se renderice. En su lugar, se producirá un error silencioso.

¿Cómo se gestionan las variables inválidas?

Por defecto, si una variable no existe el sistema de plantillas la renderiza como una cadena vacía, error silencioso. Considere este ejemplo:

>>> from django.template import Template, Context
>>> t = Template(‘Your name is {{ name }}.’)
>>> t.render(Context())
u’Your name is .’
>>> t.render(Context({‘var’: ‘hello’}))
u’Your name is .’
>>> t.render(Context({‘NAME’: ‘hello’}))
u’Your name is .’
>>> t.render(Context({‘Name’: ‘hello’}))
u’Your name is .’

Jugar con objetos Context

La mayoría de las veces, usted instanciará objetos Context pasando un diccionario totalmente lleno a Context(). Pero usted también puede añadir y eliminar elementos de un objeto Context, una vez instanciado,usando la sintaxis estándar de Python diccionario:

>>> from django.template import Context
>>> c = Context({“foo”: “bar”})
>>> c['foo']
‘bar’
>>> del c['foo']
>>> c['foo']
Traceback (most recent call last):
…
KeyError: ‘foo’
>>> c['newvariable'] = ‘hello’
>>> c['newvariable']
‘hello’

Etiquetas y Filtros de Plantilla Básica

Etiquetas

if / else

La etiqueta {% if %} evalúa una variable, y si esa variable es True (es decir, que existe, no está vacío, y no es un valor boolean FALSE), el sistema mostrará todo entre {% if %} y {% endif %}, como en este ejemplo:

{% if today_is_weekend %}

Welcome to the weekend!

{% endif %}

Una etiqueta {% else %} es opcional:

{% if today_is_weekend %}

Welcome to the weekend!

{% else %}

Get back to work.

{% endif %}

for

La etiqueta {% for %} permite un bucle sobre cada elemento de una secuencia. La plantilla renderizará todo entre {% for %} y {% endfor %}.

Por ejemplo, podría utilizar el siguiente ejemplo para mostrar una lista de atletas dada una variable athlete_list:

{% for athlete in athlete_list %}

{{ athlete.name }}

{% endfor %}

y al revés:

{% for athlete in athlete_list reversed %}
…
{% endfor %}

Es posible anidar etiquetas {% for %}.

La etiqueta for soporta una clausula opcional {% empty %} que le permite definir que salida si la lista está vacía.

{% for athlete in athlete_list %}

{{ athlete.name }}

{% empty %}

There are no athletes. Only computer programmers.

{% endfor %}

No hay soporte para opciones del tipo break y continue.

Dentro de cada bucle {% for %} usted puede acceder a una variable llamada forloop. Esta variable tiene algunas características que le dan información sobre el progreso del bucle:

forloop.counter siempre se establece en un número entero que representa el número de veces que se ha entrado en el bucle.
forloop.counter0 es como forloop.counter, excepto que es indexado en cero. Su valor será fijado a 0 la primera vez que se entre en el bucle.
forloop.revcounter siempre se establece en un número entero que representa el número de elementos restantes del bucle.
forloop.revcounter0 es como forloop.revcounter, excepto que es indexado en cero.
forloop.first es un valor booleano que se establece a True si esta es la primera iteración del bucle.
forloop.last es un valor booleano que se establece a True si esta es la última iteración del bucle.
forloop.parentloop es una referencia al objeto forloop del bucle padre, en caso de bucles anidados.

ifequal / ifnotequal

La etiqueta {% ifequal %} compara dos valores y muestra todo entre {% ifequal %} y {% endifequal %} si los valores son iguales. Este ejemplo compara la plantilla de las variables user y currentuser:

{% ifequal user currentuser %}

Welcome!

{% endifequal %}

Al igual que {% if %} la etiqueta {% ifequal %} soporta un {% else %} opcional:

{% ifequal section ‘sitenews’ %}

Site News

{% else %}

No News Here

{% endifequal %}

Sólo las variables de plantilla, cadenas, enteros y números decimales se permiten como argumentos para {% ifequal %}. Estos son ejemplos válidos:

{% ifequal variable 1 %}
{% ifequal variable 1.23 %}
{% ifequal variable ‘foo’ %}
{% ifequal variable “foo” %}

Cualquier otro tipo de variables, tales como diccionarios, listas o booleanos no pueden codificarse en la etiqueta {% ifequal %}. Estos son ejemplos inválidos:

{% ifequal variable True %}
{% ifequal variable [1, 2, 3] %}
{% ifequal variable {‘key’: ‘value’} %}

Si necesita testear si algo es verdadero o falso, use {% if %} en lugar de {% ifequal %}.

Comentarios

Para designar un comentario usar {# #}.

No pueden usar esta sintaxis para varias líneas. Para ello usar la etiqueta {% comment %}, como esto:

{% comment %}
This is a
multiline comment.
{% endcomment %}

Filtros

Los filtros de plantilla son formas sencillas de alterar el valor de las variables antes de renderizarlas. Los filtros utilizan un carácter de canalización (pipe), como esto:

{{ name|lower }}

Los filtros se pueden encadenar, es decir, que pueden ser usados en conjunto de manera que la salida de un filtro se aplica al siguiente. He aquí un ejemplo que convierte el primer elemento de una lista a mayúsculas:

{{ my_list|first|upper }}

Algunos filtros toman argumentos que vienen después de dos puntos y siempre entre comillas dobles. He aquí un ejemplo:

{{ bio|truncatewords:”30″ }}

Esto muestra las primeras 30 palabras de la variable bio.

Los siguientes son algunos de los filtros más importantes:

addslashes: Agrega una barra invertida antes de que cualquier barra invertida, comillas simples o comillas dobles. Esto es útil si el texto producido se incluye en una cadena JavaScript.
date: Formatea una cadena de fecha o fecha/hora de acuerdo a un formato dado como parámetro.
length: Devuelve la longitud del valor. Para una lista, devuelve el número de elementos. Para una cadena, devuelve el número de caracteres. Funciona en cualquier objeto Python que sabe cómo determinar su propia longitud, es decir, cualquier objeto que tiene un método __len__()

Filosofías y limitaciones

Ahora que usted tiene una idea del sistema de plantillas de Django, hay que señalar alguna de sus limitaciones intencionales, junto con algo de filosofía de por qué funciona de la forma en que funciona.

Más que cualquier otro componente de las aplicaciones web, la sintaxis de las plantillas es muy subjetiva, y las opiniones de los programadores varían significativamente.

Con esto en mente, es posible que le interese saber que Django no requiere que usted use su lenguaje de plantillas. Debido a que Django está destinado a ser un completo entorno web que proporcione todas las piezas necesarias para los desarrolladores web para ser productivo, muchas veces es más conveniente el uso del sistema de plantillas de Django que otras librerías de plantillas Python, pero no es un requisito estricto en ningún sentido.

Sin embargo, está claro que tenemos una fuerte preferencia por el lenguaje de plantillas de Django. El sistema de plantillas tiene sus raíces en la forma en que el desarrollo web se hace en el mundo en línea combinado con la experiencia de los creadores de Django. Aquí están algunas de nuestras filosofías:

La lógica de negocio deben estar separada de la lógica de presentación. Los desarrolladores de Django ven el sistema de plantillas como una herramienta que controla la presentación y la lógica relacionada con la presentación, y eso es todo.
La sintaxis debe estar desacoplada del HTML/XML. Aunque el sistema de plantillas de Django se utiliza principalmente para producir HTML, su intención es ser tan útil para los formatos no HTML, tales como el texto sin formato.
Los diseñadores se supone que se sienten cómodos con el código HTML. El sistema de plantillas no está diseñado de manera que las plantillas necesariamente se muestran muy bien en los editores WYSIWYG como Dreamweaver. Django espera que los autores de plantillas estén cómodos editando el HTML directamente.
Se asume que los diseñadores no son programadores de Python. Los autores del sistema de plantillas reconocen que a menudo las plantillas de las páginas web son escritas por los diseñadores, no por programadores, y por lo tanto no se debe asumir el conocimiento de Python.
El objetivo no es inventar un lenguaje de programación. El objetivo es ofrecer como mucho la funcionalidad del esquema de programación, tal como la ramificación y la iteración, que es esencial para la toma de decisiones relacionadas con la presentación.

Usando plantillas en vistas

Recordemos la vista current_datetime en mysite.views. Esto es:

from django.http import HttpResponse
import datetime

def current_datetime(request):

now = datetime.datetime.now()

html = “It is now %s.” % now

return HttpResponse(html)

Vamos a cambiar esta vista para utilizar el sistema de plantillas de Django. Al principio se podría pensar en hacer algo como esto:

from django.template import Template, Context
from django.http import HttpResponse
import datetime

def current_datetime(request):

now = datetime.datetime.now()

t = Template(“It is now {{ current_date }}.”)

html = t.render(Context({‘current_date’: now}))

return HttpResponse(html)

Está claro que utiliza el sistema de plantillas, pero no resuelve los problemas que hemos señalado. A saber, la plantilla está incrustada en el código Python, por lo que no se logra una verdadera separación de los datos y la presentación. Vamos a arreglar esto poniendo la plantilla en un archivo separado, que cargará esta vista.

En primer lugar, podría considerar la posibilidad de guardar la plantilla en algún lugar de su sistema de ficheros y usar Python para leer el contenido de la plantilla. Esto es lo que podría parecerse, suponiendo que la plantilla se ha guardado en el archivo /home/djangouser/templates/mytemplate.html:

from django.template import Template, Context
from django.http import HttpResponse
import datetime

def current_datetime(request):

now = datetime.datetime.now()

# Simple way of using templates from the filesystem.

# This is BAD because it doesn’t account for missing files!

fp = open(‘/home/djangouser/templates/mytemplate.html’)

t = Template(fp.read())

fp.close()

html = t.render(Context({‘current_date’: now}))

return HttpResponse(html)

Este enfoque, sin embargo, es poco elegante, por estas razones:

No maneja el caso de que el archivo falle, como se señala en el código. Si el archivo mytemplate.html no existe o no es legible, la llamada open() lanzará una excepción IOError.
Codifica a pelo la ubicación de la plantilla. Si usted fuera a utilizar esta técnica para cada función de vista, estaría duplicando las localizaciones de la plantilla – por no mencionar que se trata de escribir mucho.
Incluye una gran cantidad de código repetitivo aburrido. Tienes cosas mejores que hacer que escribir las llamadas a open(), fp.read(), y fp.close() cada vez que se carga una plantilla.

Para resolver estos problemas, vamos a utilizar la carga de plantillas y la herencia de plantillas.

Carga de Plantillas

Django proporciona un API cómodo y eficaz para la carga de plantillas del sistema de archivos, con el objetivo de eliminar la redundancia, tanto en las llamadas de carga de plantillas como en las plantillas en sí mismas.

Para usar esta API de carga de plantillas, primero tendrá que decirle al marco donde se almacenan las plantillas. El lugar para hacerlo es su archivo de configuración settings.py que hemos mencionado en el capítulo anterior, cuando se introdujo la propiedad ROOT_URLCONF.

Abra settings.py y encuentre la propiedad TEMPLATE_DIRS. De forma predeterminada, es una tupla vacía, y es probable que contenga algunos comentarios autogenerados:

TEMPLATE_DIRS = (

# Put strings here, like “/home/html/django_templates”

# or “C:/www/django/templates”.

# Always use forward slashes, even on Windows.

# Don’t forget to use absolute paths, not relative paths.

)

Este ajuste le indica al mecanismo de carga de plantillas de Django donde buscar las plantillas. Elija un directorio donde desea almacenar sus plantillas y añadalo a TEMPLATE_DIRS, así:

TEMPLATE_DIRS = (

‘/home/django/mysite/templates’,

)

Hay algunas cosas que debe recordar:

Usted puede especificar cualquier directorio que desee, siempre y cuando el directorio y las plantillas dentro de ese directorio sean legibles por la cuenta de usuario en las que el servidor Web se ejecuta. Se recomienda la creación de un directorio de plantillas dentro de su proyecto (es decir, dentro del directorio que ha creado mysite)
Si su TEMPLATE_DIRS sólo contiene un directorio, no se olvide de la coma al final de la cadena del directorio. Python requiere comas dentro de tuplas de un solo elemento para eliminar la ambigüedad de la tupla de una expresión en paréntesis.
Si está en Windows, incluya la letra de la unidad y utilice las barra inclinadas al estilo Unix en lugar de las barras invertidas.

Lo más simple es utilizar rutas absolutas (es decir, rutas de directorios que comienzan en la raíz del sistema de archivos). Si quiere ser un poco más flexible, sin embargo, usted puede construir TEMPLATE_DIRS dinámicamente, como en este ejemplo:

import os.path

TEMPLATE_DIRS = (

os.path.join(os.path.dirname(__file__), ‘templates’).replace(‘\\’,'/’),

)

Este ejemplo utiliza la variable “mágica” de Python __file__, que se ajusta automáticamente al nombre de archivo del módulo de Python en que reside el código. Se pone el nombre del directorio que contiene a settings.py (os.path.dirname), y se une con las plantillas de una manera (os.path.join), y entonces asegura que todo lo que se utiliza sean barras inclinadas en lugar de barras invertidas (en el caso de Windows).

Con TEMPLATE_DIRS activo, el siguiente paso es cambiar el código para el uso de la funcionalidad de la carga de plantillas de Django en lugar de codificar a pelo las rutas de las plantillas. Volviendo a nuestra vista current_datetime, vamos a cambiarla de esta manera:

from django.template.loader import get_template

from django.template import Context
from django.http import HttpResponse
import datetime

def current_datetime(request):

now = datetime.datetime.now()

t = get_template(‘current_datetime.html’)

html = t.render(Context({‘current_date’: now}))

return HttpResponse(html)

La función get_template() toma un nombre de plantilla como argumento, busca dónde la plantilla residee en el sistema de archivos, abre ese archivo, y devuelve un objeto Template compilado.

Si get_template() no puede encontrar la plantilla con el nombre que se le da, lanza una excepción TemplateDoesNotExist.

Ahora, crear el archivo current_datetime.html dentro de su directorio de plantillas mediante el siguiente código de plantilla:

It is now {{ current_date }}.

Actualice la página en el explorador Web, y usted debería ver la página completamente renderizada.

render_to_response()

Hemos mostrado cómo cargar una plantilla, rellenar un contexto, y devolver un objeto HttpResponse con el resultado de la plantilla renderizada. Lo hemos optimizado mediante el uso de get_template() en lugar de la codificación a pelo de las plantillas y las rutas de plantillas. Sin embargo, todavía se requiere una buena cantidad de código para escribir todas esas cosas. Debido a que estos pasos son iguales, Django proporciona una abreviatura que le permite cargar una plantilla, renderizarla, y devolver un HttpResponse, todo en una sola línea de código.

Esta abreviatura es una función llamada render_to_response(), que reside en el módulo django.shortcuts.
Aquí está el ejemplo current_datetime reescrito para utilizar render_to_response():

from django.shortcuts import render_to_response
import datetime

def current_datetime(request):

now = datetime.datetime.now()

return render_to_response(‘current_datetime.html’, {‘current_date’: now})

El primer argumento de render_to_response() es el nombre de la plantilla a usar. El segundo argumento, si lo hay, debe ser un diccionario para usar en la creación de un contexto para la plantilla. Si usted no proporciona un segundo argumento, render_to_response() utiliza un diccionario vacío.

locals()

Muchas veces, usted se encontrará que usted mismo cálcula algunos valores, los almacena en variables (por ejemplo, now en el código anterior), y envía esas variables a la plantilla. Esto es un poco redundante y también significa escribir más.

Usted puede usar la función Python llamada locals(). Esta devuelve un diccionario que asigna todos los nombres de variables locales a sus valores, donde local significa todas las variables que han sido definidas en el ámbito local. Así, la vista anterior podría reescribirse así:

def current_datetime(request):

current_date = datetime.datetime.now()

return render_to_response(‘current_datetime.html’, locals())

Hemos cambiado el nombre de la variable a current_date ahora, ya que ese es el nombre de variable que la plantilla espera.

Subdirectorios en get_template()

Puede ser difícil de manejar el almacenar todas sus plantillas en un solo directorio. Usted podría almacenar plantillas en subdirectorios de su directorio de plantillas, y eso está bien. De hecho, le recomendamos hacerlo; algunas características más avanzadas de Django (como el sistema de vistas genéricas) esperan esta disposición de plantillas por defecto.

t = get_template(‘dateapp/current_datetime.html’)

Ya que render_to_response() es una pequeña envoltura alrededor de get_template(), usted puede hacer lo mismo con el primer argumento de render_to_response(), así:

return render_to_response(‘dateapp/current_datetime.html’, {‘current_date’: now})

La etiqueta de plantilla include

Podemos introducir una etiqueta de plantilla integrada: {% include%}. Esta etiqueta permite incluir el contenido de otra plantilla. El argumento de la etiqueta debe ser el nombre de la plantilla a incluir, y el nombre de la plantilla puede ser una variable o una cadena entre comillas simples o dobles. Cada vez que tenga el mismo código en varias plantillas, considere el uso de {% include %} para eliminar la redundancia.

Estos dos ejemplos incluyen el contenido de la plantilla nav.html. Los ejemplos son equivalentes e ilustran bien el uso de las comillas simples o dobles:

{% include ‘nav.html’ %}
{% include “nav.html” %}

El siguiente ejemplo incluye el contenido de la plantilla, cuyo nombre figura en la variable template_name:

{% include template_name %}

Al igual que en get_template(), el nombre del fichero de la plantilla se determina mediante la adición al directorio de plantillas de TEMPLATE_DIRS para el nombre de la plantilla.

La plantillas incluidas son evaluadas dentro del contexto de la plantilla que las incluye. Por ejemplo, considere estas dos plantillas:

# mypage.html

{% include “includes/nav.html” %}

{{ title }}

# includes/nav.html

You are in: {{ current_section }}

Si renderiza mypage.html con un contexto que contiene current_section, entonces la variable estará disponible en la plantilla incluida, como era de esperar.

Si, en una etiqueta {% include %}, no se encuentra una plantilla con el nombre dado, Django hará una de estas 2 cosas:

Si DEBUG es True, verá una excepción TemplateDoesNotExist en una página de error de Django.
Si DEBUG es False, la etiqueta fallará de forma silenciosa, no visualizando nada en el lugar de la etiqueta.

Herencia de plantillas

Nuestros ejemplos de plantillas hasta ahora han sido pequeños fragmentos de código HTML, pero en el mundo real usted utilizará el sistema de plantillas de Django para crear páginas enteras de HTML. Esto lleva a un problema de desarrollo web común: a través de un sitio Web, ¿cómo se puede reducir la duplicación y la redundancia de áreas de página comunes, tales como la navegación de todo el sitio?

Una forma clásica de resolver este problema es usar includes de lado servidor, las directivas que usted puede incrustar dentro de sus páginas HTML para incluir una página web dentro de otra. De hecho, Django soporta esta aproximación con la etiqueta {% include %} que acabamos de describir. Pero la forma preferida de resolver este problema con Django es utilizar una estrategia más elegante llamado herencia de plantillas.

En esencia, la herencia de plantillas le permite construir una plantilla “esqueleto” base que contiene todas las partes comunes de su sitio y define “bloques” que las plantillas hijas puede rellenar.

Veamos un ejemplo de esto creando una plantilla más completa para nuestra vista current_datetime, editando el archivo current_datetime.html:

The current time

My helpful timestamp site

It is now {{ current_date }}.

Thanks for visiting my site.

Eso se ve muy bien, pero ¿qué sucede cuando queremos crear una plantilla para otra vista – por ejemplo, la vista hours_ahead? Si queremos volver a hacer otra plantilla HTML agradable, válida, completa, nos quedará algo como esto:

Future time

My helpful timestamp site

In {{ hour_offset }} hour(s), it will be {{ next_time }}.

Thanks for visiting my site.

Es evidente que hay mucho HTML duplicado. Imagínese si tuviéramos un sitio más típico, incluyendo una barra de navegación, una hojas de estilo, tal vez algo de JavaScript – empezaremos metiendo todo ese HTML redundante en cada plantilla.

La solución de include de lado servidor a este problema es factorizar las partes comunes de ambas plantillas y guardarlos en distintos fragmentos de plantilla, que luego son incluidos en cada plantilla. Tal vez desee guardar la parte superior de la plantilla en un archivo llamado header.html:

y quizá almacenar la parte inferior en un fichero llamado footer.html:

Thanks for visiting my site.

Con una estrategia basada en include, los encabezados y los pies de página son fáciles. Es el punto medio el desordenado. En este ejemplo, ambas páginas tienen un título -

My helpful timestamp site

pero ese título no puede encajar en header.html porque el en ambas páginas es diferente. Si incluimos el <h1> en la cabecera, tendríamos que incluir el <title>, que no nos permitiría personalizarlo por página. El sistema de herencia de plantillas de Django soluciona estos problemas. Puede pensar en ello como una versión dentro-fuera de los includes de lado servidor. En lugar de definir los fragmentos de código que son comunes, se definen los fragmentos de código que son diferentes. El primer paso es definir una plantilla base, un esqueleto de la página que las plantillas hijas rellenarán después. Aquí hay una plantilla base para nuestro ejemplo en curso: <blockquote> <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN”> <html lang=”en”> <head> <title>{% block title %}{% endblock %}

My helpful timestamp site

{% block content %}{% endblock %}

{% block footer %}

Thanks for visiting my site.

{% endblock %}

Esta plantilla, que llamaremos base.html, define un documento de esqueleto HTML sencillo que se utilizará para todas las páginas del sitio. Es el trabajo de las plantillas hijas reemplazar, añadir o dejar vacío el contenido de los bloques.

Estamos utilizando una etiqueta de plantilla que no hemos visto antes: la etiqueta {% block %}. Todo lo que hace una etiqueta {% block %} es decirle al motor de plantillas que una plantilla hija puede sustituir aquellas partes de la plantilla.

Ahora que tenemos esta plantilla base, podemos modificar nuestra plantilla current_datetime.html existente:

{% extends “base.html” %}

{% block title %}The current time{% endblock %}

{% block content %}

It is now {{ current_date }}.

{% endblock %}

Vamos a crear una plantilla para la vista hours_ahead del Capítulo 3. Se podría parecer a esto:

{% extends “base.html” %}

{% block title %}Future time{% endblock %}

{% block content %}

In {{ hour_offset }} hour(s), it will be {{ next_time }}.

{% endblock %}

¿No es esto bonito? Cada plantilla contiene sólo el código que es único para esa plantilla. No hay redundancia. Si usted necesita hacer un cambio de diseño de todo el sitio, sólo haga el cambio a base.html, y todas las otras plantillas inmediatamente reflejarán el cambio.

He aquí cómo funciona. Cuando se carga la plantilla current_datetime.html, el motor de plantillas ve la etiqueta {% extends %}, notando que esa plantilla es una plantilla hija. El motor carga inmediatamente la plantilla padre – en este caso, base.html.

En ese momento, el motor de plantillas nota las tres etiquetas {% block %} de base.html y sustituye esos bloques con el contenido de la plantilla hija.

La herencia no afecta al contexto de la plantilla. En otras palabras, cualquier plantilla en el árbol de herencia tendrá acceso a cada una de sus variables de plantilla en el contexto.

Puede utilizar tantos niveles de herencia, según sea necesario. Una forma común de utilizar la herencia es el siguiente enfoque de tres niveles:

Crear una plantilla base.html que contenga el diseño principal de su sitio. Esta contiene las cosas que rara vez o nunca se cambian.
Crear una plantilla base_SECTION.html por cada sección del sitio (por ejemplo, base_photos.html y base_forum.html). Estas plantillas extienden a base.html e incluyen estilos y diseño específicos de la sección.
Crear plantillas individuales para cada tipo de página, como una página del foro o una galería de fotos. Estas plantillas extienden a la plantilla de la sección correspondiente.

Este método maximiza la reutilización de código y facilita el añadir elementos a las zonas comunes, como la sección de navegación.

Aquí hay algunas pautas para trabajar con herencia de plantillas:

Si usted usa {% extends %} en una plantilla, debe ser la primera etiqueta de esa plantilla.
Generalmente, cuanto más etiquetas {% block %} en sus plantillas base, mejor. Recordar que las plantillas hijas no tienen que definir todos los bloques de los padres, así que usted puede definir en las plantillas hijas sólo los que necesita.
Si usted encuentra duplicación de código en varias plantillas, probablemente significa que usted debe mover el código a una etiqueta {% block %} de una plantilla padre.
Si usted necesita obtener el contenido del bloque de la plantilla padre, use {{ block.super }}, que es una variable “mágica” que proporciona el texto renderizado de la plantilla padre. Esto es útil si desea añadir el contenido de un bloque padre en lugar de sobreescribirlo completamente.
Usted no puede definir múltiples etiquetas {% block %} con el mismo nombre en la misma plantilla.
Esta limitación existe porque una etiqueta de bloque funciona en ambas direcciones. Es decir, un etiqueta de bloque no sólo proporcionan un contenedor para rellenar, sino que también define el contenido que rellena el contenedor en el padre. Si hubiese dos etiquetas {% block %} llamadas iguales en una plantilla, el padre no sabría cual de los contenidos de bloque utilizar.
El nombre de plantilla que se pasa a {% extends %} se carga utilizando el mismo método que usa get_template(). Es decir, el nombre de la plantilla se añade a la propiedad TEMPLATE_DIRS.
En la mayoría de los casos, el argumento de {% extends %} será una cadena, pero puede ser una variable, si usted no sabe el nombre de la plantilla padre hasta tiempo de ejecución. Esto le permite hacer algunas cosas de forma dinámica.

Enlaces Relacionados:

Descargar en PDF

Web corporativa C2 Construcción en Lanzarote

admin — Fri, 19 Mar 2010 16:58:25 +0000

Cibernatural S.L. estrena la web de la División Construcción del grupo C2 en Lanzarote – Canarias.

http://www.c2construccion.com

El grupo C2 estrena nueva web corporativa para su división de CONSTRUCCIÓN en la isla de Lanzarote, destacando los servicios que ofrecen para la gestión integral de sus proyectos, así como de la aplicaciones más avanzadas de sistemas constructivos y de seguridad en la construcción.

Páginas relacionadas

Descargar en PDF

Tutorial de Django – II

admin — Thu, 25 Feb 2010 12:17:18 +0000

Vistas y URLconfs

Su primera Página Django: Hola Mundo

Como primer objetivo, vamos a crear una página Web que produzca el mensaje de ejemplo famoso: “Hola mundo”.

Con Django, el contenido de la página es producido por una vista, y la dirección se especifica en una URLconf. En primer lugar, vamos a escribir la función de la vista “Hola Mundo”.

Una vista “Hola Mundo” es simple. Aquí está toda la función que debe escribir en el archivo views.py:

from django.http import HttpResponse

def hello(request):

return HttpResponse(“Hello world”)

Una vista en Python es sólo una función que toma un HttpRequest como su primer parámetro y devuelve una instancia de HttpResponse. Para que una función de Python sea una vista Django, tiene que hacer esas dos cosas. (Hay excepciones, pero las veremos más tarde.) Si en este momento ejecuta python manage.py runserver de nuevo, seguirás viendo el mensaje “Bienvenido a Django”, sin ningún rastro de “Hola mundo”. Eso se debe a que el proyecto mysite no conoce la vista hello; se necesita ahora decirle a Django explícitamente que se va a activar esa vista en una determinada URL, usando URLconf. Un URLconf es como una tabla de contenidos para un sitio web Django. Básicamente, es un mapeo entre las URL y las funciones de vista que deben llamarse para esas direcciones URL. El URLconf por defecto incluye algunas características comentadas de uso común en Django, por lo que la activación de esas características es tan fácil como descomentar las líneas adecuadas. Si se ignora el código comentado, aquí está la esencia de un URLconf:

from django.conf.urls.defaults import *

urlpatterns = patterns(”,

)

Lo más importante a destacar es la variable urlpatterns, que Django espera encontrarla en el módulo URLconf. Esta variable define la asignación entre las direcciones URL y el código que controla las direcciones URL. Por defecto, el URLconf está vacío – la aplicación Django está en blanco. Para agregar una URL y una vista al URLconf, simplemente añadir una tupla Python que asigna un patrón de URL a la función de la vista. He aquí cómo conectarlo en la vista hello:

from django.conf.urls.defaults import *

from mysite.views import hello

urlpatterns = patterns(”,

(‘^hello/$’, hello),

)

En pocas palabras, se le dice a Django que cualquier petición a la URL /hello/ debería ser gestionada por la función de vista hello.

Para probar los cambios a la URLconf, inicie el servidor de desarrollo de Django con el comando python manage.py runserver. (Si usted lo dejó ejecutándose también está bien. El servidor de desarrollo detecta automáticamente los cambios en su código Python y vuelve a cargarlos cuando sea necesario, para que no tenga que reiniciar el servidor entre los cambios.) El servidor se está ejecutando en la dirección http://127.0.0.1:8000/, por lo que abra un navegador Web y vaya a http://127.0.0.1:8000/hello/. Usted debe ver el texto “Hola mundo”, la salida de su vista Django. Usted hizo su primera página web en Django.

Una nota rápida sobre errores 404

En este punto, el URLconf define sólo un único patrón de URL: el que trata las solicitudes de la dirección /hello/. ¿Qué sucede cuando usted solicita una dirección URL diferente?

Usted debe ver un mensaje de “Página no encontrada”. Django muestra este mensaje porque ha solicitado una URL que no está definida en su URLconf.

La utilidad de esta página va más allá del mensaje básico de error 404. También le dice, de forma precisa que URLconf Django es usada y cada patrón utilizado en el URLconf. De esa información, usted debe ser capaz de determinar por qué la dirección URL solicitada arrojó un error 404.

Naturalmente, esta información es confidencial y está destinada únicamente a usted, el desarrollador Web. Si esto fuese un sitio de desplegado en Internet, usted no desearía exponer esa información al público. Por esta razón, esta página “Página no encontrada”, se muestra sólo si su Proyecto de Django se encuentra en modo de depuración. Le explicaremos cómo desactivar el modo de depuración más tarde. Por ahora, sólo sepa que cada proyecto Django creado se encuentra en modo de depuración, y si el proyecto no está en modo de depuración, Django emite una respuesta 404 diferente.

Una nota rápida sobre la raíz del sitio

Como se explicó en la última sección, verá un mensaje de error 404 si usted va a la raíz del sitio: http://127.0.0.1:8000/. El patrón URL para que coincida con la raíz del sitio es un poco contradictorio, por lo que es digno de mención. Cuando esté listo para poner en práctica una vista de la raíz del sitio, utilice el patrón de URL ‘^$’, que coincide con una cadena vacía. He aquí un ejemplo:

from mysite.views import hello, my_homepage_view

urlpatterns = patterns(”,

(‘^$’, my_homepage_view),

# …

)

Cómo Django procesa una petición:

Una petición viene a /hello/.
Django determina el URLconf raíz en base a ROOT_URLCONF.
Django busca en todos los urlpatterns del URLconf por el primero que coincida con /hello/.
Si encuentra una coincidencia, llama a la función de vista asociada.
La función de vista devuelve un HttpResponse.
Django convierte el HttpResponse en la respuesta HTTP apropiada, que resulta en una página web.

Ahora que conoce los aspectos básicos de cómo hacer páginas Django. Es muy sencillo, en realidad: sólo escribir funciones de vista y mapearlas a URLs a través de URLconfs.

Segunda vista: contenido dinámico

Vamos a crear algo más dinámico: una página Web que muestre la fecha y hora actuales. Este es un paso agradable y simple, porque no se trata de una base de datos o cualquier entrada de usuario, sólo la salida del reloj interno del servidor. Es sólo un poco más emocionante que “Hola mundo”, pero se muestran un par de conceptos nuevos.

Para realizar una vista Django que muestre la fecha y hora actuales, sólo es necesario colocar la sentencia datetime.datetime.now() en una vista y devolver un HttpResponse.

from django.http import HttpResponse

import datetime

def current_datetime(request):

now = datetime.datetime.now()

html = “It is now %s.” % now

return HttpResponse(html)

Al igual que con la función de vista hello, esta debe residir en views.py. Este es el aspecto completo de views.py:

from django.http import HttpResponse

import datetime

def hello(request):

return HttpResponse(“Hello world”)

def current_datetime(request):

now = datetime.datetime.now()

html = “It is now %s.” % now

return HttpResponse(html)

Después de añadir esto a views.py, agreguar el patrón URL a urls.py para decirle a Django que URL debe manejar esta vista. Algo como /time/ tendría sentido:

from django.conf.urls.defaults import *

from mysite.views import hello, current_datetime

urlpatterns = patterns(”,

(‘^hello/$’, hello),

(‘^time/$’, current_datetime),

)

Con la vista escrita y la URLconf actualizada, arrancar el runserver y visitar http://127.0.0.1:8000/time/ en el navegador. Usted debería ver la fecha y hora actuales.

URLconfs y acoplamiento débil

Ahora es un buen momento para destacar una filosofía clave detrás de URLconfs y detrás de Django en general: el principio de acoplamiento débil. Si dos trozos de código están débilmente acoplados, los cambios realizados a uno de ellos tendrá poco o ningún efecto en el otro.

Las URLconfs de Django son un buen ejemplo de este principio en la práctica. En una aplicación Web Django, las definiciones de URL y las funciones de vista que ellas llaman están débilmente acopladas, es decir, la decisión de lo que la URL debe ser para una determinada función y la implementación de la función residen en dos lugares diferentes. Esto le permite intercambiar una pieza sin afectar a la otra.

Por ejemplo, considere la vista del current_datetime. Si usted quiere cambiar la dirección por ejemplo, para moverla de /time/ a /current-time/ podría hacer un cambio rápido en URLconf sin tener que preocuparse por la vista. Del mismo modo, si usted quisiera cambiar la función de vista que altera la lógica de alguna manera, podría hacerlo sin afectar a la URL a la que está vinculada la función.

Además, si usted quiere exponer a la actual funcionalidad de la fecha en varias URL, usted fácilmente podría hacerlo editando URLconf, sin tener que tocar el código de la vista. En este ejemplo, el current_datetime está disponible en dos URLs. Es un ejemplo artificial, pero esta técnica puede ser útil:

urlpatterns = patterns(”,

(‘^hello/$’, hello),

(‘^time/$’, current_datetime),

(‘^another-time-page/$’, current_datetime),

)

Las URLconfs y las vistas están débilmente acopladas en la acción.

Tercera vista: URLs dinámicas

En la vista current_datetime, el contenido de la página, la fecha/hora actual, es dinámica, pero la dirección (/time/) es estática. En la mayoría de aplicaciones Web dinámicas, sin embargo, una dirección URL contiene los parámetros que influyen en la salida de la página. Por ejemplo, una librería on-line podría dar a cada libro su propia URL.

Crearemos una tercera vista que muestre la fecha y hora actuales compensada por un cierto número de horas. El objetivo es diseñar un sitio para que la página /time/plus/1/ muestre la fecha y hora dentro de una hora, la página /time/plus/2/ muestra la fecha y hora dentro de dos horas, la página /time/plus/3/ muestre la fecha y hora dentrop de tres horas, y así sucesivamente.

Un principiante podría pensar en codificar una función de vista distinta para cada desplazamiento de hora, que podría dar lugar a una URLconf como:

urlpatterns = patterns(”,

(‘^time/$’, current_datetime),

(‘^time/plus/1/$’, one_hour_ahead),

(‘^time/plus/2/$’, two_hours_ahead),

(‘^time/plus/3/$’, three_hours_ahead),

(‘^time/plus/4/$’, four_hours_ahead),

)

Entonces, ¿cómo diseñar la aplicación para manejar los desplazamiento de hora arbitrarios? La clave es usar comodines de patrones URL. Como se mencionó anteriormente, un patrón URL es una expresión regular, por lo que puede utilizar el patrón de expresión regular \d+ para que coincida con uno o más dígitos:

urlpatterns = patterns(”,

# … (r’^time/plus/\d+/$’, hours_ahead),

# …

)

Este nuevo patrón URL casará con cualquier URL como /time/plus/2/, /time/plus/25/, o incluso /time/plus/100000000000/.
Ahora, vamos a limitarlo de forma que se permita un desplazamiento máximo de 99 horas. Esto significa que queremos permitir, números de uno o de dos dígitos, y en la sintaxis de la expresión regular, que se traduce en \d(1,2):

(r’^time/plus/\d{1,2}/$’, hours_ahead),

Un detalle importante que se introduce aquí es el carácter r al principio de la expresión regular. Este caracter le dice a Python que la cadena es una “raw string” – su contenido no debe interpretar barras invertidas. En las cadenas normales de Python, las barras invertidas son usadas para caracteres de escape especiales, como la cadena ‘\n’, que es una cadena de caracteres que contiene una nueva línea.

Cuando se agrega el r para que sea una raw string, Python, no aplica el escape de la barra invertida, por lo que r’\n’ es una cadena de dos caracteres que contiene una barra invertida literal y la n minúscula. Se recomienda fuertemente que utilice raw string en cualquier momento si está definiendo una expresión regular en Python. A partir de ahora, todos los urlpatterns en este libro serán raw string.

Ahora que se ha designado un comodín para la dirección, usted necesita una manera de pasar esos datos de comodín a la función de vista, de modo que usted pueda utilizar una función de vista única para cualquier desplazamiento de hora arbitrario. Usted puede hacer esto colocando entre paréntesis los datos de la URLpattern que desea guardar. En el caso del ejemplo, lo que desea guardar es cualquier número que se introduzca en la URL, así que ponga paréntesis alrededor de \d(1,2), de esta manera:

(r’^time/plus/(\d{1,2})/$’, hours_ahead),

Usted está utilizando paréntesis para capturar datos del texto concordante. El URLconf final, incluidos los últimos dos puntos de vista, se parece a esto:

from django.conf.urls.defaults import *

from mysite.views import hello, current_datetime, hours_ahead

urlpatterns = patterns(”,

(r’^hello/$’, hello),

(r’^time/$’, current_datetime),

(r’^time/plus/(\d{1,2})/$’, hours_ahead),

)

hours_ahead es muy similar a la vista current_datetime escrita antes, con una diferencia clave: que lleva un argumento extra que el número de horas de desplazamiento. Aquí está la vista de código:

from django.http import Http404, HttpResponse

import datetime

def hours_ahead(request, offset):

try:

offset = int(offset)

except ValueError:

raise Http404()

dt = datetime.datetime.now() + datetime.timedelta(hours=offset)

html = “In %s hour(s), it will be %s.” % (offset, dt)

return HttpResponse(html)

Con esta función de vista y el URLconf escrito, iniciar el servidor de desarrollo de Django (si no está ya en ejecución), y visitar http://127.0.0.1:8000/time/plus/3/ para verificar que funciona. A continuación, intentar http://127.0.0.1:8000/time/plus/5/. Luego http://127.0.0.1:8000/time/plus/24/. Por último, visitar http://127.0.0.1:8000/time/plus/100/ para comprobar que el patrón en el URLconf acepta números sólo de uno o dos dígitos; Django debería mostrar un error de “Página no encontrada” en este caso, tal y como vimos. La URL http://127.0.0.1:8000/time/plus/ (sin horas) también debería lanzar un error 404.

Páginas de error bonitas en Python

Vamos a introducir deliberadamente un error de Python comentando en el archivo views.py las líneas offset=int(offset) en la vista de hours_ahead:

def hours_ahead(request, offset):

# try:

# offset = int(offset)

# except ValueError:

# raise Http404()

dt = datetime.datetime.now() + datetime.timedelta(hours=offset)

html = “In %s hour(s), it will be %s.” % (offset, dt)

return HttpResponse(html)

Inicie el servidor de desarrollo y vaya a /time/plus/3/. Usted verá una página de error con mucha información, incluido un mensaje TypeError que aparece en la parte superior: “unsupported type for timedelta hours component: unicode”

¿Qué pasó? Pues bien, la función de datetime.timedelta espera que el parámetro de horas que se le pase sea un número entero, y el trozo de código que convierte el desplazamiento a un número entero fue comentado. Eso provoca que datetime.timedelta lance un TypeError. Es el típico pequeño fallo que todos los programadores han cometido en algún momento.

El objetivo de este ejemplo es mostrar las páginas de error de Django. Tómese su tiempo para explorar la página de error y conocer la distinta información que ofrece.

La página de error de Django es capaz de mostrar más información en ciertos casos especiales, como el caso de errores de sintaxis de plantilla. Los veremos más tarde, cuando hablemos del sistema de plantillas de Django. Por el momento, descomente las líneas del offset = int (offset) para obtener la función de vista funcionando correctamente de nuevo.

Enlaces Relacionados:

Descargar en PDF

Web Residencial Grenwich-Lanzarote

admin — Tue, 23 Feb 2010 19:09:36 +0000

Cibernatural S.L. estrena la página web http://www.grenwich-lanzarote.com, Complejo Residencial de apartamentos de lujo en Playa Blanca – Lanzarote.

En ella puede ver los distintos tipos de apartamentos disponibles, una completa galería de imágenes, planos en formato PDF, el equipamiento de cada uno de ellos, así como la situación del complejo, el entorno, las actividades de ocio a realizar y los servicios que le ofrece Grenwich S.A. para realizar todos los trámites ya sea para la compra, alquiler, o alquiler con opción a compra.

Descargar en PDF

Tutorial de Django – I

admin — Thu, 11 Feb 2010 14:19:26 +0000

Introducción a Django

Django es un framework de desarrollo web escrito en Python con el que usted puede construir y mantener aplicaciones web de alta calidad con un mínimo de esfuerzo.

Instalar Python

Django está escrito completamente en Python, por lo que el primer paso en la instalación del marco es el asegurarse de que tiene Python instalado.

http://www.python.org/download/

Instalar Django

http://www.djangoproject.com/download/

Linux: sudo python setup.py install
Windows: python setup.py install

Los archivos de Django se instalarán en el directorio site-packages de su instalación de Python, en donde Python busca las bibliotecas de terceros.

Prueba de la instalación de Django

En una shell de comandos, cambie a otro directorio (no el directorio que contiene el directorio de Django) e inicie el intérprete de Python interactivo escribiendo python. Si la instalación fue exitosa, usted debe ser capaz de importar el módulo de Django:

>>> import django
>>> django.VERSION
(1, 1, 0, ‘final’, 1)

Establecer una base de datos

En este punto, usted podría comenzar a escribir una aplicación Web con Django, porque el único requisito previo es una instalación de Python. Sin embargo, es probable que desarrolle un sitio web controlado por base de datos, en cuyo caso tendrá que configurar un servidor de base de datos.

Django es compatible con cuatro motores de base de datos:

La configuración de la base de datos es un proceso de dos pasos:

En primer lugar, tendrá que instalar y configurar el servidor de base de datos.
En segundo lugar, tendrá que instalar la librería Python para nuestra base de datos de back-end. Esto es código Python de terceros que permite interactuar con la base de datos.

Uso de Django con MySQL

Django requiere MySQL 4.0 o superior. Las versiones 3.x no soportan subconsultas anidadas y algunas otras sentencias SQL estándar .

También tendrá que instalar el paquete de MySQLdb desde http://www.djangoproject.com/r/python-mysql/.
En Linux, puede comprobar si su paquete de distribución del sistema de gestión ofrece un paquete llamado python-mysql, python-MySQLdb, mysql-python, o algo similar.

Iniciar un proyecto

Una vez que haya instalado Python, Django, y (opcionalmente) el servidor/librería de base de datos, puede dar el primer paso del desarrollo de una aplicación Django mediante la creación de un proyecto.

Un proyecto es una colección de ajustes de una instancia de Django, incluyendo la configuración de la base de datos, las opciones específicas de Django, y la configuración de la aplicación.

Si es la primera vez que usa Django, usted tendrá que tener cuidado con la configuración inicial. Cree un nuevo directorio para comenzar a trabajar, tal vez algo como /home/nombre de usuario/djcode/

Vaya al directorio que ha creado y ejecute el comando siguiente:

django-admin.py startproject mysite

Esto creará un directorio mysite en el directorio actual.

El comando startproject crea un directorio que contiene cuatro archivos:

mysite/

__init__.py
manage.py
settings.py
urls.py

__init__.py: Un archivo necesario para que Python trate el directorio mysite como un paquete (un grupo de módulos de Python). Es un fichero vacío, y normalmente no se le añade nada.
manage.py: Utilidad de línea de comandos que le permite interactuar con el proyecto Django de diversas maneras. Con python manage.py puede tener una idea de lo que puede hacer. Usted nunca tiene que editar este archivo, sino que se crea en el directorio por pura conveniencia.
settings.py: Características de configuración de este proyecto Django. Echele un vistazo para tener una idea de los tipos de configuraciones disponibles, junto con sus valores predeterminados.
urls.py: Las direcciones URL de este proyecto Django. Piense en ello como la “tabla de contenidos” de su sitio Django. Por el momento, está vacío.

A pesar de su pequeño tamaño, estos archivos ya constituyen una aplicación Django de trabajo.

Ejecutar el servidor de desarrollo (runserver)

El servidor de desarrollo de Django (también llamado runserver debido al comando que lanza) es un servidor web ligero que puede utilizar durante el desarrollo de su sitio. Está incluido con Django para que pueda desarrollar su sitio rápidamente, sin tener que lidiar con la configuración del servidor de producción (Apache, por ejemplo) hasta que esté listo para la producción.

El servidor de desarrollo rastrea su código y automáticamente vuelve a cargarlo, por lo que es fácil para usted cambiar el código sin necesidad de reiniciar nada.

Para iniciar el servidor, vaya al directorio del proyecto si no lo ha hecho, y ejecute este comando:

python manage.py runserver

Esto iniciará el servidor de forma local en el puerto 8000, accesible sólo para las conexiones de su propio equipo. Ahora que está en ejecución, visite http://127.0.0.1:8000/ con su navegador Web. Verá un “Welcome to Django” ¡Funciona!

Enlaces relacionados:

Descargar en PDF

Web del C.D. Gymnástica GranaSport

admin — Thu, 29 Oct 2009 14:23:22 +0000

Desarrollo de la Web corporativa del Club Deportivo Gymnástica GranaSport, dedicado fundamentalmente a las clases de Gimnasia Rítmica y Ballet, y la organización de shows vinculados a la danza y la gimnasia, en la Isla de Tenerife.

http://www.gimnasticagranasport.es/

Descargar en PDF