Assembla home | Assembla project page
 

Changeset 48

Show
Ignore:
Timestamp:
04/20/08 21:02:17 (6 months ago)
Author:
dominik.szopa
Message:

#18 przetlumaczony tutorial 04

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • django-docs/tutorial04.txt

    r3 r48  
    1 ===================================== 
    2 Writing your first Django app, part 4 
    3 ===================================== 
    4  
    5 This tutorial begins where `Tutorial 3`_ left off. We're continuing the Web-poll 
    6 application and will focus on simple form processing and cutting down our code. 
    7  
    8 Write a simple form 
    9 =================== 
    10  
    11 Let's update our poll detail template ("polls/detail.html") from the last 
    12 tutorial, so that the template contains an HTML ``<form>`` element:: 
     1========================================== 
     2Twoja pierwsza aplikacja w Django, część 4 
     3========================================== 
     4 
     5Ten tutorial zaczyna się tam gdzie kończy się `tutorial 3`_. 
     6Kontynuujemy tworzenie aplikacji ankiety, w tym tutorial'u skupimy się na prostym przetwarzaniu formularzy oraz upraszczaniu naszego kodu. 
     7 
     8Piszemy prosty formularz 
     9======================== 
     10 
     11Uaktualnijmy nasz szablon zwierający szczegóły ankiety ("polls/detail.html") z poprzedniego tutorial'a, tak aby szablon zawierał tag HTML'owy ``<form>``:: 
    1312 
    1413    <h1>{{ poll.question }}</h1> 
    …… 
    2120        <label for="choice{{ forloop.counter }}">{{ choice.choice }}</label><br /> 
    2221    {% endfor %} 
    23     <input type="submit" value="Vote" /> 
     22    <input type="submit" value="Głosuj" /> 
    2423    </form> 
    2524 
    26 A quick rundown: 
    27  
    28     * The above template displays a radio button for each poll choice. The 
    29       ``value`` of each radio button is the associated poll choice's ID. The 
    30       ``name`` of each radio button is ``"choice"``. That means, when somebody 
    31       selects one of the radio buttons and submits the form, it'll send the 
    32       POST data ``choice=3``. This is HTML Forms 101. 
    33  
    34     * We set the form's ``action`` to ``/polls/{{ poll.id }}/vote/``, and we 
    35       set ``method="post"``. Using ``method="post"`` (as opposed to 
    36       ``method="get"``) is very important, because the act of submitting this 
    37       form will alter data server-side. Whenever you create a form that alters 
    38       data server-side, use ``method="post"``. This tip isn't specific to 
    39       Django; it's just good Web development practice. 
    40  
    41 Now, let's create a Django view that handles the submitted data and does 
    42 something with it. Remember, in `Tutorial 3`_, we created a URLconf for the 
    43 polls application that includes this line:: 
     25Szybkie wyjaśnienie: 
     26 
     27    * Powyższy szablon wyświetla przycisk typu ``"radio button"`` dla każdego wyboru ankiety. Pole ``value`` dla każdego radio button'a jest skojarzone z ID obiektu ``choice``. Atrybut ``name`` każdego radio button'a jest ``"choice"``. To oznacza, że jak ktoś wybiera jeden z radio button'ów i submit'uje formularz form, to wysłane zostaną dane za pomocą POST'a ``choice=3``. 
     28 
     29    * Ustawiliśmy atrybut formularza ``action`` na ``/polls/{{ poll.id }}/vote/``, oraz ``method="post"``. Używanie ``method="post"`` (Przeciwne do ``method="get"``) jest bardzo ważne, ponieważ submit'owanie formularza zmieni dane po stronie serwera. Jeżeli kiedykolwiek tworzysz formularz który zmienia dane po stronie serwera, używaj ``method="post"``. Ta wskazówka nie ma nic wspólnego z Django, jest to dobra praktyka tworzenia aplikacji Web'owych. 
     30 
     31    * ``forloop.counter`` oznacza ile razy tag ``for`` wykonał kod wewnątrz pętli. Więcej informacji znajdziesz w `dokumentacji dla tag'a "for"`_. 
     32 
     33.. _dokumentacji dla tag'a "for": http://www.djangoproject.com/documentation/templates/#for 
     34 
     35Teraz stwórzmy widok Django który obsługuje submit'owane dane oraz coś z nimi robi. 
     36Pamiętaj, że w `tutorial'u nr 3`, stworzyliśmy URLconf dla aplikacji pools, która zawiera linie:: 
    4437 
    4538    (r'^(?P<poll_id>\d+)/vote/$', 'mysite.polls.views.vote'), 
    4639 
    47 So let's create a ``vote()`` function in ``mysite/polls/views.py``:: 
     40Stwórzmy więc funkcje ``vote()`` w ``mysite/polls/views.py``:: 
    4841 
    4942    from django.shortcuts import get_object_or_404, render_to_response 
    …… 
    5750            selected_choice = p.choice_set.get(pk=request.POST['choice']) 
    5851        except (KeyError, Choice.DoesNotExist): 
    59             # Redisplay the poll voting form. 
     52            # Pokaz ponownie formularz do glosowania. 
    6053            return render_to_response('polls/detail.html', { 
    6154                'poll': p, 
    62                 'error_message': "You didn't select a choice.", 
     55                'error_message': "Nie wybrales zadnej opcji", 
    6356            }) 
    6457        else: 
    6558            selected_choice.votes += 1 
    6659            selected_choice.save() 
    67             # Always return an HttpResponseRedirect after successfully dealing 
    68             # with POST data. This prevents data from being posted twice if a 
    69             # user hits the Back button. 
     60            # Zawsze zwróć HttpResponseRedirect po udanym obsłużeniu danych z POST'a 
     61            # To zapewnia że dane nie zostaną wysłane dwa razy jeżeli użytkownik wciśnie 
     62            # przycisk wstecz w przeglądarce. 
    7063            return HttpResponseRedirect(reverse('mysite.polls.views.results', args=(p.id,))) 
    7164 
    72 This code includes a few things we haven't covered yet in this tutorial: 
    73  
    74     * ``request.POST`` is a dictionary-like object that lets you access 
    75       submitted data by key name. In this case, ``request.POST['choice']`` 
    76       returns the ID of the selected choice, as a string. ``request.POST`` 
    77       values are always strings. 
    78  
    79       Note that Django also provides ``request.GET`` for accessing GET data 
    80       in the same way -- but we're explicitly using ``request.POST`` in our 
    81       code, to ensure that data is only altered via a POST call. 
    82  
    83     * ``request.POST['choice']`` will raise ``KeyError`` if ``choice`` wasn't 
    84       provided in POST data. The above code checks for ``KeyError`` and 
    85       redisplays the poll form with an error message if ``choice`` isn't given. 
    86  
    87     * After incrementing the choice count, the code returns an 
    88       ``HttpResponseRedirect`` rather than a normal ``HttpResponse``. 
    89       ``HttpResponseRedirect`` takes a single argument: the URL to which the 
    90       user will be redirected (see the following point for how we construct 
    91       the URL in this case). 
    92  
    93       As the Python comment above points out, you should always return an 
    94       ``HttpResponseRedirect`` after successfully dealing with POST data. This 
    95       tip isn't specific to Django; it's just good Web development practice. 
    96  
    97     * We are using the ``reverse()`` function in the ``HttpResponseRedirect`` 
    98       constructor in this example. This function helps avoid having to 
    99       hardcode a URL in the view function. It is given the name of the view 
    100       that we want to pass control to and the variable portion of the URL 
    101       pattern that points to that view. In this case, using the URLConf we set 
    102       up in Tutorial 3, this ``reverse()`` call will return a string like :: 
     65Ten kod zawiera kilka rzeczy o których jeszcze nie mowiliśmy w tym tutorial'u: 
     66 
     67    * ``request.POST`` jest obiektem ala słownik, który pozwala na dostęp do submitowanych danych po nazwie klucza.  
     68      W tym przypadku, ``request.POST['choice']`` 
     69      zwraca ID wybranej opcji ankiety, jako string. Wartości z ``request.POST`` 
     70      są zawsze string'ami. 
     71 
     72      Django także dostarcza ``request.GET`` do pobierania danych z GET'a  
     73      w ten sam sposób -- jednak używamy ``request.POST`` w naszym kodzie,  
     74      aby upewnić się, że dane są tylko zmienione przez wywołanie POST. 
     75 
     76    * ``request.POST['choice']`` rzuci wyjątek ``KeyError`` jeżeli ``choice``  
     77      nie byl dostarczony w danych z POST'a. 
     78      Powyższy kod oczekuje wyjątku ``KeyError`` oraz wyświetla ponownie 
     79      formularz ankiety z informacją o błędzie jeżeli ``choice`` nie był podany. 
     80 
     81    * Po zwiększeniu liczny głosów(``selected_choice.votes += 1``), kod zwraca ``HttpResponseRedirect``  
     82      zamiast zwykłego ``HttpResponse``. 
     83      ``HttpResponseRedirect`` przyjmuje pojedynczy argument: URL do którego  
     84      użytkownik zostanie przekierowany(zobacz kolejny punkt jak tworzymy URL w tym przypadku). 
     85 
     86      Zgodnie z komentarzem w kodzie, powinieneś zawsze zwracać ``HttpResponseRedirect``  
     87      po udanym obsłużeniu danych z POST'a. To nie jest specyficzne dla Django;  
     88      to po prostu dobra praktyka przy tworzeniu aplikacji web'owych. 
     89 
     90    * Używamy funkcji ``reverse()`` w przekierowaniu ``HttpResponseRedirect``. 
     91      Ta funkcja pomaga uniknąć sztywnego wpisywania URL'a w funkcji widoku.  
     92      Jako parametr przekazujemy nazwę widoku, który obsłuży nam zapytanie 
     93      oraz zmienne które są użyte w tym URL'u, które wskazują na ten widok. 
     94      W tym przypadku, używając URLConf który ustawiliśmy w tutorial'u 3,  
     95      wywołanie ``reverse()`` zwróci string podobny do tego:: 
    10396 
    10497        '/polls/3/results/' 
    10598 
    106       ... where the ``3`` is the value of ``p.id``. This redirected URL will 
    107       then call the ``'results'`` view to display the final page. Note that 
    108       you need to use the full name of the view here (including the prefix). 
    109  
    110       For more information about ``reverse()``, see the `URL dispatcher`_ 
    111       documentation. 
    112  
    113 As mentioned in Tutorial 3, ``request`` is a ``HTTPRequest`` object. For more 
    114 on ``HTTPRequest`` objects, see the `request and response documentation`_. 
    115  
    116 After somebody votes in a poll, the ``vote()`` view redirects to the results 
    117 page for the poll. Let's write that view:: 
     99      ... gdzie ``3`` jest wartością ``p.id``. Ten przekierowany URL wtedy 
     100      wywoła widok ``'results'``, który wyświetli końcową stronę. Zwróć uwagę,  
     101      że musisz tutaj użyć pełnej nazwy widoku(łącznie z prefiksem). 
     102 
     103      Więcej informacji o ``reverse()``, możesz znaleźć w `dokumentacji URL dispatcher'a`_. 
     104 
     105Jak wspomniano w tutorial'u 3, ``request`` jest obiektem ``HTTPRequest``. Więcej 
     106o obiektach ``HTTPRequest``, zobacz w `dokumentacji request and response`_. 
     107 
     108Po tym jak ktoś zagłosuje w ankiecie, widok ``vote()`` przekierowuje do strony z wynikami ankiety.  
     109Napiszmy widok:: 
    118110 
    119111    def results(request, poll_id): 
    …… 
    121113        return render_to_response('polls/results.html', {'poll': p}) 
    122114 
    123 This is almost exactly the same as the ``detail()`` view from `Tutorial 3`_. 
    124 The only difference is the template name. We'll fix this redundancy later. 
    125  
    126 Now, create a ``results.html`` template:: 
     115To jest prawie to samo co widok ``detail()`` z `tutorial'a nr 3`_. 
     116Jedyną różnicą jest nazwa szablonu. Poprawimy nadmiarowość później. 
     117 
     118Teraz stwórzmy szablon ``results.html``:: 
    127119 
    128120    <h1>{{ poll.question }}</h1> 
    …… 
    134126    </ul> 
    135127 
    136 Now, go to ``/polls/1/`` in your browser and vote in the poll. You should see a 
    137 results page that gets updated each time you vote. If you submit the form 
    138 without having chosen a choice, you should see the error message. 
    139  
    140 .. _request and response documentation: ../request_response/ 
    141 .. _URL dispatcher: ../url_dispatch#reverse 
    142  
    143 Use generic views: Less code is better 
    144 ====================================== 
    145  
    146 The ``detail()`` (from `Tutorial 3`_) and ``results()`` views are stupidly 
    147 simple -- and, as mentioned above, redundant. The ``index()`` view (also from 
    148 Tutorial 3), which displays a list of polls, is similar. 
    149  
    150 These views represent a common case of basic Web development: getting data from 
    151 the database according to a parameter passed in the URL, loading a template and 
    152 returning the rendered template. Because this is so common, Django provides a 
    153 shortcut, called the "generic views" system. 
    154  
    155 Generic views abstract common patterns to the point where you don't even need 
    156 to write Python code to write an app. 
    157  
    158 Let's convert our poll app to use the generic views system, so we can delete a 
    159 bunch of our own code. We'll just have to take a few steps to make the 
    160 conversion. 
    161  
    162 .. admonition:: Why the code-shuffle? 
    163  
    164     Generally, when writing a Django app, you'll evaluate whether generic views 
    165     are a good fit for your problem, and you'll use them from the beginning, 
    166     rather than refactoring your code halfway through. But this tutorial 
    167     intentionally has focused on writing the views "the hard way" until now, to 
    168     focus on core concepts. 
    169  
    170     You should know basic math before you start using a calculator. 
    171  
    172 First, open the polls/urls.py URLconf. It looks like this, according to the 
    173 tutorial so far:: 
     128Teraz otwórz ``/polls/1/`` w Twojej przeglądarce i zagłosój w ankiecie. Powinieneś zobaczyć stronę z wynikami, 
     129która jest uaktualniona za każdym razem jak głosujesz. Jeżeli submit'ujesz formularz bez wyboru na co głosujesz, 
     130powinieneś zobaczyć informacje o błędzie. 
     131 
     132.. _dokumentacji request and response: http://www.djangoproject.com/documentation/request_response/ 
     133.. _dokumentacji URL dispatcher'a: http://www.djangoproject.com/documentation/url_dispatch#reverse 
     134 
     135Użyj widoków generycznych: Im mniej kodu tym lepiej 
     136=================================================== 
     137 
     138Widoki ``detail()`` (z `tutorial'a nr 3`_) oraz ``results()`` są po prostu głupio  
     139proste -- i jak wspomniano wczesniej, nadmiarowe. Widok ``index()`` (także z  
     140tutorial'a nr 3), który wyświetla listę ankiet, jest podobny. 
     141 
     142Te widoki wykonują często powtarzane czynności w aplikacji www: pobranie danych  
     143z bazy danych zgodnie z parametrem przekazanym w URL'u, załadowaniem szablonu  
     144oraz zwróceniem przetworzonego szablonu. Ponieważ jest to tak często wykonywane, 
     145Django dostarcza skrót, zwany systemem "widoków generycznych". 
     146 
     147Widoki generyczne są abstrakcją do punktu w którym nie musisz nawet pisać  
     148kodu w Pythonie aby napisać aplikacje. 
     149 
     150Przeróbmy teraz naszą aplikacje ankiet aby używała systemu widoków generycznych, 
     151możemy więc skasować trochę kodu który napisaliśmy wcześniej. Musimy tylko wykonać 
     152kilka kroków aby dokonać tej konwersji. 
     153 
     154.. admonition:: Dlaczego zmieniamy w ten sposób kod ? 
     155 
     156    Generalnie, gdy piszesz aplikacje w Django, musisz ocenić czy widoki generyczne 
     157    są dobrym rozwiązaniem Twojego problemu, jeżeli tak, to będziesz ich używać od  
     158    samego początku, niż zmieniał kod na końcu pisania aplikacji. Jednak w tym tutorial'u 
     159    celowo skupiamy sie na pisaniu widoków od podstaw, aby pokazać podstawową koncepcje. 
     160 
     161    Powinieneś znać podstawy matematyki, aby móc korzystać z kalkulatora. 
     162 
     163Najpierw, otwórz plik ustawień URL'i polls/urls.py. Wygląda mniej więcej tak, zgodnie z tym co napisaliśmy do tej pory:: 
    174164 
    175165    from django.conf.urls.defaults import * 
    …… 
    182172    ) 
    183173 
    184 Change it like so:: 
     174Zmień go aby wyglądał tak:: 
    185175 
    186176    from django.conf.urls.defaults import * 
    …… 
    198188    ) 
    199189 
    200 We're using two generic views here: ``object_list`` and ``object_detail``. 
    201 Respectively, those two views abstract the concepts of "display a list of 
    202 objects" and "display a detail page for a particular type of object." 
    203  
    204     * Each generic view needs to know what data it will be acting upon. This 
    205       data is provided in a dictionary. The ``queryset`` key in this dictionary 
    206       points to the list of objects to be manipulated by the generic view. 
    207  
    208     * The ``object_detail`` generic view expects the ID value captured 
    209       from the URL to be called ``"object_id"``, so we've changed ``poll_id`` to 
    210       ``object_id`` for the generic views. 
    211  
    212     * We've added a name, ``poll_results``, to the results view so that we 
    213       have a way to refer to its URL later on (see the documentation about 
    214       `naming URL patterns`_ for information). We're also using the `url()`_ 
    215       function from ``django.conf.urls.defaults`` here. It's a good habit to 
    216       use ``url()`` when you are providing a pattern name like this. 
    217  
    218 .. _naming URL patterns: ../url_dispatch/#naming-url-patterns 
     190 
     191Używamy tutaj dwóch widoków generycznych: ``object_list`` oraz ``object_detail``. Te dwa widoki sa abstrakcja koncepcji "wyswietl liste obiektów" oraz "wyświetl stronę ze szczególami dla konkretnego typu obiektu". 
     192 
     193    * Każdy widok generyczny musi wiedzieć na jakich danych będzie działać. Te dane podaje się w słowniku. Klucz ``queryset`` w tym słowniku wskazuje na listę obiektów, które będa manipulowane przez generyczny widok. 
     194 
     195    * Widok generyczny ``object_detail`` oczekuje wartości ID przekazanej z URL'a, która nazywa się ``"object_id"``, wiec zmieniliśmy ``poll_id`` na ``object_id`` dla widoków generycznych. 
     196 
     197    * Dodaliśmy nazwę ``poll_results``, do widoku wyników, aby mieć możliwość odwołania się do jego URL'a w późniejszym czasie (zobacz dokumentacje na temat `konfigurowania wzorców URL'li`_ aby uzyskać więcej informacji).  
     198 
     199Używamy tutaj także  funkcji `url()`_ z pakietu ``django.conf.urls.defaults``. Jest to dobry zwyczaj 
     200    aby używać ``url()`` kiedy podaje wzorzec taki jak tutaj. 
     201 
     202.. _konfigurowania wzorców URL'li: ../url_dispatch/#naming-url-patterns 
    219203.. _url(): ../url_dispatch/#url 
    220204 
    221 By default, the ``object_detail`` generic view uses a template called 
    222 ``<app name>/<model name>_detail.html``. In our case, it'll use the template 
    223 ``"polls/poll_detail.html"``. Thus, rename your ``polls/detail.html`` template to 
    224 ``polls/poll_detail.html``, and change the ``render_to_response()`` line in 
    225 ``vote()``. 
    226  
    227 Similarly, the ``object_list`` generic view uses a template called 
    228 ``<app name>/<model name>_list.html``. Thus, rename ``polls/index.html`` to 
     205Domyśnie, widok generyczny ``object_detail`` używa szablonu nazywającego się  
     206``<nazwa aplikacji>/<nazwa modelu>_detail.html``. W naszym przypadku, używa szablonu 
     207``"polls/poll_detail.html"``. Zmień nazwę Twojego szablonu, ``polls/detail.html`` na 
     208``polls/poll_detail.html``, oraz zmień linie ``render_to_response()`` w ``vote()``. 
     209 
     210Podobnie, widok generyczny ``object_list`` używa szablonu nazwywającego się 
     211``<nazwa aplikacji>/<nazwa modelu>_list.html``. Także, zmień ``polls/index.html`` na 
    229212``polls/poll_list.html``. 
    230213 
    231 Because we have more than one entry in the URLconf that uses ``object_detail`` 
    232 for the polls app, we manually specify a template name for the results view: 
    233 ``template_name='polls/results.html'``. Otherwise, both views would use the same 
    234 template. Note that we use ``dict()`` to return an altered dictionary in place. 
    235  
    236 .. note:: ``all()`` is lazy 
    237  
    238     It might look a little frightening to see ``Poll.objects.all()`` being used 
    239     in a detail view which only needs one ``Poll`` object, but don't worry; 
    240     ``Poll.objects.all()`` is actually a special object called a ``QuerySet``, 
    241     which is "lazy" and doesn't hit your database until it absolutely has to. By 
    242     the time the database query happens, the ``object_detail`` generic view will 
    243     have narrowed its scope down to a single object, so the eventual query will 
    244     only select one row from the database.  
    245      
    246     If you'd like to know more about how that works, The Django database API 
    247     documentation `explains the lazy nature of QuerySet objects`_. 
    248  
    249 .. _explains the lazy nature of QuerySet objects: ../db-api/#querysets-are-lazy 
    250  
    251 In previous parts of the tutorial, the templates have been provided with a context 
    252 that contains the ``poll`` and ``latest_poll_list`` context variables. However, 
    253 the generic views provide the variables ``object`` and ``object_list`` as context. 
    254 Therefore, you need to change your templates to match the new context variables. 
    255 Go through your templates, and modify any reference to ``latest_poll_list`` to 
    256 ``object_list``, and change any reference to ``poll`` to ``object``. 
    257  
    258 You can now delete the ``index()``, ``detail()`` and ``results()`` views 
    259 from ``polls/views.py``. We don't need them anymore -- they have been replaced 
    260 by generic views. 
    261  
    262 The ``vote()`` view is still required. However, it must be modified to match 
    263 the new templates and context variables. Change the template call from 
    264 ``polls/detail.html`` to ``polls/poll_detail.html``, and pass ``object`` in the 
    265 context instead of ``poll``. 
    266  
    267 The last thing to do is fix the URL handling to account for the use of generic 
    268 views. In the vote view above, we used the ``reverse()`` function to avoid 
    269 hard-coding our URLs. Now that we've switched to a generic view, we'll need to 
    270 change the ``reverse()`` call to point back to our new generic view. We can't 
    271 simply use the view function anymore -- generic views can be (and are) used 
    272 multiple times -- but we can use the name we've given:: 
    273      
     214Ponieważ mamy więcej niż jeden wpis w URLconf który używa ``object_detail`` 
     215dla aplikacji polls, określamu recznie nazwę szablonu dla widoku wyników: 
     216``template_name='polls/results.html'``. W przeciwnym razie obydwa widoki używały by takiego samego szablonu.  
     217Zauwarz że używamy ``dict()`` aby zwrócić zmieniony słownik w tym miejscu. 
     218 
     219.. note:: ``all()`` jest leniwe 
     220 
     221    To może wyglądać troche przerażające, wywołanie ``Poll.objects.all()``  
     222    w widoku szczegółu, który tylko potrzebuje jednego obiektu ``Poll``, ale nie martw się; 
     223    ``Poll.objects.all()`` jest właściwie specjalnym obiektem nazwywanym ``QuerySet``, 
     224    który jest "leniwy" i nie wyciąga nic z bazy danych dopóki nie musi.  
     225    W czasie gdy wystąpi zapytanie do bazy, widok generyczny ``object_detail`` będzie miał 
     226    zmniejszony swój zasięg do pojedyńczego obiektu, więc ewentualne zapytanie  
     227    wybierze tylko jeden wiersz z bazy danych. 
     228 
     229    Jezeli chciałbys sie dowiedzieć jak to działa, dokumentacja Django na tamat API     
     230    bazy danych `wyjaśnia leniwą natrurę obiektów QuerySet`_. 
     231 
     232.. _wyjaśnia leniwą natrurę obiektów QuerySet: http://www.djangoproject.com/documentation/db-api/#querysets-are-lazy 
     233 
     234W porzednich częściach tego tutoriala, szablony miały podany kontkst który zawierał 
     235zmienne ``poll`` oraz ``latest_poll_list``. Jednak, widoki generyczne dostarczają  
     236zmienne ``object`` oraz ``object_list`` jako kontekst. 
     237Dlatego musisz zmienić Twoje szablony aby zawierały nowe zmienne kontekstu. 
     238Przejrzyj Twoje szablony, i zmodyfikuj każde odnieśienie do ``latest_poll_list`` na 
     239``object_list``, i zmien każde wystąpienie ``poll`` na ``object``. 
     240 
     241Możesz teraz usunąc widoki ``index()``, ``detail()`` oraz ``results()`` z  ``polls/views.py``.  
     242Już ich nie potrzebujemy -- zostały zastapione przez widoki generyczne. 
     243 
     244Widok ``vote()`` jest jednak ciągle potrzebny. Musi być jednakże zmodyfikowany,  
     245aby odpowiadał nowemu kontekstowi zmiennych. W wywołaniu ``render_to_response()``, zmień nazwę zmiennj 
     246``poll`` na ``object``. 
     247 
     248Ostania rzecz do zrobienia to naprawa obsługi URL'i z uwzględnieniem użycia widoków generycznych. 
     249W widoku vote powyrzej, użylismy funkcji ``reverse()``, aby uniknąć sztywnego wpisywania URL'i w widokach.  
     250Teraz przełączyliśmy się na widok generyczny, musimy zmienić wywołanie ``reverse()`` aby wskazywało spowrotem do naszego widoku generycznego. Nie możemy już poprostu użyć funkcji widoku -- widoki genryczne mogą (i są) używane wielokrotnie -- 
     251ale możemy użyć nazwy której użyliśmy:: 
     252 
    274253    return HttpResponseRedirect(reverse('poll_results', args=(p.id,))) 
    275254 
    276 Run the server, and use your new polling app based on generic views. 
    277  
    278 For full details on generic views, see the `generic views documentation`_. 
    279  
    280 .. _generic views documentation: ../generic_views/ 
    281  
    282 Coming soon 
    283 =========== 
    284  
    285 The tutorial ends here for the time being. But check back soon for the next 
    286 installments: 
    287  
    288     * Advanced form processing 
    289     * Using the RSS framework 
    290     * Using the cache framework 
    291     * Using the comments framework 
    292     * Advanced admin features: Permissions 
    293     * Advanced admin features: Custom JavaScript 
    294  
    295 In the meantime, you can read through the rest of the `Django documentation`_ 
    296 and start writing your own applications. 
    297  
    298 .. _Tutorial 3: ../tutorial03/ 
    299 .. _Django documentation: http://www.djangoproject.com/documentation/ 
     255Uruchom teraz server, i użyj Twojej nowej aplikacji ankiet opartej o widoki generyczne. 
     256 
     257Aby dowiedzieć się więcej o widokach generycznych, zobacz `dokumentacje widoków generycznych`_. 
     258 
     259.. _dokumentacje widoków generycznych: http://www.djangoproject.com/documentation/generic_views/ 
     260 
     261Już w krótce 
     262============ 
     263 
     264Ten tutorial kończy sie w tym momencie. Ale zobacz w krótce po nowe informacje: 
     265 
     266    * Zawansowane przetwarzanie formularzy 
     267    * Używanie framework'a RSS 
     268    * Używanie framework'a cache'owania 
     269    * Używanie framework'a komentarzy 
     270    * Zaawansowane funckje admina: uprawnienia 
     271    * Zaawansowane funckje admina: Własny Java script 
     272 
     273W między czasie możesz przeczytać resztę `dokumentacji Django`_ i zacząć pisać własne aplikacje. 
     274 
     275.. _tutorial'a nr 3: ../tutorial03/ 
     276.. _tutorial 3: ../tutorial03/ 
     277.. _dokumentacji Django: http://www.djangoproject.com/documentation/