My previous post about the alphabet filterexplained the first take at creating the alphabet filter. There were several issues, especially with international character sets, so we have revised the code to fix the issues and made it installable via PyPI.

The Default Alphabet

The default alphabet is the list of characters displayed in the admin even if there is no data for that character. As there is data, the letters of the alphabet are enabled. Any characters not in the default alphabet, but that exist in the data, are added dynamically.

There is no easy way to determine what the default alphabet should be based on the language or locale. We hit several barriers while automating the default alphabet:

1. 
   
2. 
   

   The default character encoding (on a Mac and in English, at least) is ISO-8859-1, but Django tries to interpret it as UTF-8.

   
   
   
3. 
   

   The default character set includes too many characters.

   
   
   
4. 
   

   Some languages (I'm looking at you, Spanish) treat certain two-letter combinations as letters (e.g. ch and ll).

   
   
   

Due to these issues, the default alphabet is now a setting named DEFAULT_ALPHABET. The default setting is the ASCII alphabet and digits. You can set the DEFAULT_ALPHABETto a string or list or tuple.

If you only what the ASCII characters, no digits:

DEFAULT_ALPHABET = u'ABCDEFGHIJKLMNOPQRSTUVWXYZ'

For the German alphabet:

DEFAULT_ALPHABET = u'0123456789A\xc4BCDEFGHIJKLMNO\xd6PQRS\xdfTU\xdcVWXYZ'

For the Icelandic alphabet:

DEFAULT_ALPHABET = u'0123456789A\xc1BD\xd0E\xc9FGHI\xcdJKLMNO\xd3PRSTU\xdaVXY\xdd\xde\xd6'

The ordering of the alphabet will not stay the same as entered, it is sorted through Python's list sort method.

Using Alphabet Filter on a Model

You need to do two things to make it work on a model

1. 
   
2. Add an alphabet_filter setting in the ModelAdmin.
   
3. Create a custom template.
   

The first step is easy: in the model's admin.pyset alphabet_filterto the name of a character field. For example:

class TagAdmin(admin.ModelAdmin):
    alphabet_filter = 'name'

You also have to create a template for the model (or application) that will override the admin's change_list.htmltemplate.
Within your project's template directory, you need to create an admindirectory, and a directory with the name of the application, and optionally the name of the model. For example, if you were adding the filter on the Tagmodel of an application named cooltags, the directory structure would look like::

MyProject
    templates
        admin
            cooltags
                tag

Create a document named change_list.htmland put it in either the application (templates/admin/cooltags) directory, to have it work for every model within that application or put it in the model directory (templates/admin/cooltags/tag) to have it work only for that model.

The change_list.html document should only contain one line:

{% extends "alphafilter/change_list.html" %}

You cannotplace this template in the admindirectory, as it leads to an infinite loop of inheritance. The alphafilter's change_list.htmltemplate extends Django's change_list.htmltemplate. Django always looks for overridden templates first, so it would find your template, which extends alphafilter/change_list.html, which extends admin/change_list.htmland it finds your template again.
There are no side effects of using this ModelAdminsetting without the special template, or using the special admin template without the setting in the ModelAdmin. Either way, you just won't see the alphabet filter.

01 Jan 1970 12:00am GMT

In Autumn 2010 I will be running several Django courses throughout the UK. The dates and locations will be based on demand, so please signup here to express your interest, and I'll contact you when the venues have been arranged. There will be 2 different types of courses: Django template design - 1 day - for html/css [...]

01 Jan 1970 12:00am GMT

01 Jan 1970 12:00am GMT

Today we released LFS 0.5.0 beta 4

What's new?

• Bugfix pages: caching page_view
• Bugfix cart: display correct stock amount within growl message
• Bugfix product_inline: display property title within error message
• Bugfix order_received_mail.html: display the correct selected values of a configurable product
• Bugfix cart: calculation of maximum delivery date
• Bugfix redirect: save redirect url for variants
• Bugfix lfs.page.views: added missing import of Http404
• Bugfix: restrict adding to cart if the product is not deliverable. Issue #37
• Added french translations (Jacques Seite)
• Added get_properties method to OrderItem
• Added optional cached parameter to cart/utils/get_cart_price and cart/utils/get_cart_costs
• Removed javascript which dynamically sets the height of the slots.
• Changed properties management: display name instead of title within left portlet
• Improved lfs.portlet: caching

Further Information

You can find more information and help on following places:

• Official page
• Documentation on PyPI
• Demo
• Releases on PyPI
• Source code on bitbucket.org
• Google Group
• lfsproject on Twitter
• IRC

01 Jan 1970 12:00am GMT

django-treebeard 1.61 has been released (CHANGES). It's in pypi so you can install it with pip or easy_install. You can get the code in the Mercurial repo. There is also a well maintained Git mirror. Please report bugs in the … Continue reading →

01 Jan 1970 12:00am GMT

• Creating an Alphabetical Filter in Django's Admin
• Partial Deployment with Feature Switches
  • Always Ship Trunk
• Proposal: Revised form rendering
  • On Form Libraries
• Query Refactor Update
• Investing in Yourself - A review of Django 1.1 Testing and Debugging by Karen M. Tracey

01 Jan 1970 12:00am GMT

Here are the slides from my talk at Europython 2010, Advanced Django ORM Techniques.

The talk is mainly a summary of the query optimisation tricks I've previously talked about on this blog, although I did begin by explaining briefly how models, fields and relationships work behind the scenes - I'll write some of that up here at some point.

I'll also be posting a longer review of Europython here, hopefully in the next few days.

01 Jan 1970 12:00am GMT

I'm pleased to announce that Foundry's first web site has gone live: Swoop Travel.

Swoop Travel is a GeoDjango site using PostgreSQL and PostGIS, although very little GIS functionality is in the public-facing site at the moment - it's mainly in the backend.

We built this from scratch in about a month (while juggling other projects too!) are are pretty pleased with how it's turned out. This is just the first iteration and we're looking forward to expanding the site.

GeoDjango is pretty awesome. As we work on the site and get more experience, I'll post some more about some of the innards: there's quite a lot of interesting stuff in the backend, particularly admin customisations like filtering dropdowns based on landmarks within geographic regions, and so on. I'll also try to talk about the production server configuration, as GeoDjango needs a slightly different WSGI configuration to the standard run-of-the-mill Django site.

01 Jan 1970 12:00am GMT

I'm pleased to announce the release of djangoembed, a django app for consuming and providing rich media.

What is OEmbed?

OEmbed is a format for allowing a rich representation of a url. If you've used Facebook you've probably seen this feature before -- linking a YouTube video will embed an actual video player in the news feed, automatically. The player is represented by some HTML, plus there may be additional metadata like the author, a link to their channel, the title of the video, or even a thumbnail.

01 Jan 1970 12:00am GMT

Després de barallar-m'hi un bon grapat de dies he aconseguit integrar el TPV de CECA en una de les aplicacions que estic desenvolupant per APSL. Com en el cas de la integració amb el BBVA he de dir que la qualitat de la documentació és inversament proporcional al suport que tens dels tècnics, per a que quedi clar: la documentació és pèssima, plena de inconsistències i exemples que no funcionen. El suport dels tècnics de CECA molt bo. Poc temps per a contestat (llevat de si demanes en divendres, clar) i respostes clares i concises. Un deu! Amb la gent del BBVA el mateix, se coneix que els ha tocat bregar amb la documentació.ora

No acab d'entendre què costa mantenir la documentació actualitzada. Si ja no es fa servir un programa per a generar la firma, llavors es refà la documentació i se'n lleva la referència. Si s'incorpora un tag obligatori nou que s'ha d'enviar, llavors s'actualitzen els exemples.

Per si a algú més li serveix faig cinc cèntims del que m'he trobat i del que funciona a l'hora d'escriure aquest apunt.

Generació de la firma

La firma és diferent per l'enviament i per la resposta. En ambdós casos es fa servir el xifrat sha1

Per l'enviament hem de fer una concatenació formada per:

    clau_encriptació
    merchantid
    adquirerbin
    terminalid
    num_operacion
    importe
    tipomoneda
    exponente
    referencia
    SHA1
    url_ok
    url_nok

El que és cada cosa està a la documentació, aquí el que s'ha de saber és: SHA1 és una cadena de caràcters i és necessari posar-la. La referència apareix a la documetació, però NO s'ha de posar, millor dit, és una cadena buida. El número d'operació és el que identificarà la nostra operació i vendrà també a la confirmació així que convé (i és necessari) que sigui un codi numèric únic. L'import és un nombre on les dues posicions representen els decimals, així 12.23 passa a ser 1223. Damunt la concatenació s'ha de fer l'sha1 i passar-ho tot a una cadena hexadecimal i a minúscules. Per exemple:

 m = hashlib.sha1()
 m.update(s)
 valor = m.hexdigest().lower()

El calcul de la firma per la signatura de la resposta és diferent: clave_encriptacion merchantid adquirerbin terminalid num_operacion importe tipomoneda exponente referencia

Fixau-vos que no hi ha SHA1 aquí i com a cosa important l'import s'ha de posar tal com ve de la resposta, veureu que ve completat a zeros per l'esquerra. En aquest cas la referència sí que ve i està generada per la pasarel·la de pagament.

Enviament de les dades

 <form id="pago_form" action="{{url_ceca}}" method="post" accept-charset="utf-8" enctype="application/x-www-form-urlencoded">
 <input id="MerchantID" name="MerchantID" type="hidden" value="{{merchant_id}}"/>
 <input id="AcquirerBIN" name="AcquirerBIN" type="hidden" value="{{acquirer_bin}}"/>
 <input id="TerminalID" name="TerminalID" type="hidden" value="{{terminal_id}}"/>
<input id="firma" name="Firma" type="hidden" value="{{firma}}"/>
<input id="importe" name="Importe" type="hidden" value="{{importe}}"/>
<input name="TipoMoneda" type="hidden" value="978"/>
<input name="Exponente" type="hidden" value="2"/>
<input id="referencia" name="Referencia" type="hidden" value=""/>
<input name="URL_OK" type="hidden" value="{{url_ok}}"/>
<input name="URL_NOK" type="hidden" value="{{url_nok}}"/>
<input name="Pago_soportado" type="hidden" value="SSL"/>
<input name="Cifrado" type="hidden" value="SHA1"/>
<input name="Idioma" type="hidden" value="1"/>
<input name="Descripcion" type="{{descripcion}}"/>
<input type="submit" value="Comprar" />
</form>

Si mirau la documentació veureu que qualsevol parescut amb els exemples és pura coincidència. Tots els camps hi són però no hi ha cap exemple que funcioni amb els camps que hi ha. L'import ha d'estar en el mateix format que la firma, és a dir com a nombre sencer on les dues darreres xifres representen la part decimal.

És important notar que la referència viatja buida i que s'ha de posar el camp Cifrado. L'exemple està agafat d'una plantilla Django i preparat per a funcionar amb Euros com a moneda i en castellà com a idioma.

Rebre la resposta

CECA us enviarà la resposta en un POST a la url que l'indiqueu. Ja he comentat abans el tema de la firma. Convé comprovar sempre que la firma de l'operació calculada amb els paràmetres que ens ha donat CECA coincideix amb el que rebem, d'altra manera implicaria que algú altra està intentant validar l'operació de pagament i marcar-la com a correcta quan no seria així.

Si feis com nosaltres la integració fent servir Django heu de tenir en compte que la protecció CSRF evita que pugui enviar-se un post com el que necessitam, així que hem de marcar la url com a exempta d'aquesta protecció. No fa gaire gràcia, però com a protecció addicional convindrà configurar el firewall per a que sols accepti peticions cap a la url confirmació des de les IPs de CECA.

Com a consideracions importants heu de tenir en compte que CECA passarà l'import completat a zeros per l'esquerra i que heu de guardar la referència i el camp Num_aut, ja que són els dos camps que CECA us demanaria en cas de reclamació. El camp Num_operacion se correspon amb el nombre d'operació que nosaltres hem enviat i ens servirà per a localitzar i processar la venda.

Esper que la informació sigui d'utilitat.

0 comentaris, 0 trackbacks (URL)

Automatic translations of this post by Apertium

01 Jan 1970 12:00am GMT