"…mais ce serait peut-être l'une des plus grandes opportunités manquées de notre époque si le logiciel libre ne libérait rien d'autre que du code…"

Les vues génériques de Django

Posted by patrick sur juillet 20, 2007

Mon apprentissage de Django qui est parti du livre “Restful web services” de Léonard Richardson et Sam Ruby, Copyright 2007, O’Reilly Media, Inc., ISBN-13: 978-0-596-52926-0 m’a fait passer par les méthodes ‘GET’ et ‘POST’ et à cause de cette dernière méthode je suis bien obligé de m’intéresser à l’écriture de pages XHTML qui sont bien la chose la plus longue, pénible et ennuyeuse que l’on puisse imaginer !.

Heureusement, avec Django il y a les vues génériques et un coup de Google m’amène également sur le blog de David Larlet qui a consacré un article à ce sujet bien pénible🙂. Je vais essayer de détailler un peu plus ce puissant mécanisme.
Voir: -http://www.biologeek.com/journal/index.php/vues-generiques-heritage-et-templatetags-developpez-rapidement-avec-django

http://code.google.com/p/biologeek/(« Suite à la refonte du site, je trouve intéressant de pouvoir mettre les sources à la disposition de tous. Une solution maison à base de Trac pouvait soulever des problèmes pour la pérennité du dépôt alors c’est l’occasion de tester Google Code.Si jamais je regrette ce choix, je pourrais toujours en changer facilement étant donné que ça repose sur Subversion« )

svn checkout http://biologeek.googlecode.com/svn/trunk/ biologeek

Il faut lire également la page http://www.djangoproject.com/documentation/generic_views/ (« Writing Web applications can be monotonous, because we repeat certain patterns again and again. In Django, the most common of these patterns have been abstracted into “generic views” that let you quickly provide common views of an object without actually needing to write any Python code« )

Django’s generic views contain the following:

  • A set of views for doing list/detail interfaces (for example, Django’s documentation index and detail pages).
  • A set of views for year/month/day archive pages and associated detail and “latest” pages (for example, the Django weblog’s year, month, day, detail, and latest pages).
  • A set of views for creating, editing, and deleting objects.

All of these views are used by creating configuration dictionaries in your URLconf files and passing those dictionaries as the third member of the URLconf tuple for a given pattern. For example, here’s the URLconf for the simple weblog app that drives the blog on djangoproject.com:

Pour être plus clair, les vues génériques permettent de ne pas coder de code XHTML ce qui est une très bonne chose🙂. Le principe est de partir d’un objet défini par son modèle (défini dans /cygdrive/e/projets/pybookmarks/bookmarks/models.py) et de produire une vue générique à partir de ce modèle.

Vues génériques

On peut donc avoir des vues génériques:

  • « Simples »
    • $ python manage.py shell
      Python 2.5.1 (r251:54863, Jun 19 2007, 22:55:07)
      [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
      Type « help », « copyright », « credits » or « license » for more information.
      (InteractiveConsole)
      >>> from django.views.generic import simple
      >>> dir(simple)
      [‘HttpResponse’, ‘HttpResponseGone’, ‘HttpResponsePermanentRedirect’, ‘RequestContext’, ‘__builtins__’, ‘__doc__’, ‘__file__’, ‘__name__’, ‘direct_to_template‘, ‘loader’, ‘redirect_to‘, ‘render_to_response’]
      >>>
    • Exemples issus de biologeek (‘direct_to_template‘) (http://biologeek.googlecode.com/svn/trunk/urls.py)
      • ## Misc
        urlpatterns = patterns('django.views.generic.simple',
            (r'^$',             'direct_to_template', {'template': 'home.html'}),
            (r'^abonnement/$',  'direct_to_template', {'template': 'abonnement.html'}),
            (r'^contact/$',     'direct_to_template', {'template': 'contact.html'}),
            (r'^comments/',     include('django.contrib.comments.urls.comments')),
        )
    • Exemples issus de Django (‘redirect_to‘):
      • This example returns a 410 HTTP error for requests to /bar/:
        urlpatterns = patterns('django.views.generic.simple',
            ('^bar/$', 'redirect_to', {'url': None}),
        )
      • This example redirects from /foo/<id>/ to /bar/<id>/:
        urlpatterns = patterns('django.views.generic.simple',
            ('^foo/(?P<id>d+)/$', 'redirect_to', {'url': '/bar/%(id)s/'}),
        )
    • Exemples issus de Django ('direct_to_template'):
      • urlpatterns = patterns('django.views.generic.simple',
            (r'^foo/$',             'direct_to_template', {'template': 'foo_index.html'}),
            (r'^foo/(?P<id>d+)/$', 'direct_to_template', {'template': 'foo_detail.html'}),
        )
  • basées sur les dates
    • >>> from django.views.generic import date_based
      >>> dir(date_based)
      [‘DateTimeField’, ‘Http404’, ‘HttpResponse’, ‘ObjectDoesNotExist’, ‘RequestConte
      xt’, ‘__builtins__’, ‘__doc__’, ‘__file__’, ‘__name__’, ‘archive_day’, ‘archive_
      index’, ‘archive_month’, ‘archive_today’, ‘archive_week’, ‘archive_year’, ‘datetime’, ‘loader’, ‘object_detail’, ‘populate_xheaders’, ‘time’]
      >>>
    • grâce à la méthode django.views.generic.date_based
  • Liste/détails
    • >>> from django.views.generic import list_detail
      >>> dir(list_detail)
      [‘Http404’, ‘HttpResponse’, ‘InvalidPage’, ‘ObjectDoesNotExist’, ‘ObjectPaginator’, ‘RequestContext’, ‘__builtins__’, ‘__doc__’, ‘__file__’, ‘__name__’, ‘loader’, ‘object_detail’, ‘object_list’, ‘populate_xheaders’]
      >>>
  • Creation/Mise à jour
    • >>> from django.views.generic import create_update
      >>> dir(create_update)
      [‘FileField’, ‘Http404’, ‘HttpResponse’, ‘HttpResponseRedirect’, ‘ImproperlyConfigured’, ‘ObjectDoesNotExist’, ‘RequestContext’, ‘__builtins__’, ‘__doc__’, ‘__file__’, ‘__name__’, ‘create_object’, ‘delete_object’, ‘loader’, ‘oldforms’, ‘populate_xheaders’, ‘redirect_to_login’, ‘ugettext’, ‘update_object’]
      >>>

A suivre …

Voir:

http://www.djangoproject.com/documentation/newforms/(« django.newforms is Django’s fantastic new form-handling library. It’s a replacement for django.forms, the old form/manipulator/validation framework. This document explains how to use this new library »)

As with the django.forms (“manipulators”) system before it, django.newforms is intended to handle HTML form display, data processing (validation) and redisplay. It’s what you use if you want to perform server-side validation for an HTML form.

For example, if your Web site has a contact form that visitors can use to send you e-mail, you’d use this library to implement the display of the HTML form fields, along with the form validation. Any time you need to use an HTML <form>, you can use this library.

The library deals with these concepts:

  • Widget — A class that corresponds to an HTML form widget, e.g. <input type="text"> or <textarea>. This handles rendering of the widget as HTML.
  • Field — A class that is responsible for doing validation, e.g. an EmailField that makes sure its data is a valid e-mail address.
  • Form — A collection of fields that knows how to validate itself and display itself as HTML.

The library is decoupled from the other Django components, such as the database layer, views and templates. It relies only on Django settings, a couple of django.utils helper functions and Django’s internationalization hooks (but you’re not required to be using internationalization features to use this library).

http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/forms/tests.py

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

 
%d blogueurs aiment cette page :