Django 1.3 release notes

23 mars 2011

Välkommen till Django 1.3!

Django 1.3 har nästan ett år på nacken och innehåller en hel del nya funktioner och massor av buggfixar och förbättringar av befintliga funktioner. Dessa release notes täcker de nya funktionerna i 1.3, samt några :ref:``backwards-incompatible changes <backwards-incompatible-changes-1.3>` som du bör vara medveten om när du uppgraderar från Django 1.2 eller äldre versioner.

Översikt

Django 1.3 har mestadels fokuserat på att lösa mindre, långvariga funktionsförfrågningar, men det har inte hindrat några ganska betydande nya funktioner från att landa, inklusive:

• Ett ramverk för att skriva klassbaserade vyer.

• Inbyggt stöd för användning av Pythons loggningsfunktioner.

• Contrib stöd för enkel hantering av statiska filer.

• Djangos testramverk stöder nu (och levereras med en kopia av) the unittest2 library.

När det är möjligt introduceras nya funktioner på ett bakåtkompatibelt sätt enligt vår API-stabilitetspolicy policy. Som ett resultat av denna policy, Django 1.3 börjar deprecieringsprocessen för vissa funktioner.

Kompatibilitet med Python

Utgåvan av Django 1.2 var anmärkningsvärd för att ha den första förändringen i Djangos Python-kompatibilitetspolicy; före Django 1.2 stödde Django alla 2.x-versioner av Python från 2.3 och uppåt. Från och med Django 1.2 höjdes minimikravet till Python 2.4.

Django 1.3 fortsätter att stödja Python 2.4, men kommer att vara den sista Django-utgåveserien som gör det; från och med Django 1.4 kommer den minsta stödda Python-versionen att vara 2.5. Ett dokument som beskriver vår fullständiga tidslinje för utfasning av Python 2.x och övergång till Python 3.x kommer att publiceras strax efter lanseringen av Django 1.3.

Vad är nytt i Django 1.3

Klassbaserade åsikter

Django 1.3 lägger till ett ramverk som gör att du kan använda en klass som en vy. Detta innebär att du kan komponera en vy av en samling metoder som kan underklassas och åsidosättas för att tillhandahålla gemensamma vyer av data utan att behöva skriva för mycket kod.

Analoger till alla de gamla funktionsbaserade generiska vyerna har tagits fram, tillsammans med en helt generisk basklass för vyer som kan användas som grund för återanvändbara applikationer som enkelt kan utökas.

Se dokumentationen om klassbaserade generiska vyer för mer information. Det finns också ett dokument som hjälper dig att konvertera dina funktionsbaserade generiska vyer till klassbaserade vyer.

Loggning

Django 1.3 lägger till stöd på ramnivå för Pythons modul logging. Detta innebär att du nu enkelt kan konfigurera och kontrollera loggning som en del av ditt Django-projekt. Ett antal loggningshanterare och loggningsanrop har också lagts till i Djangos egen kod - framför allt hanteras felmeddelandena som skickas vid ett HTTP 500-serverfel nu som en loggningsaktivitet. Se dokumentationen om Djangos loggningsgränssnitt för mer information.

Utökad hantering av statiska filer

Django 1.3 levereras med en ny contrib-app - django.contrib.staticfiles - för att hjälpa utvecklare att hantera de statiska mediefiler (bilder, CSS, JavaScript, etc.) som behövs för att rendera en komplett webbsida.

I tidigare versioner av Django var det vanligt att placera statiska tillgångar i MEDIA_ROOT tillsammans med filer som laddats upp av användaren, och servera dem båda på MEDIA_URL. En del av syftet med att introducera appen staticfiles är att göra det enklare att hålla statiska filer åtskilda från användaruppladdade filer. Statiska tillgångar bör nu placeras i underkatalogerna static/ i dina appar eller i andra kataloger för statiska tillgångar som anges i STATICFILES_DIRS, och kommer att serveras på STATIC_URL.

Se referensdokumentationen för appen för mer information eller lär dig hur man hanterar statiska filer.

stöd för unittest2

Python 2.7 introducerade några stora förändringar i unittest-biblioteket och lade till några extremt användbara funktioner. För att säkerställa att alla Django-projekt kan dra nytta av dessa nya funktioner, levereras Django med en kopia av unittest2, en kopia av Python 2.7 unittest-biblioteket, bakåtporterat för Python 2.4-kompatibilitet.

För att komma åt detta bibliotek tillhandahåller Django modulaliaset django.utils.unittest. Om du använder Python 2.7, eller om du har installerat unittest2 lokalt, kommer Django att mappa aliaset till den installerade versionen av unittest-biblioteket. Annars kommer Django att använda sin egen medföljande version av unittest2.

För att utnyttja detta alias använder du helt enkelt:

from django.utils import unittest

där du historiskt sett skulle ha använt:

import unittest

Om du vill fortsätta att använda basbiblioteket unittest kan du göra det - du får bara inte tillgång till några av de nya fina unittest2-funktionerna.

Hantering av transaktionskontext

Användare av Python 2.5 och senare kan nu använda transaktionshanteringsfunktioner som kontexthanterare. Till exempel:

with transaction.autocommit():
    ...

Konfigurerbar delete-kaskad

ForeignKey och OneToOneField accepterar nu ett on_delete-argument för att anpassa beteendet när det refererade objektet raderas. Tidigare var borttagningar alltid kaskad; tillgängliga alternativ inkluderar nu set null, set default, set to any value, protect, eller do nothing.

För mer information, se on_delete dokumentation.

Kontextuella markörer och kommentarer för översättningsbara strängar

För översättningssträngar med tvetydig innebörd kan du nu använda funktionen pgettext för att ange strängens sammanhang.

Och om du bara vill lägga till lite information för översättare kan du också lägga till särskilda översättarkommentarer i källan.

Mer information finns i Kontextuella markörer och Kommentarer för översättare.

Förbättringar av inbyggda malltaggar

Ett antal förbättringar har gjorts av Djangos inbyggda malltaggar:

• Taggen include accepterar nu alternativet with, vilket gör att du kan ange kontextvariabler för den inkluderade mallen

• Taggen include accepterar nu alternativet only, vilket gör att du kan utesluta den aktuella kontexten från den inkluderade kontexten

• Med taggen with kan du nu definiera flera kontextvariabler i ett enda with-block.

• Taggen load accepterar nu argumentet from, vilket gör att du kan ladda en enskild tagg eller ett filter från ett bibliotek.

MallSvar

Det kan ibland vara fördelaktigt att låta dekoratorer eller mellanprogram ändra ett svar efter att det har konstruerats av vyn. Du kanske t.ex. vill ändra den mall som används eller lägga in ytterligare data i kontexten.

Du kan dock inte (enkelt) ändra innehållet i en grundläggande HttpResponse efter att den har konstruerats. För att övervinna denna begränsning lägger Django 1.3 till en ny TemplateResponse-klass. Till skillnad från grundläggande HttpResponse-objekt behåller TemplateResponse-objekt detaljerna i mallen och sammanhanget som tillhandahölls av vyn för att beräkna svaret. Det slutliga resultatet av svaret beräknas inte förrän det behövs, senare i svarsprocessen.

För mer information, se dokumentation om TemplateResponse-klassen.

Cachelagring av ändringar

Django 1.3 introducerar flera förbättringar av Djangos infrastruktur för cachning.

För det första stöder Django nu flera namngivna cacher. På samma sätt som Django 1.2 införde stöd för flera databasanslutningar, kan du med Django 1.3 använda den nya inställningen CACHES för att definiera flera namngivna cache-anslutningar.

För det andra har versioning, site-wide prefixing och transformation lagts till i cache-API:et.

För det tredje har :ref:cache key creation <using-vary-headers>` uppdaterats för att ta hänsyn till frågesträngen på ``GET-förfrågningar.

Slutligen har stöd för pylibmc lagts till i memcached cache backend.

För mer information, se dokumentation om cachelagring i Django.

Behörigheter för inaktiva användare

Om du tillhandahåller en anpassad auth-backend med upports_inactive_user inställd på True, kommer en inaktiv User-instans att kontrollera backend för behörigheter. Detta är användbart för att ytterligare centralisera behörighetshanteringen. Se authentication docs för mer information.

GeoDjango

GeoDjango-testsviten ingår nu när man kör Django-testsviten med runtests.py när man använder spatial databas backends.

MEDIA_URL och STATIC_URL måste sluta med ett snedstreck

Tidigare krävde inställningen MEDIA_URL bara ett efterföljande snedstreck om den innehöll ett suffix utöver domännamnet.

Ett efterföljande snedstreck är nu krävt för MEDIA_URL och den nya STATIC_URL-inställningen så länge det inte är tomt. Detta säkerställer att det finns ett konsekvent sätt att kombinera sökvägar i mallar.

Projektinställningar som anger någon av de båda inställningarna utan ett efterföljande snedstreck kommer nu att ge upphov till en PendingDeprecationWarning.

I Django 1.4 kommer samma tillstånd att ge upphov till ett DeprecationWarning, och i Django 1.5 kommer det att ge upphov till ett ImproperlyConfigured undantag.

Allt annat

Django 1.1 och 1.2 lade till många stora saker till Django, som stöd för flera databaser, modellvalidering och ett sessionsbaserat meddelanderamverk. Detta fokus på stora funktioner kom dock på bekostnad av många mindre funktioner.

För att kompensera för detta har fokus i utvecklingsprocessen för Django 1.3 legat på att lägga till många mindre, långvariga funktionsförfrågningar. Dessa inkluderar:

• Förbättrade verktyg för åtkomst till och manipulering av det aktuella Site-objektet i the sites framework.

• En :klass:`~django.test.RequestFactory` för att mocka förfrågningar i tester.

• Ett nytt testassertment – assertNumQueries() – gör det enklare att testa databasaktiviteten som är associerad med en vy.

• Stöd för uppslagningar som sträcker sig över relationer i admins list_filter.

• Stöd för HttpOnly-cookies.

• mail_admins() och mail_managers() har nu stöd för att enkelt bifoga HTML-innehåll till meddelanden.

• EmailMessage har nu stöd för CC.

• Felmeddelanden innehåller nu mer av detaljerna och formateringen på debug-serverns felsida.

• simple_tag() accepterar nu ett takes_context argument, vilket gör det enklare att skriva enkla malltaggar som kräver tillgång till mallkontext.

• En ny render() genväg – ett alternativ till django.shortcuts.render_to_response() som tillhandahåller en RequestContext som standard.

• Stöd för att kombinera F uttryck med timedelta värden vid hämtning eller uppdatering av databasvärden.

Bakåtkompatibla ändringar i 1.3

CSRF-validering gäller nu för AJAX-förfrågningar

Före Django 1.2.5 undantog Djangos CSRF-förhindrande system AJAX-förfrågningar från CSRF-verifiering; på grund av säkerhetsproblem som rapporterats till oss, är dock alla förfrågningar nu föremål för CSRF-verifiering. Se :doc:``Djangos CSRF-dokumentation </ref/csrf>` för detaljer om hur man hanterar CSRF-verifiering i AJAX-förfrågningar.

Begränsade filter i administratörsgränssnittet

Före Django 1.2.5 tillät Djangos administrativa gränssnitt filtrering på alla modellfält eller relationer - inte bara de som anges i list_filter - via manipulering av frågesträngar. På grund av säkerhetsproblem som rapporterats till oss måste dock argument för uppslagning av frågesträngar i admin vara för fält eller relationer som anges i list_filter eller date_hierarchy.

Om du tar bort en modell raderas inte tillhörande filer

I tidigare Django-versioner, när en modellinstans som innehåller en FileField raderades, tog FileField på sig att också radera filen från backend-lagringen. Detta öppnade dörren för flera dataförlustscenarier, inklusive rullade transaktioner och fält på olika modeller som refererar till samma fil. I Django 1.3, när en modell raderas, kommer FileField delete() metod inte att anropas. Om du behöver rensa bort föräldralösa filer måste du hantera det själv (t.ex. med ett anpassat hanteringskommando som kan köras manuellt eller schemaläggas för att köras regelbundet via t.ex. cron).

PasswordInput standard renderingsbeteende

Formwidgeten PasswordInput, avsedd för användning med formulärfält som representerar lösenord, accepterar ett boolean nyckelordsargument render_value som anger om dess data ska skickas tillbaka till webbläsaren när ett inskickat formulär visas med fel. Före Django 1.3 var detta argument som standard True, vilket innebär att det inskickade lösenordet skulle skickas tillbaka till webbläsaren som en del av formuläret. Utvecklare som ville lägga till lite extra säkerhet genom att utesluta det värdet från det återvisade formuläret kunde instansiera en PasswordInput som passerade render_value=False .

På grund av lösenordets känsliga natur tar dock Django 1.3 detta steg automatiskt; standardvärdet för render_value är nu False, och utvecklare som vill att lösenordsvärdet ska returneras till webbläsaren vid en inlämning med fel (det tidigare beteendet) måste nu uttryckligen ange detta. Till exempel:

class LoginForm(forms.Form):
    username = forms.CharField(max_length=100)
    password = forms.CharField(widget=forms.PasswordInput(render_value=True))

Rensbar standardwidget för FileField

Django 1.3 innehåller nu en ClearableFileInput-form widget utöver FileInput. ClearableFileInput renderas med en kryssruta för att rensa fältets värde (om fältet har ett värde och inte är obligatoriskt); FileInput tillhandahöll inget sätt att rensa en befintlig fil från en FileField.

ClearableFileInput är nu standardwidgeten för en FileField, så befintliga formulär som innehåller FileField utan att tilldela en anpassad widget måste ta hänsyn till den eventuella extra kryssrutan i den renderade formulärutmatningen.

Om du vill återgå till den tidigare renderingen (utan möjlighet att rensa FileField) använder du widgeten FileInput i stället för ClearableFileInput. Till exempel, i en ModelForm för en hypotetisk Document modell med en FileField med namnet document:

from django import forms
from myapp.models import Document


class DocumentForm(forms.ModelForm):
    class Meta:
        model = Document
        widgets = {"document": forms.FileInput}

Nytt index på databasens sessionstabell

Före Django 1.3 hade den databastabell som användes av databasbackend för appen sessions inget index på kolumnen expire_date. Som ett resultat skulle datumbaserade frågor på sessionstabellen - till exempel den fråga som behövs för att rensa gamla sessioner - vara mycket långsam om det fanns många sessioner.

Om du har ett befintligt projekt som använder databasens sessionsbackend behöver du inte göra något för att anpassa dig till den här ändringen. Du kan dock få en betydande prestandaförbättring om du manuellt lägger till det nya indexet i sessionstabellen. Den SQL som lägger till indexet kan hittas genom att köra adminkommandot sqlindexes:

python manage.py sqlindexes sessions

Inga fler fula ord

Django har historiskt tillhandahållit (och genomdrivit) en lista över svordomar. Kommentarsappen har tillämpat denna lista över svordomar och hindrat människor från att skicka in kommentarer som innehåller någon av dessa svordomar.

Tyvärr var den teknik som användes för att implementera denna lista över svordomar sorgligt naiv och utsatt för Scunthorpe-problemet. Att förbättra det inbyggda filtret för att åtgärda detta problem skulle kräva betydande insatser, och eftersom bearbetning av naturligt språk inte är den normala domänen för ett webbramverk har vi ”åtgärdat” problemet genom att göra listan över förbjudna ord till en tom lista.

Om du vill återställa det gamla beteendet lägger du helt enkelt till en PROFANITIES_LIST-inställning i din inställningsfil som innehåller de ord som du vill förbjuda (se commit som implementerade den här ändringen om du vill se listan över ord som historiskt sett var förbjudna). Om det är viktigt för dig att undvika svordomar gör du dock klokt i att försöka hitta en bättre och mindre naiv lösning på problemet.

Lokala smakförändringar

Django 1.3 introducerar följande bakåtkompatibla ändringar för lokala varianter:

• Kanada (ca) – Provinsen ”Newfoundland and Labrador” har fått sin provinskod uppdaterad till ”NL”, istället för den äldre ”NF”. Dessutom har Yukon Territory fått sin provinskod korrigerad till ”YT”, istället för ”YK”.

• Indonesien (id) – Provinsen ”Nanggroe Aceh Darussalam (NAD)” har tagits bort från provinslistan till förmån för den nya officiella beteckningen ”Aceh (ACE)”.

• United States of America (us) – Listan över ”states” som används av USStateField har utökats med postnummer för de väpnade styrkorna. Detta är bakåtkompatibelt om du förlitade dig på att USStateField inte inkluderade dem.

Uppdateringar av FormSet

I Django 1.3 har FormSet skapande beteende ändrats något. Historiskt sett gjorde klassen ingen skillnad mellan att inte få data och att få en tom ordbok. Detta var inkonsekvent med beteendet i andra delar av ramverket. Från och med 1.3 om du skickar in en tom ordbok kommer FormSet att skapa ett ValidationError.

Till exempel med en FormSet:

>>> class ArticleForm(Form):
...     title = CharField()
...     pub_date = DateField()
...
>>> ArticleFormSet = formset_factory(ArticleForm)

kommer följande kod att ge upphov till ett ValidationError:

>>> ArticleFormSet({})
Traceback (most recent call last):
...
ValidationError: [u'ManagementForm data is missing or has been tampered with']

om du behöver instansiera en tom FormSet, skicka inte in data eller använd None:

>>> formset = ArticleFormSet()
>>> formset = ArticleFormSet(data=None)

Callables i mallar

Tidigare anropades en callable i en mall automatiskt som en del av variabelupplösningsprocessen endast om den hämtades via attributuppslagning. Detta var en inkonsekvens som kunde leda till ett förvirrande och ohjälpsamt beteende:

>>> Template("{{ user.get_full_name }}").render(Context({"user": user}))
u'Joe Bloggs'
>>> Template("{{ full_name }}").render(Context({"full_name": user.get_full_name}))
u'<bound method User.get_full_name of <...

Detta har lösts i Django 1.3 - resultatet i båda fallen kommer att vara u'Joe Bloggs. Även om det tidigare beteendet inte var användbart för ett mallspråk som är utformat för webbdesigners, och aldrig avsiktligt stöddes, är det möjligt att vissa mallar kan brytas av denna ändring.

Användning av anpassad SQL för att ladda initiala data i tester

Django tillhandahåller en anpassad SQL-krok som ett sätt att injicera egenhändigt utformad SQL i databassynkroniseringsprocessen. En av de möjliga användningarna för denna anpassade SQL är att infoga data i din databas. Om din anpassade SQL innehåller INSERT-satser kommer dessa infogningar att utföras varje gång din databas synkroniseras. Detta inkluderar synkronisering av alla testdatabaser som skapas när du kör en testsvit.

I samband med testningen av Django 1.3 upptäcktes dock att denna funktion aldrig har fungerat helt som utlovat. När du använder databasbackends som inte stöder transaktioner, eller när du använder ett TransactionTestCase, kommer data som har infogats med anpassad SQL inte att vara synliga under testprocessen.

Tyvärr fanns det inget sätt att åtgärda detta problem utan att införa en bakåtkompatibilitet. I stället för att lämna SQL-införda initialdata i ett osäkert tillstånd, tillämpar Django nu policyn att data som infogats av anpassad SQL inte kommer att vara synliga under testning.

Den här ändringen påverkar endast testprocessen. Du kan fortfarande använda anpassad SQL för att ladda data till din produktionsdatabas som en del av syncdb-processen. Om du vill att data ska finnas under testförhållanden bör du antingen infoga dem med test fixtures eller med metoden setUp() i ditt testfall.

Ändrad prioritet för laddning av översättningar

Arbete har gjorts för att förenkla, rationalisera och korrekt dokumentera den algoritm som används av Django vid körning för att bygga översättningar från de olika översättningar som finns på disken, nämligen:

För översättningsbara bokstäver som finns i Python-kod och mallar ('django gettext-domän):

• Prioriteringarna för översättningar som ingår i applikationer som listas i inställningen INSTALLED_APPS ändrades. För att ge ett beteende som överensstämmer med andra delar av Django som också använder en sådan inställning (mallar, etc.) nu, när man bygger den översättning som kommer att göras tillgänglig, har de appar som listas först högre prioritet än de som listas senare.

• Nu är det möjligt att åsidosätta de översättningar som levereras med program genom att använda inställningen LOCALE_PATHS vars översättningar nu har högre prioritet än översättningarna i INSTALLED_APPS-program. Den relativa prioriteten mellan de värden som anges i denna inställning har också ändrats så att de sökvägar som anges först har högre prioritet än de som anges senare.

• Underkatalogen locale i katalogen som innehåller inställningarna, som vanligtvis sammanfaller med och är känd som projektkatalogen, kommer i den här utgåvan inte längre att användas som källa för översättningar. (Prioriteten för dessa översättningar ligger mellan översättningar av program och LOCALE_PATHS). Se avsnittet motsvarande borttagna funktioner i detta dokument.

För översättningsbara bokstäver som finns i JavaScript-kod ('djangojs gettext-domän):

• På samma sätt som översättningarna för 'django'-domänen: Åsidosättande av översättningar som levereras med applikationer genom att använda inställningen LOCALE_PATHS är nu möjligt även för denna domän. Dessa översättningar har högre prioritet än översättningarna av Python-paket som skickas till vyn javascript_catalog(). Sökvägar som listas först har högre prioritet än de som listas senare.

• Översättningar i underkatalogen locale i projektkatalogen har aldrig tagits med i beräkningen för JavaScript-översättningar och situationen är fortfarande densamma med tanke på att denna plats inte längre är aktuell.

Transaktionshantering

När du använder hanterade transaktioner - det vill säga allt annat än standardautocommit-läget - är det viktigt när en transaktion markeras som ”dirty”. Dirty-transaktioner bekräftas av dekoratorn commit_on_success eller django.middleware.transaction.TransactionMiddleware, och commit_manually tvingar dem att stängas uttryckligen; rena transaktioner ”får ett pass”, vilket innebär att de vanligtvis rullas tillbaka i slutet av en begäran när anslutningen stängs.

Fram till Django 1.3 markerades transaktioner endast som smutsiga när Django var medveten om en modifierande operation som utfördes i dem; det vill säga antingen sparades någon modell, någon bulkuppdatering eller radering utfördes, eller så kallade användaren uttryckligen transaction.set_dirty(). I Django 1.3 markeras en transaktion som dirty när någon databasoperation utförs.

Som ett resultat av den här ändringen behöver du inte längre uttryckligen ange att en transaktion är smutsig när du kör rå SQL eller använder en datamodifierande SELECT. Du behöver dock uttryckligen stänga alla skrivskyddade transaktioner som hanteras med hjälp av commit_manually(). Till exempel:

@transaction.commit_manually
def my_view(request, name):
    obj = get_object_or_404(MyObject, name__iexact=name)
    return render_to_response("template", {"object": obj})

Före Django 1.3 skulle detta fungera utan fel. Men under Django 1.3 kommer detta att ge upphov till ett TransactionManagementError eftersom läsoperationen som hämtar MyObject-instansen lämnar transaktionen i ett smutsigt tillstånd.

Ingen återställning av lösenord för inaktiva användare

Före Django 1.3 kunde inaktiva användare begära ett e-postmeddelande om återställning av lösenord och återställa sitt lösenord. I Django 1.3 kommer inaktiva användare att få samma meddelande som ett icke-existerande konto.

Lösenordsåterställningsvyn accepterar nu from_email

Vyn django.contrib.auth.views.password_reset() accepterar nu en from_email-parameter, som skickas till password_reset_form save()-metoden som ett nyckelordsargument. Om du använder den här vyn med ett anpassat formulär för återställning av lösenord måste du se till att formulärets save()-metod accepterar det här nyckelordsargumentet.

Funktioner som inte längre är aktuella i 1.3

Django 1.3 tar bort vissa funktioner från tidigare utgåvor. Dessa funktioner stöds fortfarande, men kommer gradvis att fasas ut under de kommande utgivningscyklerna.

Kod som utnyttjar någon av funktionerna nedan kommer att ge upphov till en PendingDeprecationWarning i Django 1.3. Denna varning är tyst som standard, men kan aktiveras med Pythons modul warnings eller genom att köra Python med flaggan -Wd eller -Wall.

I Django 1.4 kommer dessa varningar att bli en DeprecationWarning, som inte är tyst. I Django 1.5 kommer stödet för dessa funktioner att tas bort helt och hållet.

Se även

För mer information, se dokumentationen Djangos releaseprocess och vår deprecation tidslinje.

stöd för mod_python

Biblioteket mod_python har inte haft en release sedan 2007 eller en commit sedan 2008. Styrelsen för Apache Foundation röstade för att ta bort mod_python från uppsättningen aktiva projekt i dess versionshanteringsarkiv och dess huvudutvecklare har flyttat alla sina ansträngningar till den lättare, smalare, stabilare och mer flexibla mod_wsgi backend.

Om du för närvarande använder begäranhanteraren mod_python bör du distribuera om dina Django-projekt med hjälp av en annan begäranhanterare. mod_wsgi är den begäranhanterare som rekommenderas av Django-projektet, men FastCGI stöds också. Stöd för mod_python-distribution kommer att tas bort i Django 1.5.

Funktionsbaserade generiska vyer

Som ett resultat av införandet av klassbaserade generiska vyer har de funktionsbaserade generiska vyerna som tillhandahålls av Django utgått. Följande moduler och de vyer de innehåller har utgått:

• django.views.generic.create_update

• django.views.generic.date_based django.views.generic.date_based

• django.views.generic.list_detail

• django.views.generic.simple

Testa attributet template för klientsvar

Djangos test client returnerar Response-objekt annoterade med extra testinformation. I Django-versioner före 1.3 inkluderade detta ett template-attribut som innehöll information om mallar som användes för att generera svaret: antingen None, ett enda Template-objekt eller en lista över Template-objekt. Denna inkonsekvens i returvärden (ibland en lista, ibland inte) gjorde attributet svårt att arbeta med.

I Django 1.3 är attributet template avskrivet till förmån för ett nytt templates-attribut, som alltid är en lista, även om den bara har ett enda element eller inga element.

DjangoTestRunner

Som ett resultat av införandet av stöd för unittest2, har funktionerna i django.test.simple.DjangoTestRunner (inklusive fail-fast och Ctrl-C testavslut) blivit överflödiga. Med tanke på denna redundans har DjangoTestRunner förvandlats till en tom platshållarklass och kommer att tas bort helt i Django 1.5.

Ändringar av url och `ssi

De flesta malltaggar tillåter dig att skicka in antingen konstanter eller variabler som argument - till exempel:

{% extends "base.html" %}

kan du ange en basmall som en konstant, men om du har en kontextvariabel templ som innehåller värdet base.html:

{% extends templ %}

är också lagligt.

På grund av en historisk tillfällighet är dock url och ssi olika. Dessa taggar använder den andra, citatlösa syntaxen, men tolkar argumentet som en konstant. Det innebär att det inte är möjligt att använda en kontextvariabel som mål för en url- och ssi-tagg.

Django 1.3 markerar starten på processen att rätta till denna historiska olycka. Django 1.3 lägger till ett nytt mallbibliotek - future - som tillhandahåller alternativa implementationer av malltaggarna url och `ssi. Detta future-bibliotek implementerar ett beteende som gör hanteringen av det första argumentet konsekvent med hanteringen av alla andra variabler. Så, en befintlig mall som innehåller:

{% url sample %}

bör ersättas med:

{% load url from future %}
{% url 'sample' %}

De taggar som implementerar det gamla beteendet har utgått och i Django 1.5 kommer det gamla beteendet att ersättas med det nya beteendet. För att säkerställa kompatibilitet med framtida versioner av Django bör befintliga mallar ändras så att de använder de nya future-biblioteken och syntaxen.

Ändringar av inloggningsmetoderna för administratören

I den tidigare versionen definierade admin-appen inloggningsmetoder på flera platser och ignorerade den nästan identiska implementeringen i den redan använda auth-appen. En bieffekt av denna duplicering var att ändringarna som gjordes i r12634 för att stödja en bredare uppsättning tecken för användarnamn inte antogs.

Denna utgåva refaktoriserar admins inloggningsmekanism för att använda en underklass av AuthenticationForm istället för en manuell formulärvalidering. Den tidigare odokumenterade metoden 'django.contrib.admin.sites.AdminSite.display_login_form' har tagits bort till förmån för ett nytt login_form-attribut.

hanteringskommandona reset och `sqlreset

Dessa kommandon har tagits ur bruk. Kommandona flush och sqlflush kan användas för att radera allt. Du kan också använda ALTER TABLE- eller DROP TABLE-satser manuellt.

GeoDjango

• Den funktionsbaserade :inställningen:`TEST_RUNNER` som tidigare användes för att köra GeoDjango-testsviten, django.contrib.gis.tests.run_gis_tests, utrangerades för den klassbaserade löparen, django.contrib.gis.tests.GeoDjangoTestSuiteRunner.

• Tidigare kunde anrop av transform() inte göra någonting när GDAL inte var tillgängligt. Nu genereras en GEOSException på rätt sätt för att indikera eventuell felaktig applikationskod. En varning utfärdas nu om transform() anropas när geometrins SRID är mindre än 0 eller None.

CZBirthNumberField.clean

Tidigare accepterade detta fälts clean()-metod ett andra argument, kön, som gjorde det möjligt att göra starkare valideringskontroller, men eftersom detta argument aldrig faktiskt kunde skickas från Django-formulärsmaskineriet är det nu i väntan på avskrivning.

CompatCookie

Tidigare exponerade django.http en odokumenterad CompatCookie-klass, som var en buggfixad omslag runt standardbibliotekets SimpleCookie. Eftersom korrigeringarna flyttas uppströms är detta nu föråldrat - du bör använda from django.http import SimpleCookie istället.

Inläsning av översättningar på *projektnivå

Denna utgåva av Django startar utfasningsprocessen för inkludering av översättningar som ligger under den så kallade projektsökvägen i översättningsbyggnadsprocessen som utförs vid körning. Inställningen LOCALE_PATHS kan användas för samma uppgift genom att lägga till filsystemets sökväg till en locale-katalog som innehåller översättningar på projektnivå till värdet för den inställningen.

Motivering för detta beslut:

• Projektsökvägen* har alltid varit ett löst definierat begrepp (den katalog som används för att hitta översättningar på projektnivå är faktiskt den katalog som innehåller inställningsmodulen) och det har skett en förändring i andra delar av ramverket så att den inte längre används som referens för placering av tillgångar under körning.

• Detektering av underkatalogen locale tenderar att misslyckas när distributionsscenariot är mer komplext än det grundläggande. t.ex. misslyckas det när inställningsmodulen är en katalog (ärende #10765).

• Det finns potentiella konstiga problem under utvecklings- och driftsättningstiden, som det faktum att underkatalogen project_dir/locale/ kan generera falska felmeddelanden när projektkatalogen läggs till i Python-sökvägen (manage.py runserver gör detta) och sedan krockar med den liknamnade standardbiblioteksmodulen, detta är ett typiskt varningsmeddelande:

  /usr/lib/python2.6/gettext.py:49: ImportWarning: Not importing directory '/path/to/project/locale': missing __init__.py.
  import locale, copy, os, re, struct, sys
  

• Den här platsen ingick inte i översättningsskapandeprocessen för JavaScript-litteraler. Denna depreciering tar bort sådan inkonsekvens.

PermWrapper flyttad till django.contrib.auth.context_processors

I Django 1.2 började vi processen med att ändra platsen för auth kontextprocessorn från django.core.context_processors till django.contrib.auth.context_processors. Stödklassen PermWrapper utelämnades dock av misstag från den migreringen. I Django 1.3 har klassen PermWrapper också flyttats till django.contrib.auth.context_processors, tillsammans med supportklassen PermLookupDict. De nya klasserna är funktionellt identiska med sina gamla versioner; endast modulens plats har ändrats.

Borttagning av XMLField

När Django först släpptes inkluderade Django en XMLField som utförde automatisk XML-validering för alla fältinmatningar. Denna valideringsfunktion har dock inte utförts sedan introduktionen av newforms, före 1.0-utgåvan. Som ett resultat är XMLField som det för närvarande implementeras funktionellt oskiljbart från en enkel TextField.

Av denna anledning har Django 1.3 påskyndat utfasningen av XMLField - istället för en utfasning i två releaser kommer XMLField att tas bort helt i Django 1.4.

Det är enkelt att uppdatera din kod för att tillgodose denna ändring - ersätt bara alla användningar av XMLField med TextField och ta bort nyckelordsargumentet schema_path (om det anges).