File diff 8684885ce1d9 → 379e3713e98f
docs/usage.rst
Show inline comments
 
new file 100644
 
.. _usage:
 

	
 
Usage
 
=====
 

	
 
Django Pydenticon is targeted at developers who wish to integrate an identicon
 
service in their Django projects. This chapter covers details on how an
 
identicon image is served, and how to integrate Django Pydenticon with other
 
applications.
 

	
 
Requesting identicons
 
---------------------
 

	
 
Identicon images are served through specially formatted URL. Whenever such URL
 
is submitted to Django Pydenticon application, an identicon image is created on
 
the fly.
 

	
 
The format of URL is ``/image/USER_DATA`` (relative to prefix URL assigned for
 
the application), where **USER_DATA** can be either in hashed or raw format. For
 
example, if Django Pydenticon application is reachable under ``/identicon/``,
 
identicon images can be requested using the following URLs:
 

	
 
* ``/identicon/image/somedataforhashing`` (raw data)
 
* ``/identicon/image/55d207ea47247b375dc1f495517f1332`` (pre-hashed data using
 
  *md5*)
 

	
 
.. warning::
 
   Keep in mind that if user data is submitted in pre-hashed form, the digest
 
   used should match with the digest configured for Django Pydenticon
 
   application. If digest does not match, the user data will be treated as any
 
   other user data, and it will be hashed once again.
 

	
 
URL instance namespaces
 
-----------------------
 

	
 
When resolving Django Pydenticon URLs, you should always use the URL names in
 
conjunction with application instance namespace.
 

	
 
Default application instance namespace is ``django_pydenticon``. Alternative
 
instance namespace can be specified by passing an (optional) argument to
 
``django_pydenticons.urls.get_patterns`` function.
 

	
 
For example, if default namespace is in use, the ``image`` URL would be
 
referenced as ``django_pydenticon:image`` in template tag ``url`` or function
 
call ``reverse``.
 

	
 
Generating identicon URLs in templates
 
--------------------------------------
 

	
 
If the data (whether raw or hashed) is available in template's context, an
 
identicon URL can be easily generated from within the template itself. This can
 
be achieved via ``url`` tag.
 

	
 
The URL for serving the identicons is named ``image``. It should always be
 
referenced in conjunction with an application instance namespace. The
 
application namespace defaults to ``django_pydenticon``, unless custom instance
 
namespace is passed when including the application URLs via
 
``django_pydenticon.urls.get_patterns``. In case of default namespace, that
 
means the URL would be referenced to as ``django_pydenticon:image``.
 

	
 
For example, let's say that it's necessary to show an identicon based on
 
username next to every comment. Related template snippet could look something
 
similar to the following::
 

	
 
  <ul>
 
  {% for comment in comments %}
 
    <li><img src="{% url 'django_pydenticon:image' comment.user.username %}"/>{{ comment.text }}</li>
 
  {% endfor %}
 
  </ul>
 

	
 
Generating identicon URLs programatically
 
-----------------------------------------
 

	
 
The URLs can be generated programtically, using Python code. Afterwards those
 
URLs can be either passed into template's rendering context, or used inside of
 
code for whatever other purposes. This is achieved by using the ``reverse`` URL
 
resolver (from ``django.core.urlresolvers``).
 

	
 
The URL for serving the identicons is named ``image``. It should always be
 
referenced in conjunction with an application instance namespace. The
 
application namespace defaults to ``django_pydenticon``, unless custom instance
 
namespace is passed when including the application URLs via
 
``django_pydenticon.urls.get_patterns``. In case of default namespace, that
 
means the URL would be referenced to as ``django_pydenticon:image``.
 

	
 
For example, let's say that it's necessary to show an identicon based on
 
username next to every comment. A special context variable could be passed into
 
template that would contain a list of comments, where each comment consists out
 
of identicon URL and comment itself. The Python code could look something
 
similar to::
 

	
 
  comments_context = []
 

	
 
  for comment in comments:
 
      identicon_url = reverse("django_pydenticon:image",
 
                              kwargs={"data": comment.user.username})
 
      comments_context.append({"text": comment.text,
 
                               "identicon_url": identicon_url})
 

	
 
  return render_to_response('myapp/comments.html',
 
                            {"comments": comments_context})
 

	
 
With the above context set-up, the ``myapp/comments.html`` template could
 
contain a snippet similar to::
 

	
 
  <ul>
 
  {% for comment in comments %}
 
    <li><img src="{{ comment.identicon_url }}"/>{{ comment.text }}</li>
 
  {% endfor %}
 
  </ul>
 

	
 
Overriding identicon parameters
 
-------------------------------
 

	
 
By default, the identicon generator will use parameters from project settings
 
for each request, falling back to application defaults if none were defined. In
 
addition to this static configuration, some parameters can be overridden per
 
request.
 

	
 
Per-request identicon generator parameters are passed via *GET* parameters. The
 
following *GET* parameters are available:
 

	
 
w
 
  Specifies the width of generated identicon image in pixels. Overrides the
 
  ``PYDENTICON_WIDTH`` configuration option.
 

	
 
h
 
  Specifies the height of generated identicon image in pixels. Overrides the
 
  ``PYDENTICON_HEIGHT`` configuration option.
 

	
 
f
 
  Specifies the format of generated identicon. Overrides the
 
  ``PYDENTICON_FORMAT`` configuration option.
 

	
 
p
 
  Specifies the padding that will be added to the generated identicon image. The
 
  value should be provided as 4 comma-separated positive integers.
 

	
 
i
 
  Specifies whether the background and foreground colour in generated identicon
 
  should be inverted (swapped) or not. The value passed for this parameter
 
  should be ``true`` or ``false``.
 

	
 
Passing an invalid parameter value via *GET* parameter will result in a
 
``SuspiciousOperation`` exception being raised.
 

	
 
For example, the following request would generate an identicon with width of
 
``320``, height of ``240``, format ``PNG``, padding (top, bottom, left, right)
 
of ``10, 10, 20, 20``, and with inverted foreground and background colours::
 

	
 
  /identicon/image/somedata?w=320&h=240&f=png&p=10,10,20,20&i=true