Open Source

Społeczność

Ta strona, odświeżana co godzinę, zbiera wpisy z blogów na tematy związane z Django

Django i pliki statyczne

Posted on Czerwiec 22, 2009 at 9:36 po południu by restlessbeing RSS

Konfiguracja statyki w Django opiera się na trzech wpisach w pliku settings.py. Są to definicje zmiennych: MEDIA_URL, MEDIA_ROOT i ADMIN_MEDIA_PREFIX. Wykorzystanie MEDIA_URL MEDIA_URL - adres URL, pod którym dostępne będą nasze pliki statyczne. Jest on wykorzystywany przy generowaniu adresów obrazków, arkuszy stylów itp. Przykładowe ustawienia: wartość domyślna: '' serwer deweloperski: MEDIA_URL='/static/ serwer produkcyjny: MEDIA_URL='http://static.restlessbeing.pl/media/ Przyjmijmy, że chcemy włączyć jakiś arkusz stylów do naszej strony html. W Django zrobimy to wpisując do szablonu strony: <link rel="stylesheet" type="text/css" href="{{ MEDIA_URL }}css/960/960.css" /> Jeśli ustawiliśmy MEDIA_URL na wartość: http://static.restless.being.pl/media/ to w kodzie naszej strony znajdzie się adres w postaci: http://static.restless.being.pl/media/css/960/960.css. Proste, prawda? Dociekliwy jednak zapyta - jak to się stało, że zmienna MEDIA_URL nagle pojawia się w szablonie? Odpowiedzią na to pytanie jest context processor django.core.context_processors.media, który umieszcza w kontekście szablonu tę zmienną, a który mamy domyślnie włączony. Oto jego kod: def media(request): """ Adds media-related context variables to the context. """ return {'MEDIA_URL': settings.MEDIA_URL} Podsumowując: MEDIA_URL odpowiada za adres, pod którym przeglądarka będzie szukała plików statycznych. Pozostaje więc tylko powiedzieć o tym naszemu serwerowi. Konfiguracja statyki na serwerze deweloperskim W przypadku serwera developerskiego mozemy serwować statykę korzystając z wbudowanego widoku django.views.static.serve. W tym celu wpisujemy w urls.py: if settings.DEBUG: urlpatterns += patterns("django.views", ...

Przeczytaj cały wpis »

Jak Pownce skalowało aplikacje Django

Posted on Czerwiec 21, 2009 at 10:09 rano by Biblioteka Pythona | Django RSS

Mike Malone w prezentacji opisuje różne metody skalowania aplikacji Django, jakie były stosowane w pownce.com, webowym komunikatorze zbudowanym z wykorzystaniem technologii Adobe AIR jak i Django.

Przeczytaj cały wpis »

Django - migracje z south

Posted on Czerwiec 20, 2009 at 12:46 po południu by Dominik Szopa RSS

South jest jedną z najlepszych aplikacji do prostego tworzenia migracji struktur baz danych w Django. Używam south'a od wersji 0.3. I muszę powiedzieć że jest to naprawdę dobre narzędzie. Ułatwia prace przy tworzeniu i rozwijaniu aplikacji w Django. Normalnie gdy tworzymy aplikacje w Django i korzystamy z syncdb, gdy chcemy zmienić strukturę bazy danych to musimy albo usunąć całą bazę i ponownie wykonać syncdb lub pisać "ręcznie" SQL który zmieni tą strukturę. Dodatkowym problemem jest jeżeli chcemy później te same zmiany struktury bazy danych wykonać na środowisku produkcyjnym. Przy większych projektach jest bardzo uciążliwe i zajmuje bardzo dużo czasu. Chciałbym opisać tutaj swoje doświadczenia z south 0.5 i pokazać jego możliwości. Zaczynamy: Tworzymy projekt który posiada dwie aplikacje books oraz authors. Modele z aplikacji authors: from django.db import models class Author(models.Model): name = models.CharField(max_length=30) Modele z aplikacji books: from django.db import models from southtest.authors.models import Author class Book(models.Model): name = models.CharField(max_length=30) author = models.ForeignKey(Author) Na początku musimy stworzyć pierwsze migracje dla tych dwóch aplikacji: ./manage.py startmigration books --initial + Added model 'books.Book' Created 0001_initial.py. ./manage.py startmigration authors --initial + Added model 'books.Book' Created 0001_initial.py. South automatycznie stworzy moduł migrations w katalogu aplikacji dla której tworzona jest migracja. W module tym ...

Przeczytaj cały wpis »

Django - migracje z south

Posted on Czerwiec 20, 2009 at 12:46 po południu by Dominik Szopa RSS

South jest jedną z najlepszych aplikacji do prostego tworzenia migracji struktur baz danych w Django. Używam south'a od wersji 0.3. I muszę powiedzieć że jest to naprawdę dobre narzędzie. Ułatwia prace przy tworzeniu i rozwijaniu aplikacji w Django. Normalnie gdy tworzymy aplikacje w Django i korzystamy z syncdb, gdy chcemy zmienić strukturę bazy danych to musimy albo usunąć całą bazę i ponownie wykonać syncdb lub pisać "ręcznie" SQL który zmieni tą strukturę. Dodatkowym problemem jest jeżeli chcemy później te same zmiany struktury bazy danych wykonać na środowisku produkcyjnym. Przy większych projektach jest bardzo uciążliwe i zajmuje bardzo dużo czasu. Chciałbym opisać tutaj swoje doświadczenia z south 0.5 i pokazać jego możliwości. Instalacja Jeżeli nie mamy jeszcze zainstalowanego south'a to instalujemy: easy_install south Zaczynamy: Tworzymy projekt który posiada dwie aplikacje books oraz authors. django-admin.py startproject southtest manage.py startapp books manage.py startapp authors Dopisujemy south oraz aplikacje books i authors do INSTALLED_APPS i robimy syncdb. South stworzy sobie tabele w której będzie trzymać historie migracji. Dopisujemy modele do aplikacji books i authors Modele z aplikacji authors: from django.db import models class Author(models.Model): name = models.CharField(max_length=30) Modele z aplikacji books: from django.db import models from southtest.authors.models import Author class Book(models.Model): name = models.CharField(max_length=30) ...

Przeczytaj cały wpis »

&quot;Django, Ćwiczenia&quot; już niebawem...

Posted on Czerwiec 19, 2009 at 3:19 po południu by Biblioteka Pythona | Django RSS

"Django, ćwiczenia", książka mojego autorstwa powinna niebawem trafić do sklepów (przynajmniej mam taką nadzieję :)). 88 stron to wprowadzenie do Django na bazie prostej aplikacji, rozbudowywanej krok po kroku prezentując kolejne elementy frameworka. Oprócz Django znajdzie się też trochę o GAE i Django + GAE.

Przeczytaj cały wpis »

Django i blogi

Posted on Czerwiec 14, 2009 at 9:06 po południu by restlessbeing RSS

Django jest moim ulubionym frameworkiem webowym. Jest proste a zarazem posiada ogromne możliwości. Jeśli do tego dołożyć to, że zostało w nim napisanych bardzo wiele rozmaitych aplikacji i projektów, z których możemy skorzystać tworząc własne projekty to otrzymujemy framework niemalże idealny :D Mówiąc o aplikacjach mam na myśli reużywalne aplikacje takie jak na przykład django-registration, natomiast przez projekt rozumiem to co z takich aplikacji się buduje żeby zaoferować użytkownikom końcowym jakąś funkcjonalność. Takim projektem jest na przykład własny blog. Blog - no właśnie - zachciało mi się własnego bloga, a ponieważ na pisanie bloga od zera nie miałem ochoty postanowiłem, że użyję czegoś gotowego. Powstało pytanie - czego? Użyłem najlepszego przyjaciela dewelopera, czyli wyszukiwarki, w celu wyszukania gotowych blogów (a raczej silników blogowych) w Django i otrzymałem naprawdę sporo wyników, z których najciekawsze to: Wpis z bloga pydanny'ego szukającego gotowego bloga do użycia przez jego firmę czyli... NASA Przegląd 20 blogów w Django Z tego wybrałem sobie do bliższego zapoznania się, które polegało na poczytaniu i uruchomieniu lub próbie uruchomienia danego bloga, następujące projekty: djangotechblog byteflow trespams Ella mightylemon django-diario djangotechblog odpadł jako pierwszy, a to dlatego, że nie mogłem go uruchomić. Wyrzucał jakieś błędy i szkoda mi było czasu ...

Przeczytaj cały wpis »

Django i blogi

Posted on Czerwiec 14, 2009 at 9:06 po południu by restlessbeing RSS

Django jest moim ulubionym frameworkiem webowym. Jest proste a zarazem posiada ogromne możliwości. Jeśli do tego dołożyć to, że zostało w nim napisanych bardzo wiele rozmaitych aplikacji i projektów, z których możemy skorzystać tworząc własne projekty to otrzymujemy framework niemalże idealny :D Mówiąc o aplikacjach mam na myśli reużywalne aplikacje takie jak na przykład django-registration, natomiast przez projekt rozumiem to co z takich aplikacji się buduje żeby zaoferować użytkownikom końcowym jakąś funkcjonalność. Takim projektem jest na przykład własny blog. Blog - no właśnie - zachciało mi się własnego bloga, a ponieważ na pisanie bloga od zera nie miałem ochoty postanowiłem, że użyję czegoś gotowego. Powstało pytanie - czego? Użyłem najlepszego przyjaciela dewelopera, czyli wyszukiwarki, w celu wyszukania gotowych blogów (a raczej silników blogowych) w Django i otrzymałem naprawdę sporo wyników, z których najciekawsze to: Wpis z bloga pydanny'ego szukającego gotowego bloga do użycia przez jego firmę czyli... NASA Przegląd 20 blogów w Django Z tego wybrałem sobie do bliższego zapoznania się, które polegało na poczytaniu i uruchomieniu lub próbie uruchomienia danego bloga, następujące projekty: djangotechblog byteflow trespams Ella mightylemon django-diario djangotechblog odpadł jako pierwszy, a to dlatego, że nie mogłem go uruchomić. Wyrzucał jakieś błędy i szkoda mi było czasu ...

Przeczytaj cały wpis »

Wszystko o URL dispatcher

Posted on Maj 25, 2009 at 3:15 po południu by Michał Dydecki RSS

Artykuł oparty na oryginalnej dokumentacji django do wersji svn. Jedną z cech django której nie da sie nie zauważyc są bardzo ładne i "czyste" adresy url .Świadczą one o wysokiej jakości i profesjonaliźmie naszje aplikacji. Nie potrzebujemy jakiegokolwiek rozszerzenia jak przy .php albo .cgi. Wstęp Żeby stworzyć URL-e dla aplikacji , musimy stworzyc moduł pythona nieoficjalnie nazywany URLconf ,  gdzie bedziemy trzymać całą konfiguracje URL-i dla naszej aplikacji.  Moduł ten odwzorowuje wzór adresu , przypisująć do niego dany widok . W związku z tym że jest to zwykły kod pythona moduł ten może byc tworzony dynamicznie ,czy odnosić sie do innych modułów. Jak django przetwarza zapytanie? Poniżej przedstawiony jest algorytm na jakiej podstawie django przetwarza zapytanie: 1.Podczas startu django wyznacza bazowy URLconf do użycia.Jest to moduł zdefiniowany w pliku settings.py pod zmienną ROOT_URLCONF. Wyjątek stanowi sytuacja gdy przychodzące zapytanie HttpRequest posiada atrybut urlconf , którego wartość zostępuje pierwotną wartość ROOT_URLCONF. 2.Django ładuje moduł i szuka zmiennej urlpatterns. Jest to lista Pythona , w formacie zwróconym przez funkcję patterns ( importowanym z django.conf.urls.defaults.patterns() ). 3.Django sprawdza po kolei wszystkie adresy wpisane do URLconfa ( względem zapytania ) , i zatrzymuje się na pierwszym który bedzie pasował do zapytania. 4.Gdy zapytanie pasuje ...

Przeczytaj cały wpis »

ping_google() w akcji

Posted on Maj 21, 2009 at 6:15 po południu by Michał Dydecki RSS

Jak wiadomo google sprawdza nasze strony co jakiś czas , dlatego uaktualnienia dla szukających informacji w wyszukiwarce docierają z pewnym opóźnieniem. Co w sytuacji ja chce juz?? Twórcy django pomyślili również i o takich sytauacjach. Zasada działania jest bardzo prosta. Struktura naszej strony jest dostepna poprzez sitemape , która wiadomo że przy każdej aktualizacji strony zmienia się , podając wyszukiwarce aktualną informację o stronie. Wszystko wygląda oka gdyby nie to że musimy czekać aż wyszukiwarka trafi na naszą strone i zobaczy że jest coś nowego. Ping_google() własnie służy do tego żeby nie czekać , tylko powiedzieć  google że własnie na stronie coś sie zmieniło i żeby wpadł na chwile zobaczyć co. Funkcje wywołujemy w podczas wykonywania metody safe() , czyli wtedy gdy do naszej bazy danych wskakuje cos nowego (artykuł ,news itd , to co indexujemy w sitemapie ). Poniżej prosty przykład: from django.db import modelsfrom django.contrib.sitemaps import ping_googleclass News(models.Model):     LIVE_STATUS = 1     DRAFT_STATUS = 2     HIDDEN_STATUS = 3      STATUS_CHOICES = (     (LIVE_STATUS , 'Live'),     (DRAFT_STATUS , 'Draft'),     (HIDDEN_STATUS , 'Hidden'),     )     title = models.CharField(max_length=255 , verbose_name = "Title")     slug = models.SlugField(max_length = 255)     body = models.TextField()     status = models.IntegerField(choices = STATUS_CHOICES , default = LIVE_STATUS)      def __unicode__(self):         ...

Przeczytaj cały wpis »

Modele w django - cz.1

Posted on Maj 16, 2009 at 7:16 po południu by Michał Dydecki RSS

Modele w django są odwzorowaniem tabel i relacji w bazie danych. Generalnie każdy model odnosi się do pojedyńczej tabeli w bazie danych. - Kazdy model jest podklasą dziedziczącą po django.db.models.Model. - Każdy atrybut klasy reprezentuje jedno pole w bazie danych. Ok , więc zaczynamy od małego przykładu: class MojeFilmy(models.Model):     tytul = models.CharField("Tytuł",max_length = 100)     gatunek = models.CharField("Gatunek filmu" , max_length = 100) Stworzyliśmy prosty model opisujący kolekcje filmów , posiadający pola tytuł oraz gatunek . Pola te nie moga byc puste . Django utworzy nam tabele o nazwie myapp_mojefilmy ( nazwę można nadpisać , ale zostaniemy na razie przy defaultowej ). CREATE TABLE myapp_mojefilmy ( "id" serial NOT NULL PRIMARY KEY, "tytul" varchar(100) NOT NULL, "gatunek" varchar(100) NOT NULL); By użyć naszego modelu , wystarczy ze dodamy naszą aplikację do pliku settings.py i wykonamy polecenie python manage.py syncdb , które i ile nie popełniliśmy żadnego błędu powinno nam wygenerowac wyżej zdefiniowaną tabelę w bazie danych. Opcje pól Każde pole może przyjmować pewne parametry bądź ich wymagac  ( tak jak pole Char Field wymaga max_length ). Poniżej znajduje się lista parametrów dostepnych dla każdego pola (uniwersalnych) : - null -  Jeżeli zdefiniujemy jak True django wprowadzi pustą wartość do bazy danych. ...

Przeczytaj cały wpis »

Modele w django - cz.1

Posted on Maj 16, 2009 at 7:16 po południu by Michał Dydecki RSS

Modele w django są odwzorowaniem tabel i relacji w bazie danych. Generalnie każdy model odnosi się do pojedyńczej tabeli w bazie danych. - Kazdy model jest podklasą dziedziczącą po django.db.models.Model. - Każdy atrybut klasy reprezentuje jedno pole w bazie danych. Ok , więc zaczynamy od małego przykładu: class MojeFilmy(models.Model):     tytul = models.CharField("Tytuł",max_length = 100)     gatunek = models.CharField("Gatunek filmu" , max_length = 100) Stworzyliśmy prosty model opisujący kolekcje filmów , posiadający pola tytuł oraz gatunek . Pola te nie moga byc puste . Django utworzy nam tabele o nazwie myapp_mojefilmy ( nazwę można nadpisać , ale zostaniemy na razie przy defaultowej ). CREATE TABLE myapp_mojefilmy ( "id" serial NOT NULL PRIMARY KEY, "tytul" varchar(100) NOT NULL, "gatunek" varchar(100) NOT NULL); By użyć naszego modelu , wystarczy ze dodamy naszą aplikację do pliku settings.py i wykonamy polecenie python manage.py syncdb , które i ile nie popełniliśmy żadnego błędu powinno nam wygenerowac wyżej zdefiniowaną tabelę w bazie danych. Opcje pól Każde pole może przyjmować pewne parametry bądź ich wymagac  ( tak jak pole Char Field wymaga max_length ). Poniżej znajduje się lista parametrów dostepnych dla każdego pola (uniwersalnych) : - null -  Jeżeli zdefiniujemy jak True django wprowadzi pustą wartość do bazy danych. ...

Przeczytaj cały wpis »

Długi brak wpisów i...

Posted on Maj 12, 2009 at 7:14 po południu by Rafał Jońca RSS

Oj, długo nie było nowych wpisów, ale mam coś na swoje usprawiedliwienie. Byłem zajęty tworzeniem między innymi artykułu wprowadzającego do Django dla webhosting.pl. Mogę dodać, że nie będzie to jedyny akcent Djangowy w tym internetowym magazynie w najbliższym czasie.

Przeczytaj cały wpis »

System szablonów - cz.2

Posted on Maj 10, 2009 at 4:30 po południu by Michał Dydecki RSS

W pierwszej częsci opisane były tylko podstawowe filtry dostępne wszablonach django. Dzisiaj opisze dostępne tagi oraz bloki. {% extends "base.html" %} - Rozszerza bazowy szablon ( lokalizacja podawana względem scieżki ustawionej w settings.py o nazwie "TEMPLATE_DIR"  ). Extends może również jako parametr przyjmować zmienną. {% include "other/menu.html" %} - Ładuje inny szablon do bierzącego i renderuje . Jako parametr może przyjmować zmienna z nazwą szablonu. {% block content %} Zawartość bloku {% endblock %} - Definiuje nazwe oraz zawartość danego bloku. Typowe zastosowanie to utworzenie takiego bloku z szablonie bazowym ,  a następnie wpisanie do niego oppowiedniej treści w szablonie który dziedziczy po szablonie bazowym. Dla większej wygody i czytelności szablony możemy dodawać endblock content . {% load i18n %} -  Załadownie do szablonu customowch tagów i filtrów dostępnych z danej bibliotek. Jeżeli w szablonie  "rodzicu" zadeklarujemy używanie danej biblioteki , szablon "dziecko" nie będzie miał dostepu do tagów i filtórw udostepnianych przez bibliotekę , dlatego w każdym szablonie dziedziczącym musimy również zdelkarować jej używanie. {% comment %}  Tu zamieszczamy komentarz {% endcomment %} -  Blok komentarza , żadna filozofia :). Pętla for: Wykonuję sie dla każdego elementu telefony. Czyli jeżeli mamy telefon1, telefon2 i telefon3 to zostanie wykonana 3 ...

Przeczytaj cały wpis »

System szablonów - cz.2

Posted on Maj 10, 2009 at 4:30 po południu by Michał Dydecki RSS

W pierwszej częsci opisane były tylko podstawowe filtry dostępne wszablonach django. Dzisiaj opisze dostępne tagi oraz bloki. {% extends "base.html" %} - Rozszerza bazowy szablon ( lokalizacja podawana względem scieżki ustawionej w settings.py o nazwie "TEMPLATE_DIR"  ). Extends może również jako parametr przyjmować zmienną. {% include "other/menu.html" %} - Ładuje inny szablon do bierzącego i renderuje . Jako parametr może przyjmować zmienna z nazwą szablonu. {% block content %} Zawartość bloku {% endblock %} - Definiuje nazwe oraz zawartość danego bloku. Typowe zastosowanie to utworzenie takiego bloku z szablonie bazowym ,  a następnie wpisanie do niego oppowiedniej treści w szablonie który dziedziczy po szablonie bazowym. Dla większej wygody i czytelności szablony możemy dodawać endblock content . {% load i18n %} -  Załadownie do szablonu customowch tagów i filtrów dostępnych z danej bibliotek. Jeżeli w szablonie  "rodzicu" zadeklarujemy używanie danej biblioteki , szablon "dziecko" nie będzie miał dostepu do tagów i filtórw udostepnianych przez bibliotekę , dlatego w każdym szablonie dziedziczącym musimy również zdelkarować jej używanie. {% comment %}  Tu zamieszczamy komentarz {% endcomment %} -  Blok komentarza , żadna filozofia :). Pętla for: Wykonuję sie dla każdego elementu telefony. Czyli jeżeli mamy telefon1, telefon2 i telefon3 to zostanie wykonana 3 ...

Przeczytaj cały wpis »

Definiowanie własnej metody save()

Posted on Maj 10, 2009 at 3:51 po południu by Michał Dydecki RSS

Metoda save() jest bardzo wygodna, jednak nie zawsze portrzebujemy tylko zapisać dane do bazy danych, lecz przed zapisaniem jeszcze coś z nimi zrobić. Przykład będzie trywialny , lecz chodzi o zobrazowanie zasady działania a nie przedstawianie super skomplikowanych rzeczy.Ok, więc do dzieła. Cel:stworzymy model składający sie z 3 pól name , text oraz text_upper , text_upper ma podaczas zapisu do bazy danych textu ma automatycznie zapisywać ten sam tekst tylko i wyłącznie dużymi literami. Model: from django.db import modelsclass TextUpper(models.Model):     name = models.CharField(max_length=255)     text = models.TextField()     text_upper = models.TextField(blank=True,editable=False)     def __unicode__(self):        return self.name     def save(self):        self.text_upper = self.text.upper()        super(TextUpper , self).save() I tyle , nic specjalnie trudnego."Super"  w pythonie odnosi się do klasy "rodzica" ,  do której moze dodawać bądź nadpisywać metody.

Przeczytaj cały wpis »