Расширяем возможности приложения администрирования Django

Три способа доработки этого мощного приложения для соответствия вашим нуждам

Встроенная консоль администрирования, предоставляемая Django, является одним из ее самых главных достоинств. Что следует делать, если вам нужно настроить под себя больше, чем просто внешний вид консоли и несколько полей модели? Узнайте, как расширять приложение администрирования, не прибегая при этом к модификации исходного кода.

Лиза Дэли, разработчик ПО и владелец компании, Threepress Consulting Inc.

Photo of Liza DalyЛиза Дэли – разработчик программного обеспечения, специализируется на приложениях для издательской индустрии. Она была ведущим разработчиком многих крупных онлайновых продуктов издательств Oxford University Press, O'Reilly Media и других. В настоящее время Лиза является независимым консультантом и основателем проекта Threepress, цель которого – разработка электронных книг.



04.03.2011

Приложение администрирования Django

Платформа Django предлагает разработчикам множество функциональности: зрелую стандартную библиотеку, активное сообщество пользователей и все преимущества языка Python. В то время как другие инфраструктуры разработки Web-приложений могут предложить то же самое, уникальным достоинством Django является ее встроенное приложение администрирования - admin.

Приложение администрирования предоставляет "из коробки" расширенную функциональность для создания, чтения, обновления и удаления данных (Create-Read-Update-Delete или CRUD), избавляя разработчиков от часов повторяющейся работы. Это является важным как при разработке Web-приложений, потому что с его помощью программисты могут быстро изучать свои модели данных, так и при развертывании приложений, потому что не имеющие отношения к технике конечные пользователи могут пользоваться приложением администрирования для добавления и редактирования содержимого сайта.

В реальной жизни всегда требуется сделать какую-либо подгонку приложения. В документации Django приводится множество руководств по преобразованию базового вида приложения администрирования, а также Django предоставляет несколько простых методов для переопределения части поведения приложения. Но что, если вам нужно больше? С чего начать? В этой статье рассказывается о нескольких направлениях, в которых можно вести серьезную переработку приложения администрирования.

Краткий обзор приложения администрирования

Возможности приложения администрирования с настройками по умолчанию знакомы большинству разработчиков Django. Сделаем краткий обзор этих возможностей. Для начала включим приложение администрирования, отредактировав файл верхнего уровня urls.py, как показано в листинге 1.

Листинг 1. Включаем приложение администрирования в urls.py
from django.conf.urls.defaults import *

# Uncomment the next two lines to enable the admin:
from django.contrib import admin
admin.autodiscover()

urlpatterns = patterns('',
    # Uncomment the next line to enable the admin:
    (r'^admin/(.*)', admin.site.root),
)

Версии ПО, используемые в этой статье

  • Django V1.0.2
  • SQLite V3
  • Python V2.4–2.6 (Django пока не поддерживает Python 3)
  • IPython (для работы в консоли)

Механизм объектно-ориентированного отображения (Object-Relational Mapper или ORM) Django поддерживает множество баз данных, среди которых проще всех в установке sqlite3. Кроме того, sqlite3 поставляется в комплекте со многими ОС. Примеры из этой статьи должны работать с любой базой данных. С полным списком баз данных, поддерживаемых Django, можно ознакомиться в разделе Ресурсы.

Django предоставляет удобный способ настройки рабочего окружения с помощью команды python manage.py shell. Во всех примерах кода, приводимых в этой статье, предполагается, что окружение настраивается именно таким образом.

В терминах Django, в этой статье предполагается следующее:

  • Проект Django называется more_with_admin.
  • В проекте more_with_admin имеется приложение с именем examples.

Приложение examples моделирует простую, похожую на блог систему документов, каждый из которых может иметь комментарии. Все примеры работы в командной строке выполняются из корневой директории проекта more_with_admin.

Также необходимо добавить приложение django.contrib.admin в кортеж settings.INSTALLED_APPS.

Перед тем как двигаться дальше, всем, кто планирует серьезно дорабатывать приложение администрирования, рекомендуется ознакомиться с его исходным кодом. Если позволяет операционная система, может быть полезным создать в директории приложения ярлык или символическую ссылку на приложение администрирования.

Приложение администрирования живет внутри пакета Django. Если вы его установили с помощью setuptools, приложение администрирования должно находиться в директории site-packages/django/contrib/admin. Ниже приводится пример создания в директории проекта символической ссылки, указывающей на исходный код приложения администрирования Django. Вы можете воспользоваться этой ссылкой, изменив ее в соответствии с вашей операционной системой и местонахождением пакета Django.

$ ln -s /path/to/Python/install/site-packages/django/contrib/admin admin-source

Метод admin.autodiscover() пробегается по всем приложениям, указанным в кортеже settings.INSTALLED_APPS и ищет файл с именем admin.py. Он обычно находится на верхнем уровне директории приложения, на одном уровне с models.py.

Приложению examples нужен файл models.py, показанный в листинге 2. Соответствующий файл admin.py приведен ниже.

Листинг 2. Пример файла models.py для этого приложения
from django.db import models

class Document(models.Model):
    '''
    документ - это запись в блоге или на wiki-страничке, 
    имеющая некоторое текстовое содержимое
    '''
    name = models.CharField(max_length=255)
    text = models.TextField()
    
    def __unicode__(self):
        return self.name

class Comment(models.Model):
    '''комментарий  - это некоторый текст, относящийся  к данному документу'''
    document = models.ForeignKey(Document, related_name='comments')
    text = models.TextField()

Теперь можно запустить сервер разработки Django и взглянуть на приложение администрирования:

python manage.py runserver

По умолчанию приложение администрирования доступно по адресу http://localhost:8000/admin/. Зарегистрировавшись, вы увидите главный экран администратора, показанный на рисунке 1.

Рисунок 1. Главный экран администратора Django
Basic Django admin screen

Изменение кода в admin.py

В отличие от остальных файлов приложения Django, если вы при работающем Web-сервере разработки Django вносите изменения в admin.py, то для вступления изменений в силу, возможно, придется вручную перезапустить сервер.

Заметьте, что модели приложения еще недоступны, потому что мы не создали файл admin.py. В листинге 3 показан код, который даст возможность работать с моделями через приложение администрирования.

Листинг 3. Пример файла admin.py
from django.contrib import admin
from more_with_admin.examples import models

class DocumentAdmin(admin.ModelAdmin):
    pass

class CommentAdmin(admin.ModelAdmin):
    pass

admin.site.register(models.Document, DocumentAdmin)
admin.site.register(models.Comment, CommentAdmin)

После перезагрузки основной страницы приложения администрирования, как показано на рисунке 2, новые модели становятся доступными для использования.

Рисунок 2. Администратор Django готов работать с пользовательскими моделями данных
Django admin screen with custom models

Доработка страниц моделей в приложении администрирования

Имена директорий в папках приложения администрирования

Заметьте, что я использую в именах моделей только символы в нижнем регистре. Это согласуется с тем, как работают обычные страницы администратора при генерации адресов URL. В Django эти дружественные для адресов URL имена называются "ленивыми" (slug) именами. Если вы не уверены в том, каким должно быть ленивое имя для определенной модели, перед созданием собственных директорий исследуйте приложение администрирования и посмотрите, какие имена появляются в URL-адресах.

Чтобы понять, как дорабатывать приложение администрирования не меняя исходного кода Django, важно помнить, что мы имеем дело с обычным приложением Django, таким же, как и все остальные. В первую очередь это означает, что к нему применима система наследования шаблонов Django.

В Django шаблоны проекта имеют больший приоритет по сравнению с системными шаблонами. Кроме того, перед обращением к шаблонам по умолчанию приложение администрирования пытается найти жестко закодированные шаблоны с именами, соответствующими каждой модели. Это предоставляет точку входа для доработки приложения.

Сначала отредактируем файл settings.py проекта, указав в нем директорию, в которой Django должен искать шаблоны (листинг 4).

Листинг 4. Добавляем в settings.py директории с шаблонами
TEMPLATE_DIRS = (
    "/path/to/project/more_with_admin/templates",
    "/path/to/project/more_with_admin/examples/templates",
)

Затем создадим в проекте следующие директории:

$ mkdir templates/admin/examples/document/
$ mkdir templates/admin/examples/comment/

Приложение администрирования Django сначала попытается найти шаблоны в директории с именем, совпадающим с названием вашего приложения (здесь examples), затем с названием моделей (document и comment) и только потом, в случае неудачи, будет использовать системные шаблоны для отображения страницы.

Переопределяем страницу добавления/удаления экземпляра модели

Для добавления и редактирования экземпляров модели приложение администрирования использует страницу change_form.html. Для начала создадим в директории templates/admin/examples/document/ страницу с именем change_form.html и поместим в нее следующую строку для наследования шаблона Django: {% extends "admin/change_form.html" %}.

Теперь все готово для доработки приложения. Уделите некоторое время знакомству с содержимым реального шаблона admin/change_form.html. Он довольно хорошо организован в блоки, которые можно переопределять, но в некоторых случаях доработка может потребовать "оптового" копирования блоков. Тем не менее, переопределение основанных на блоках шаблонов всегда предпочтительнее копирования страницы целиком.

Какого рода доработку можно сделать на странице добавления/редактирования? Допустим, мы хотим для каждого документа добавить предварительный просмотр пяти последних комментариев.

Сначала создадим тестовые данные(листинг 5).

Листинг 5. Создаем с помощью оболочки Django экземпляр модели Document с несколькими комментариями
$ python manage.py shell
In [1]: from examples import models
In [2]: d = models.Document.objects.create(name='Test document', 
                                           text='This is a test document.')
In [3]: for c in range(0, 10):
   ...:     models.Comment.objects.create(text='Comment number %s' % c, document=d)

Теперь в администраторе на странице списочного отображения показан один документ. Выберем этот документ, чтобы увидеть показанную на рисунке 3 страницу добавления/редактирования по умолчанию.

Рисунок 3. Стандартная страница добавления/редактирования для модели Document
Default add/edit page

Обратите внимание, что связанные с документом комментарии не показаны вообще. Обычно в приложении администрирования работа с взаимосвязанными моделями организуется посредством классов Inline. Эти мощные классы позволяют пользователям приложения администрирования редактировать или добавлять несколько взаимосвязанных моделей на одной странице. Чтобы увидеть классы Inline в действии, отредактируйте файл admin.py приложения так, как показано в листинге 6.

Листинг 6. Добавляем модель комментария к модели документов в приложении администрирования
from django.contrib import admin
from more_with_admin.examples import models

class CommentInline(admin.TabularInline):
    model = models.Comment

class DocumentAdmin(admin.ModelAdmin):
    inlines = [CommentInline,]

class CommentAdmin(admin.ModelAdmin):
    pass

admin.site.register(models.Document, DocumentAdmin)
admin.site.register(models.Comment, CommentAdmin)

На рисунке 4 показан новый вид страницы добавления/редактирования после добавления элемента управления TabularInline.

Рисунок 4. Страница добавления/удаления документа после добавления модели комментария в виде класса Inline
Document add/edit page after the comment model is added as Inline

Несомненно, это мощный способ доработки приложения администрирования, однако при нем результат может оказаться слишком громоздким, тогда как мы всего лишь хотели организовать быстрый просмотр комментариев.

В таком случае имеется два подхода. Первый подход – отредактировать HTML-виджеты, ассоциированные с классами inline, с помощью предоставляемого Django интерфейса администрирования виджетов. Виджеты в документации Django описаны весьма подробно. Другой подход - модифицировать шаблон добавления/редактирования напрямую. Этот подход наиболее полезен, если вы вообще не собираетесь использовать специфическую функциональность администратора.

Если вы не хотите разрешать редактировать комментарии (например, потому что пользователи не имеют для этого достаточных прав), но вы хотите, чтобы они могли видеть комментарии, можно модифицировать шаблон change_form.html.

Переменные, предоставляемые приложением администрирования Django

Чтобы добавить функциональность на страницу отображения экземпляра модели, нужно знать, какие данные приложения администрирования уже доступны. В таблице 1 дано описание двух переменных, которые вам в этом помогут.

Таблица 1. Переменные, необходимые для доработки шаблона приложения администрирования
ПеременнаяОписание
object_idЭто первичный ключ для редактируемого объекта. Если вы дорабатываете страницу экземпляра какой-либо одной модели (например, документа), это все, что вам понадобится.
content_type_idЕсли вы переопределяете страницы, работающие с множеством моделей, используйте эту переменную, чтобы опрашивать инфраструктуру ContentTypes для получения имени модели. Больше информации о типах содержимого можно получить в разделе Ресурсы.

Создаем тэг шаблона и включаем его в страницу приложения администрирования

Чтобы вывести комментарии, относящиеся к документу, необходим код, который нельзя вводить непосредственно в шаблон Django. Для таких случаев наилучшим решением является использование тэга шаблона. Сначала создадим директорию тэгов шаблонов и файл __init__.py в ней:

$ mkdir examples/templatetags/
$ touch examples/templatetags/__init__.py

Создадим новый файл с именем examples/templatetags/example_tags.py и добавим в него приведенный ниже код (листинг 7).

Листинг 7. Тэг шаблона для извлечения комментариев к документу с заданным ID
from django import template
from examples import models

register = template.Library()

@register.inclusion_tag('comments.html')
def display_comments(document_id):
    document = models.Document.objects.get(id__exact=document_id)
    comments = models.Comment.objects.filter(document=document)[0:5]
    return { 'comments': comments }

Так как здесь используется тэг включения шаблона, необходимо создать соответствующий шаблон: comments.html. Отредактируем файл examples/templates/comments.html file и поместим в него код, показанный в листинге 8.

Листинг 8. Шаблон для предварительного просмотра комментариев
{% for comment in comments %}
<blockquote>{{ comment.text }}</blockquote>
{% endfor %}

Теперь пришло время добавить это на страницу приложения администрирования. Закомментируйте в admin.py ссылки на CommentInline и сделайте в вашей локальной версии шаблона change_form.html изменения, показанные в листинге 9.

Листинг 9. Включение тэга шаблона в страницу добавления/редактирования
{% extends "admin/change_form.html" %}

{% load example_tags %}

{% block after_field_sets %}
  {% if object_id %}{% display_comments object_id %}{% endif %}
  {% endblock %}

Перед использованием object_id надо проверять, что он существует, так как шаблон change_form.html также используется для создания новых экземпляров модели, при котором object_id экземпляра еще не доступен. Блок after_field_sets – один из многих элементов, предоставляющих возможности для расширения приложения администрирования. Остальные подобные блоки можно найти в исходном коде страницы change_form.html.

На рисунке 5 показана обновленная форма.

Рисунок 5. Страница добавления/редактирования документа после добавления на нее собственного тэга шаблона
Document add/edit page after the custom template tag is included

Модифицируем поведение приложения администрирования

Как видите, одним только переопределением шаблонов можно добиться довольно многого. Но что, если мы хотим поменять само поведение приложения администрирования? Это можно сделать, подправив исходный код, но тогда вы будете ограничены только той версией Django, которую будете использовать на момент внесения исправлений.

Переопределяем методы в AdminModel

По умолчанию нажатие кнопки Save в приложении администрирования возвращает пользователя на страницу списочного отображения экземпляров модели. Обычно это всех устраивает, но что, если мы хотим переходить сразу на страницу предварительного просмотра объекта, находящуюся вне приложения администрирования? Это распространенное поведение в системах управления содержимым (content management system или CMS).

Метод get_absolute_url()

В листинге 10 предполагается, что класс Document был изменен и теперь включает в себя метод get_absolute_url(), который является рекомендуемым способом определения моделями Django своего канонического представления. Если метод определен, в администраторе Django на каждой странице этой модели также появляется полезная кнопка View on site.

Большая часть функциональности приложения администрирования реализована в классе admin.ModelAdmin. От этого класса наследуются объекты в admin.py. В нем имеется очень много публичных методов, которые можно переопределять. Определение этого класса можно посмотреть в файле admin-source/options.py.

Есть два способа поменять поведение кнопки Save: можно переопределить метод admin.ModelAdmin.response_add, отвечающий за само перенаправление после сохранения объекта, а также можно переопределить метод admin.ModelAdmin.change_view. Последний способ немного проще.

Листинг 10. Переопределяем страницу, на которую перенаправляются пользователи после сохранения документа
class DocumentAdmin(admin.ModelAdmin):

    def change_view(self, request, object_id, extra_context=None):

        result = super(DocumentAdmin, self).change_view(request, object_id, extra_context)

        document = models.Document.objects.get(id__exact=object_id)
        
        if not request.POST.has_key('_addanother') and 
              not request.POST.has_key('_continue'):
            result['Location'] = document.get_absolute_url()
        return result

Теперь, когда пользователь нажимает кнопку Save, он перенаправляется на страницу предварительного просмотра сохраненного документа, а не на страницу списочного отображения всех документов.

Добавление функциональности в приложение администрирования с помощью сигналов

Сигналы – это незаслуженно мало используемая функциональность Django, улучшающая модульность вашего кода. Сигналы определяют события, такие как сохранение модели или загрузку шаблона; функции из любого места проекта Django могут узнавать о событиях и отвечать на них. Это означает, что вы можете легко расширить поведение приложения, не изменяя приложение напрямую.

В приложении администрирования имеется функциональность, которую разработчики желают поменять особенно часто – это управление пользователями с помощью класса django.contrib.auth.models.User. Часто приложение администрирования является единственным местом, где добавляются или модифицируются пользователи Django, что делает сложной доработку под себя этого полезного класса.

Представим, что мы хотим, чтобы администратор сайта получал уведомление по электронной почте каждый раз при создании нового объекта класса User. Так как модель User напрямую недоступна в проекте, может показаться, что реализовать это можно либо создав класс-наследник User, либо каким-нибудь неявным методом, например с помощью создания некого фиктивного профиля для модификации.

В листинге 11 демонстрируется, как легко добавить функцию, выполняющуюся при каждом сохранении экземпляра класса User. Сигналы обычно добавляют в models.py.

Листинг 11. Использование сигналов Django для уведомления о создании новых пользователей
from django.db import models
from django.db.models import signals
from django.contrib.auth.models import User
from django.core.mail import send_mail

class Document(models.Model):
    [...]

class Comment(models.Model):
    [...]

def notify_admin(sender, instance, created, **kwargs):
    '''Оповещает администратора о добавлении нового пользователя.'''
    if created:
       subject = 'New user created'
       message = 'User %s was added' % instance.username
       from_addr = 'no-reply@example.com'
       recipient_list = ('admin@example.com',)
       send_mail(subject, message, from_addr, recipient_list)        

signals.post_save.connect(notify_admin, sender=User)

Сигнал post_save предоставляется Django, он генерируется каждый раз при создании или сохранении экземпляра модели. Метод connect() здесь принимает два аргумента: функцию обратного вызова (notify_admin) и аргумент sender, который сообщает о том, что эту функцию следует вызывать только при сохранении экземпляров модели User.

Внутрь функции обратного вызова сигнал post_save передает отправителя (класс модели), экземпляр этой модели и булево значение, обозначающее, был ли этот экземпляр только что создан. В этом примере метод посылает электронное сообщение только при создании нового экземпляра модели User; в противном случае не делается ничего.

В разделе Ресурсы можно ознакомиться со списком предоставляемых Django сигналов, а также с документацией по созданию собственных сигналов.


Более глубокие изменения: добавляем права строкового уровня

Почему blank=True?

Возможно, не сразу становится понятным, почему поле ForeignKey будет выставляться с флагом blank=True, когда оно не является текстовым полем. В данном случае это так потому, что приложение администрирования использует blank вместо null, чтобы определять, должно ли значение быть выставлено вручную перед сохранением модели.

Если задать только null=True или вообще ничего, то приложение администрирования Django перед сохранением заставит пользователя вручную выбрать значение "added by", хотя вместо этого мы хотим, чтобы при сохранении по умолчанию выбирался текущий пользователь.

Для приложения администрирования Django часто дополнительно запрашивают добавление в систему прав пользователей прав строкового уровня. По умолчанию администратор обеспечивает детальное управление ролями и правами пользователей, но эти роли применяются на уровне классов: пользователь может модифицировать либо все экземпляры модели Document, либо никаких.

В ряде случаев хочется разрешить пользователям изменять только какие-либо специфичные объекты. Такие права часто называют правами строкового уровня, так как они отражают способность изменять только некоторые строки в таблице базы данных вместо права изменять любые записи в таблице без ограничений. Например, в приложении examples можно разрешить пользователям видеть только их собственные документы.

Сначала, как показано в листинге 12, добавим в models.py атрибут, в котором будет храниться имя создателя экземпляра модели Document.

Листинг 12. Добавляем в models.py информацию о пользователе, создавшем каждый экземпляр модели Document
from django.db import models
from django.db.models import signals
from django.contrib.auth.models import User
from django.core.mail import send_mail
    
class Document(models.Model):
    name = models.CharField(max_length=255)
    text = models.TextField()
    added_by = models.ForeignKey(User, 
      null=True, blank=True)

    def get_absolute_url(self):
        return 'http://example.com/preview/document/%d/' % self.id

    def __unicode__(self):
        return self.name
[...]

Затем нужно добавить код для автоматического заполнения этого поля при создании экземпляра модели Document. Сигналы в этом случае не подходят, так как они не имеют доступа к объекту пользователя. Однако класс ModelAdmin предоставляет метод, включающий в себя запрос, а значит, как параметр, и текущего пользователя.

Поменяем метод save_model() в файле admin.py так, как показано в листинге 13.

Листинг 13. Переопределяем метод в DocumentAdmin для сохранения текущего пользователя в базу данных при создании экземпляра модели
from django.contrib import admin

class DocumentAdmin(admin.ModelAdmin):
    def save_model(self, request, obj, form, change):
        if getattr(obj, 'added_by', None) is None:
            obj.added_by = request.user
        obj.last_modified_by = request.user
        obj.save()

[...]

Если атрибут added_by равен None, значит это новая запись, которая раньше не сохранялась. (Также можно проверять, что change равно false, это обозначает, что запись добавляется, но проверка пустоты поля added_by обеспечивает, что будут заполняться и записи, которые были добавлены не из приложения администрирования.)

Далее надо ограничить список документов, доступных пользователю, только документами, созданными этим пользователем. Это можно сделать с помощью находящегося в классе ModelAdmin метода queryset(), который определяет результат запроса, по умолчанию возвращаемый любой страницей списочного отображения.

Переопределим метод queryset() так, как показано в листинге 14, чтобы ограничить список только документами, созданными текущим пользователем. Суперпользователи могут видеть все документы.

Листинг 14. Переопределяем результат запроса, возвращаемый списочными страницами
from django.contrib import admin
from more_with_admin.examples import models

class DocumentAdmin(admin.ModelAdmin):
   
    def queryset(self, request):
        qs = super(DocumentAdmin, self).queryset(request)

        # если это суперпользователь - показываем все документы
        if request.user.is_superuser:
            return qs
        
        return qs.filter(added_by=request.user)
[...]

Теперь все запросы к странице списочного отображения модели Document приложения администрирования будут показывать только документы, созданные текущим пользователем (за исключением суперпользователей, которым показываются все документы).

Конечно, на данный момент ничто не мешает находчивому пользователю получить доступ к странице редактирования чужого документа, зная его ID. По-настоящему безопасные права строкового уровня требуют переопределения большего количества методов. Так как пользователи с правами администратора, как правило, пользуются определенным доверием, иногда оказывается достаточно такой простой системы прав для обеспечения хорошо налаженного рабочего процесса.


Заключение

Для доработки приложения администрирования требуются некоторые знания исходного кода приложения, но править его приходится лишь в незначительной степени. Приложение администрирования структурировано так, чтобы быть расширяемым посредством обычного наследования Python и некоторой специфичной для Django функциональности, такой как сигналы.

Доработка под свои нужды существующего приложения администрирования имеет много преимуществ по сравнению с созданием нового интерфейса администрирования:

  • ваше приложение может выиграть от развития проекта Django по мере продолжения его активной разработки;
  • приложение администрирования уже поддерживает большинство типичных сценариев использования;
  • при добавлении в проект нового приложения оно так же, как и ваш собственный код, автоматически будет доступно для администрирования.

В Django версии 1.1 в приложении администрирования будут добавлены две часто запрашиваемые новые возможности: возможность линейного (inline) редактирования полей на страницах списочного просмотра и действия администратора (admin actions), которые позволяют обновлять за один раз множество объектов. Оба добавления устранят необходимость писать эту функциональность с нуля при расширении и доработке приложения

Ресурсы

Научиться

Получить продукты и технологии

  • Многие дистрибутивы Linux®, а также Mac OS® X имеют в своем комплекте SQLite, однако если его нет в вашей системе, вы можете загрузить его с сайта проекта SQLite (EN).
  • SQLite V3: Начиная с версии 2.5, в Python появилась поддержка SQLite 3 без необходимости в дополнительных драйверах. В ранних версиях Python для этого приходилось загружать пакет pysqlite (EN).
  • Разработайте ваш следующий проект с помощью пробного ПО от IBM, доступного для загрузки и на DVD.(EN)
  • Загрузите ознакомительные версии продуктов IBM или поработайте с онлайновой пробной версией IBM SOA Sandbox и получите практический опыт с инструментами разработки и связующим ПО от DB2®, Lotus®, Rational®, Tivoli® и WebSphere®.(EN)

Обсудить

  • Пишите в блогах и участвуйте в жизни сообщества developerWorks.

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Open source
ArticleID=630770
ArticleTitle=Расширяем возможности приложения администрирования Django
publish-date=03042011