//barrabarra

Django y error No module named models

Javi — Thu, 27 May 2010 08:19:27 +0000

Esta mañana estaba refactorizando un poco el código de la aplicación de tiendas antes de subirlo al repositorio de un cliente y me he encontrado con el error que describe el título y que me ha traído de cabeza toda la mañana.

Uno de los cambios que estaba haciendo al código era sustituir líneas del tipo: from tienda.checkout.models import * por from checkout.models import * para mejorar la portabilidad de las aplicaciones, pero a raíz de eso el sitio dejó de funcionar y lo único que recibía era ese mensaje de error.

A la postre resulta que tenía una estructura de directorios y ficheros tal que así:
cart\
   __init__.py
   admin.py
   models.py
   cart.py
   views.py
checkout\
   __init__.py
   admin.py
   models.py
   checkout.py
   views.py

etc.

El problema ocurría cuando python interpretaba los ficheros cart.py y checkout.py (entre otros) e intentaba luego buscar modelos en ellos al tener el mismo nombre que el directorio en el que se encuentran.

La solución una vez sabido esto fué sencilla, cambiar los nombres por cart_functions.py y checkout_functions.py a los archivos y en todos aquellos lugares en los que se usaban.

Error en Django Admin al buscar: Related Field has invalid lookup: icontains

Javi — Mon, 24 May 2010 16:20:52 +0000

Mientras buscaba en un gran listado de productos desde la administración de django me he topado con el siguiente error:

Related Field has invalid lookup: icontains

A la postre resulta que el problema venía por cómo estaba definida la clase de administración del modelo:


class ProductAdmin(admin.ModelAdmin):

   # sets values for how the admin site lists your products

   list_display = ('name', 'price', 'brand', 'stock', 'is_pack', 'created_at', 'updated_at',)

   ...

   search_fields = ['name', 'categories', 'brand', 'internal_reference', 'description']

   ...

Y es que ‘categories’ es una clave externa (ForeignKey) y por eso hay que definir sobre qué campo asociado se buscará, se soluciona, por ejemplo, con:


   search_fields = ['name', 'categories__name', 'brand', 'internal_reference', 'description']

Django: Flatpages devuelven error 404

Javi — Mon, 17 May 2010 19:08:51 +0000

Los últimos proyectos en los que estoy trabajando van sobre una plataforma de comercio electrónico.
Como tal, a la hora de mostrar errores a los visitantes/clientes, es importante no desconcertarlos y hacer que pierdan la confianza en el sitio web, por lo cual se personalizan las páginas de error para que se integren en el resto del sitio y además se aprovecha para mostrarle productos que podrían interesarle.

Debido a estos listados de productos no podemos simplemente renderizar un template para los errores, sino que he implementado un manejador para los errores: file_not_found_404 y handler_500. Estos hacían bien su trabajo mientras realizaba el desarrollo en local, sin embargo, cuando se pasaba a pruebas en el entorno de producción todas las páginas estáticas definidas con el framework flatpages direccionaban a la página de error 404.

Después de muchas vueltas, pruebas, desactivar el manejador, revisar logs y volver a probar y a dar vueltas ví que en los logs de acceso las páginas de errores 404 devolvían un status 200 (Ok), lo cual finalmente me dió la pista que necesitaba: tenía que sobreescribir el status_code de la respuesta a 404, ya que por defecto el valor es 200.

El manejador quedó con algo parecido a esto:


def file_not_found_404(request):

    page_title = _('Page Not Found')

    

    featured = Product.featured.all()[0:FEATURED_PER_ROW] 

    bestseller = Product.bestseller.all()[0:BESTSELLER_PER_ROW]

    recommended = Product.recommended.all()[0:RECOMMENDED_PER_ROW]

    

    response = render_to_response('404.html', locals(), context_instance=RequestContext(request))

    response.status_code = 404

    return response

Django: acceder al value de los campos de un formulario

Javi — Sat, 27 Mar 2010 19:47:41 +0000

Recientemente he tenido que preparar una plantilla en django que mostrara una serie de imágenes del usuario y un formulario adyacente en el que podían sustituir esta, así que me encontraba con el problema de mostrar al usuario sus fotos actuales, si es que tenían.

Para ello se crea un formulario heredando del modelo:


forms.py:

class PhotosForm(forms.ModelForm):

   photo = forms.ImageField(label=_(u'Fotografía'), required=False)

   current = forms.CharField(label='', widget=forms.HiddenInput(), required=False)

    

   class Meta:

      model = ProfilePhotos

      exclude = ('profile','accepted',)

Luego, en la vista, puedes consultar el perfil del usuario en cuestión y ver si tiene fotografías:


views.py

@login_required

def edit_photos(request, template_name='members/photos.html'):

   page_title = _(u'Editar fotografías')

   PhotosFormSet = formset_factory(PhotosForm, extra=5, max_num=5)

   profile = request.user.profiles_set.filter(accepted=True).latest('date')



   if request.method == 'POST':

       ...

   else:

      profile_photos = profile.profilephotos_set.filter(accepted=True)

      if profile_photos:

         data = []

         for photo in profile_photos:

            data.append({'current': photo.photo.name})

         formset = PhotosFormSet(initial = data)

      else:

         formset = PhotosFormSet()

Y finalmente, en la plantilla se puede acceder a los valores de los campos mediante


photos.html:

   {{ formset.management_form }}

   {% for photos_form in formset.forms %}

   

   {% if photos_form.initial.current %}

      [img src="{{photos_form.initial.current }}" alt="" /]

   {% else %}

      [img src="default.jpg" alt="" /]

   {% endif %}

   


   ...

Y del mismo modo, se puede acceder mediante form.initial.nombre_clave a cualquier otro dato inicial.

Si en lugar de proporcionar datos iniciales lo que hacemos es asociar el formulario a una instancia ( form.is_bound == True ) entonces podremos acceder a los datos mediante form.data.nombre_clave

Bah, como salta a la vista, el formateo de código de Wordpress no es muy bueno…

Actualización de MotrilCenter

Javi — Tue, 15 Dec 2009 18:52:48 +0000

De cara a las fiestas Motrilcenter ha lanzado una serie de planes promocionales para facilitar el acceso a sus viviendas en Motril y he estado actualizando la página.

Actualización Diciembre 09 Motrilcenter

Con esto me he dado cuenta de una cosa ¡Aún no le había puesto favicon a la página!

Página en blanco tras instalar OpenCart bajo ArchLinux, solución: Zlib

Javi — Tue, 08 Dec 2009 17:17:20 +0000

Estaba instalando OpenCart (1.3.4) bajo ArchLinux y me he encontrado que tras seguir los pasos de instalación correctamente, al finalizar esta e intentar cargar el sitio el navegador no mostraba nada.

Mostrando más detalles en Chromium obtenía el error: net::ERR_CONTENT_DECODING_FAILED y Firefox devolvía el error: Error de codificación de contenido

Estos me han dado pistas para que buscara cómo se enviaba el código y resulta que estaba comprimido. Se da la situación de que la instalación de PHP en Archlinux deja desactivada esa opción y de ahí viene el error.

La solución, editar /etc/php/php.ini y poner zlib.output_compression = On

Borrar todos los archivos eliminados de la copia de trabajo de SVN

Javi — Wed, 25 Nov 2009 10:27:47 +0000

Es más difícil de explicar que de entender.

Cuando trabajamos con subversion, a menudo vamos borrando archivos y luego al realizar el commit se nos quedan marcados con estado ! los archivos borrados en lugar de borrarse.

Para no tener que ir borrándolos uno a uno con svn del ‘archivo’ yo uso el siguiente script:

svn status | grep ! | awk '{print $2}' | xargs svn del

Con eso los marco para borrarse en el siguiente commit.

CodeIgniter paso a paso (I)

Javi — Thu, 19 Nov 2009 16:56:42 +0000

CodeIgniter es un framework de desarrollo para PHP que sigue la filosofía MVC ¿esto qué significa? a grandes rasgos que desarrollarás tu aplicación en tres apartados: el Modelo -para trabajar con las base de datos-, la Vista -las páginas que se van a presentar en el navegador- y el Controlador -donde se procesan los datos y se vuelca la información que queremos mostrar a la vista-.

Para trabajar con CodeIgniter es importante que conozcas programación orientada a objetos o las cosas te sonarán raras. Bien, dando esto por sentado, vamos a pasar a instalar y configurar una primera aplicación.

Desde la página oficial nos descargamos su versión más reciente y procedemos a descomprimirla en nuestro directorio de trabajo. También pasaremos por la sección de internacionalización (i18n) del Wiki y descargaremos los archivos de traducciones al español. Una vez descargado, extraeremos el contenido en la carpeta system/languages. Tras todo esto, debe quedarnos una estructura de directorios similar a la de la siguiente imagen:

Jerarquía de directorios tras instalar CodeIgniter y el idioma español

Hecho esto lo siguiente para empezar con nuestra aplicación será editar los archivos system/config/config.php, donde modificaremos las variables:

la ruta en la que se encuentra la aplicación
$config['base_url'] = "http://localhost/lab/";
el idioma de la aplicación
$config['language'] = "spanish";
la clave de encriptado
$config['encryption_key'] = "clave";
Para que esto tenga sentido debes usar una clave larga (32 caracteres), con mayúsculas, minúsculas, números y símbolos. Si vas a encriptar las cosas hazlo bien, o no lo hagas.

en system/config/database.php pondremos los datos de conexión a la base de datos con la que vayamos a trabajar:

la dirección de la base de datos
$db['default']['hostname'] = "localhost";
un nombre de usuario de esa base de datos
$db['default']['username'] = "usuario";
su contraseña correspondiente
$db['default']['password'] = "clave";
el nombre de la base de datos con la que vas a trabajar
$db['default']['database'] = "nombre_base_de_datos";

Con estos pasos ya podemos ir a la dirección de nuestra aplicación y ver la pantalla de bienvenida de CodeIgniter que contiene al pie un enlace a la estupenda guía de usuario de este framework.

Página de bienvenida de CodeIgniter