Django использует подход MVT (Model-View-Template - модель-представление-шаблон). Подход модель-представление-шаблон похож, если не идентичен, более общему подходу МVС (Model-View-Controller - модель-представление-контроллер). Оба способа позволяют разрабатывать веб-приложения так, чтобы не смешивать части приложений. Программный код взаимодействия с базой данных в обоих случаях представляет собой отдельную область, которая называется «моделью». Бизнес-логика выделяется в область, которая называется «представлением» в MVT и «контроллером» в MVC. А внешний интерфейс выделяется в область, которая называется «шаблоном» в MVT и «представлением» в MVC.

Приложение для просмотра файла журнала веб-сервера Apache

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

Загрузить Django можно по адресу: http :// www . djangoproject . com /. К моменту написания этих строк последней была версия 0.96. Однако мы рекомендуем устанавливать версию из дерева разработки. После загрузки платформа устанавливается обычной командой python setup.py install. После установки в каталоге site - packages появятся дополнительные библиотеки платформы Django и сценарий django-ad-min.py в каталоге для сценариев. Обычно в UNIX-подобных системах сценарии по умолчанию устанавливаются в тот же каталог, где находится выполняемый файл python.

После установки Django необходимо создать проект и приложение. Проекты содержат по одному или более приложений. Кроме того, они играют роль центров конфигурации для всего веб-приложения (не путайте с приложением Django), которое вы создаете. Приложения Django -это небольшие фрагменты, которые могут многократно использоваться в разных проектах. Для нашего приложения просмотра файла жу-ранала веб-сервера Apache мы создали проект с именем «dj_apache», выполнив команду django-admin. py startproject dj_apache. Эта команда создала каталог и несколько файлов. В примере 11.4 приводится дерево каталогов нового проекта.

Пример 11.4. Дерево каталогов проекта Django

Теперь, когда у нас имеется проект, мы можем в рамках этого проекта создать приложение. Для этого сначала следует перейти в каталог djjapache, а затем создать приложение, выполнив команду django-ad-min.py startapp logview. В результате в каталоге djjapache будет создан каталог logview и несколько файлов. В примере 11.5 показаны все файлы и каталоги, которые теперь имеются в нашем распоряжении.

Пример 11.5. Дерево каталогов приложения Django

Как видите, каталог приложения (logview) содержит файлы models.ру и views.py. Платформа Django следует соглашениям MVT, поэтому эти файлы помогут разделить все приложение на компоненты, соответствующие именам файлов. Файл models.py содержит схему базы данных, поэтому он представляет компонент Model (модель) в аббревиатуре MVT. Файл views.ру содержит реализацию логики приложения, поэтому он представляет компонент View (представление) в этой аббревиатуре.

Здесь отсутствует компонент Template (шаблон). Компонент шаблона содержит уровень представления всего приложения. Существует несколько способов заставить платформу Django увидеть наши шаблоны. Так, в примере 11.6 показано, что мы создали подкаталог templates в каталоге logview.

Пример 11.6'. Добавление каталога templates

Теперь мы готовы к воплощению нашего приложения. В первую очередь мы должны решить, как будут работать наши URL. Это очень простое приложение, поэтому адреса URL должны быть очень простыми. Нам потребуется выводить список файлов журналов, доступных для просмотра. Поскольку приложение обладает простой и ограниченной функциональностью, мы будем использовать адрес URL «/» для доступа к списку файлов и строку URL вида "/viewlog/some_sort_method/ some_log_file" для указания имени файла и метода сортировки. Чтобы связать URL с определенным действием, нам необходимо обновить файл urls. py в корневом каталоге проекта. Содержимое файла urls.ру для нашего проекта приводится в примере 11.7.

Пример 11.7. Конфигурация URL для проекта Django ( urls. py)

Файл с настройками URL достаточно прост и понятен. Этот файл опирается на использование регулярных выражений: строки URL, соответствующие регулярному выражению, отображаются на функцию представления, задаваемую явно строкой. Здесь мы отображаем URL «/» на функцию "dj_apache.logview.views.llst_files". Все остальные URL, соответствующие регулярному выражению ' "viewlog/(?P<sortmethod>.*?)/ (?P<filename>.*?)/$',- на функцию "dj_apache. logview.views.view_log". Когда броузер соединяется с веб-приложением Django и отсылает запрос на доступ к определенному ресурсу, Django просматривает urls.ру в поисках элемента, регулярное выражение которого соответствует URL, и затем направляет запрос соответствующей функции.

В примере 11.8 представлен исходный текст функций представления для данного приложения, а также вспомогательной функции.

Пример 11.8. Модуль представления Django ( uiews. py)

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

Функция view_log() принимает в качестве аргументов метод сортировки и имя файла журнала. Значения для обоих этих аргументов извлекаются из URL посредством регулярного выражения, заданного в файле urls. py. Для задания метода сортировки и имени файла мы использовали именованные группы в регулярном выражении в файле urls.py, но это не является обязательным. Аргументы, извлеченные из URL, передаются функции представления в том же порядке, в каком они были найдены в соответствующих группах. Это распространенная практика, когда в регулярном выражении разбора URL используются именованные группы, потому что благодаря такому подходу вы легко можете сказать, какие параметры извлекаются из URL, а также - как должна выглядеть строка URL.

Функция view_log() открывает файл журнала с именем, полученным из URL. Затем выполняется его анализ с помощью библиотеки анализа файлов журналов Apache из приведенных ранее примеров, чтобы преобразовать каждую строку в кортеж, в формате: статус, удаленный_хост, количество_байтов и остаток строки журнала. Затем функция view_log() сортирует список кортежей, который был получен из URL, с учетом указанного метода сортировки. В заключение функция view_log() передает полученный список шаблону view_logfile. html для отображения.

Единственное, что осталось сделать, это создать шаблоны, которые используются функциями представления для отображения информации. Шаблоны в платформе Django могут наследовать другие шаблоны, благодаря чему повышается уровень многократного использования кода и обеспечивается единообразие внешнего вида страниц. Первым мы создадим шаблон, который является родительским для двух других шаблонов. Этот шаблон будет определять общий внешний вид для других двух шаблонов в приложении. Именно поэтому мы и начнем с него. Это шаблон base.html, исходный код которого приводится в примере 11.9.

Пример 11.9. Базовый шаблон Django ( base. html)

Это очень простой базовый шаблон. Возможно, это самая простая страница HTML, которую только можно получить. Единственные элементы, которые представляют здесь интерес, - это два раздела «block»: «title» и «content». Когда в родительском шаблоне определяется раздел «block», дочерний шаблон получает возможность заменить его своим собственным содержимым. Это позволяет задавать содержимое по умолчанию, которое может быть замещено в дочернем шаблоне. Блок «title» позволяет дочерним страницам определять значение, которое будет отображаться в теге <title>. Блок «content» - это типичный прием обновления «главного» раздела страницы без внесения изменений в остальную часть страницы.

В примере 11.10 приводится шаблон, с помощью которого выводится список файлов в указанном каталоге.

Пример 11.10. Шаблон Django для вывода списка файлов ( llst_ files. html)

На рис. 11.4 показано, как выглядит страница со списком файлов.

В этом шаблоне мы указываем, что расширяем шаблон «base.html». Это позволяет использовать все, что определено в базовом шаблоне, включать свой код в любые блоки, которые были определены, и переопределять их поведение. Именно это мы и делаем с блоками «title» и «content». В блоке «content» в цикле выполняется обход содержимого переменной file_llst, которая была передана шаблону. Для каждого элемента в списке file_llst создается ссылка, в результате щелчка на которой будет открыт соответствующий файл журнала.

Шаблон в примере 11.11 отвечает за создание страниц, на которые указывают ссылки из шаблона в предыдущем примере 11.10. Он отображает содержимое выбранного файла журнала.

Рис. 11.4. Список файлов журналов веб-сервера Apache

Пример 11.11. Шаблон Django для вывода содержимого файлов ( view_ logfile. html)

Шаблон в примере 11.11 наследует базовый шаблон, упоминавшийся выше, и создает таблицу в области «content». Заголовок таблицы описывает содержимое каждого столбца: код состояния, удаленный хост, количество отправленных байтов и остаток строки из файла журнала. Помимо описания содержимого, заголовки столбцов дают пользователю возможность вbinолнять сортировку по тому или иному столбцу. Например, если пользователь щелкнет на заголовке столбца «ьytes Sent» (передано байтов) (который является обычной ссылкой), страница будет перезагружена и программный код в сценарии представления отсортирует строки по столбцу «bytes Sent». Щелчок на заголовке любого столбца, за исключением «Line», будет приводить к вbinолнению сортировки по этому столбцу в порядке возрастания. Щелчок на заголовке «Line» приведет к возврату к первоначальному порядку следования строк.

На рис. 11.5 показано, как выглядит страница приложения с оригинальным порядком следования строк, а на рис. 11.6- как выглядит страница после выполнения сортировки по столбцу «bytes Sent».

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

Рис. 11.5. Просмотр содержимого файла журнала веб-сервера Apache — сортировка по номерам строк

Рис. 11.6. Просмотр содержимого файла журнала веб-сервера Apache -сортировка по количеству отправленных байтов

Простое приложение базы данных

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

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

Как и в предыдущем примере, мы вbinолним те же самые действия, чтобы создать проект и приложение Django. Ниже приводятся команды обращения к инструменту командной строки django-admin, создающие проект и приложение:

Эти команды создали аналогичное дерево каталогов, как и в предыдущем примере приложения для просмотра файла журнала веб-сервера Apache. Ниже приводится дерево каталогов и файлов, которые были созданы:

Создав проект и приложение, нам необходимо настроить базу данных, с которой мы будем работать. База данных SQLite предоставляет прекрасные возможности, особенно для нужд тестирования и разработки, при условии, что она не будет использоваться в рабочем окружении. Если приложение предусматривает работу более чем с одним пользователем одновременно, мы рекомендуем использовать более надежную базу данных, такую как PostgreSQL. Для настройки приложения на использование базы данных SQLite мы изменим пару строк в файле settings . py , расположенном в корневом каталоге проекта. Ниже показаны строки, которые мы изменили:

В качестве механизма базы данных мы указали «sqliteS». Строка, определяющая местоположение базы данных (параметр DATAbase_NAME), требует дополнительных пояснений. Вместо того чтобы указать абсолютный путь к файлу базы данных, мы определили, что он всегда будет

находиться в том же каталоге, что и файл settings . py . Атрибут_ _file_ всегда хранит абсолютный путь к файлу settings . py . Вызов метода

os. path. dirname(_ _file_ _) возвращает каталог, в котором находится

файл settings . py . Полученное имя каталога и имя файла базы данных, который мы предполагаем создать, передается методу os.path. join(), возвращающему абсолютный путь к файлу базы данных, который зависит от каталога с приложением. Это полезный прием, который вы можете взять на вооружение при настройке параметров, связанных с местоположением файлов.

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

Мы добавили в список установленных приложений django. contriь. admin и sysmanage. inventory. Это означает, что, когда мы потребуем от платформы Django создать базу данных, она создаст таблицы для всех установленных приложений.

Далее нам необходимо настроить отображение URL, так чтобы этот проект включал административный интерфейс. Ниже приводится соответствующая строка из файла настройки URL:

Инструмент, создавший файл urls. py, поместил в него строку, которая подключает административный интерфейс, но эту строку требуется раскомментировать. Как видите, чтобы подключить административный интерфейс, мы просто убрали символ #, стоявший в начале строки.

Теперь, когда мы настроили базу данных, добавили приложения административного интерфейса и инвентаризации и добавили административный интерфейс в конфигурационный файл urls. py, можно приступать к определению схемы базы данных. При использовании платформы Django для каждого приложения определяется своя собственная схема. В каталоге каждого приложения, в данном случае «inventory», присутствует файл с именем models. py, содержащий определения таблиц и столбцов, которые будут использоваться приложением. В Django, как и в других платформах разработки веб-приложений, опирающихся на использование объектно-реляционных проекций (Object-Relation Mapping, ORM), вполне возможно создавать и использовать базы данных, не написав ни одного SQL-выражения. Механизм ORM платформы Django превращает классы в таблицы, а атрибуты классов в столбцы этих таблиц. Например, следующий фрагмент программного кода является определением таблицы настроенной базы данных (этот фрагмент является частью более крупного сценария, к которому мы вскоре подойдем):

Обратите внимание, что класс HardwareComponent наследует класс Model платформы Django. Это означает, что класс HardwareComponent относится к типу Model и обладает соответствующим поведением. Каждому аппаратному компоненту мы придали несколько атрибутов: manufacturer (производитель), type (тип), model (модель), vendor_part_numьer (серийный номер) и description (описание). Реализация этих атрибутов находится в самой платформе Django. Нет, платформа не предоставляет какой-либо перечень производителей, но она реализует тип CharField.

Такое определение класса в приложении inventory создаст таблицу inventory_hardwarecomponent с шестью столбцами: id, manufacturer, type, model, vendor_part_numьer и description. Что практически в точности соответствует определению класса для ORM. Фактически такое объявление полностью соответствует определению класса для ORM. Когда определяется класс модели, платформа Django создает соответствующую таблицу с именем, состоящим из имени приложения (все символы в нижнем регистре), за которым следуют символ подчеркивания и имя класса (все символы также в нижнем регистре). Кроме того, если не определено иное, платформа создаст в вашей таблице дополнительный столбец id, который будет играть роль первичного ключа. Ниже приводится код на языке SQL, создающий таблицу, которая полностью соответствует модели HardwareComponent:

Если вам когда-нибудь потребуется увидеть код на языке SQL, который платформа использует для создания базы данных, просто запустите в каталоге проекта команду python manage.py sql myapp, где аргумент myapp соответствует имени приложения.

Теперь, когда вы познакомились с ORM платформы Django, мы пройдем через создание модели базы данных для нашего приложения инвентаризации. В примере 11.12 приводится содержимое файла model.py для приложения inventory.

Пример 11.12. Схема базы данных ( models. py)

Для нашей модели мы определили пять классов: OperatingSystem, Service, HardwareComponent, Server и IPAddress. Класс OperatingSystem позволяет нам определять различные операционные системы для серверов, которые будут учитываться приложением инвентаризации. В этом классе мы определили два атрибута: name и description, которые действительно будут необходимы нам. Можно было бы создать класс OperatingSystem-Vendor и определить ссылку на него в классе OperatingSystem, но в интересах сохранения простоты и понятности мы опустим упоминание о производителе операционной системы. Каждому серверу будет соответствовать единственная операционная система. Мы покажем это отношение между сервером и операционной системой, когда будем рассматривать класс Server.

Класс Service позволяет перечислить все службы, которые могут вbinолняться на сервере. В качестве примеров таких служб можно назвать веб-сервер Apache, сервер электронной почты Postfix, сервер

DNS bind и сервер OpenSSH. Как и класс OperatingSystem, этот класс имеет два атрибута: name и description. Каждый сервер может иметь множество служб. Мы покажем отношения между этими классами, когда будем рассматривать класс Server.

Класс HerdwareComponent представляет список всех аппаратных компонентов, которые могут содержаться в сервере. Этот список будет представлять интерес, только если вы сами добавляли аппаратные компоненты в приобретенную систему и в случае, если вы собирали сервер из отдельных компонентов. В классе HardwareComponent мы определили пять атрибутов: manufacturer, type, model, vendor_part_numьer и description. Как и в случае с изготовителем операционной системы, можно было бы создать отдельные классы для описания производителей и типов аппаратного обеспечения, а затем связать их отношениями. Но опять же, ради сохранения простоты мы предпочли не создавать такие отношения.

Класс Server - это основа системы инвентаризации. Каждый экземпляр класса Server - это отдельный сервер, информацию о котором мы собираем. Класс Server - это место, где сходятся все связи и устанавливаются отношения с тремя предыдущими классами. Прежде всего, мы дали каждому серверу атрибуты name и description. Они идентичны одноименным атрибутам в других классах. Чтобы установить отношения с другими классами, нам необходимо указать в классе Server, какого типа будут эти отношения. Каждый сервер будет иметь только одну операционную систему, поэтому мы создаем отношение с классом OperatingSystem по внешнему ключу (foreign key). Поскольку виртуализация становится все более распространенным явлением, отношение такого типа со временем потеряет свой смысл, но пока оно вполне удовлетворяет нашим потребностям. На сервере может вbinолняться множество служб, и служба одного и того же типа может вbinолняться на многих серверах, поэтому между классами Server и Service мы создали отношение типа «многие ко многим». Точно так же каждый сервер может содержать множество аппаратных компонентов, а один и тот же тип аппаратного компонента может быть установлен на множестве серверов. Поэтому классы Server и HardwareComponent мы также связали отношением типа «многие ко многим».

Наконец, класс IPAddress - это список всех IP-адресов всех серверов, которые должны быть учтены. Мы определили эту модель последней, чтобы подчеркнуть отношения между IP-адресами и серверами. Класс IPAddress имеет один атрибут и одно отношение. Атрибут address содержит IP-адрес в формате ХХХ.ХХХ.ХХХ.ХХХ. Между классами IPAddress и Server мы определили отношение по внешнему ключу, потому что один IP-адрес может принадлежать только одному серверу. Да, это выглядит слишком упрощенно, но это удовлетворяет целям демонстрации установления отношений между компонентами данных в Django.

Теперь все готово к созданию файла базы данных sqlite. Если запустить команду python manage, py syncDB в каталоге проекта, она создаст все отсутствующие таблицы для приложений, включенных в файл settings . py . Она также предложит создать в базе данных учетную запись суперпользователя, если предусмотрено создание таблиц аутентификации. Ниже приводится (усеченный) вывод команды python manage.py syncDB:

Теперь можно запустить сервер разработки Django и заняться исследованием административного интерфейса. Ниже приводится команда запуска сервера разработки Django и вывод, полученный в ходе ее выполнения:

На рис. 11.7 показана форма регистрации. Пройдя процедуру аутентификации, мы сможем добавлять серверы, аппаратные компоненты, операционные системы и прочие данные. На рис. 11.8 показана главная страница административного интерфейса Django, а на рис. 11.9 — форма добавления нового аппаратного компонента. Полезно иметь инструмент, позволяющий сохранять и просматривать данные непротиворечивым, простым и удобным способом! Платформа Django удивительно легко справляется с реализацией простого и удобного интерфейса доступа к данным. И если это все, что вам необходимо, такой инструмент станет полезным для вас. Но это только самая верхушка возможностей платформы Django. Придумав вид отображения данных

Рис. 11.7, Страница регистрации при входе в административный интерфейс Django

Puc. 11.8. Главная страница административного интерфейса Django

Например, если бы нам потребовалось получить отдельную страницу для каждого типа операционной системы, аппаратного компонента, службы и так далее, мы могли бы это реализовать. Если бы нам потребовалось иметь возможность щелкнуть на любом из этих элементов и получить список серверов, обладающих этой характеристикой, мы также могли бы реализовать это. И если бы нам потребовалось иметь возможность щелкнуть на любом из серверов и получить подробную информацию о нем, мы смогли бы реализовать и это. Давайте теперь это сделаем. Добавим эти «потребности» к первоначальным требованиям.

Рис. 11.9. Форма добавления аппаратного компонента в административном интерфейсе Django

Для начала в примере 11.13 приводится дополненный файл urls. py. Пример 11.13. Отображение адресов URL (urls.py)

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

Следующее, что мы сделаем, это добавим в модуль views функции, которые были объявлены в файле отображения адресов URL. В примере 11.14 приводится содержимое модуля views.

Пример 11.14. Функции представления приложения инвентаризации ( views. py)

В файл urls. py мы добавили три отображения адресов URL, поэтому мы добавили три функции в файл views. py. Первая функция - main(). Она просто получает списки всех типов операционных систем, аппаратных компонентов и служб и передает их шаблону main.html.

В примере 11.6 мы уже создавали подкаталог templates в каталоге приложения. Теперь сделаем то же самое и здесь:

В примере 11.15 приводится содержимое шаблона «main.html», которому функция main() передает данные для отображения.

Пример 11.15. Главный шаблон ( main. html)

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

Когда пользователь щелкает на одной из таких ссылок, вызывается следующая функция представления categorized().

Главный шаблон передает функции представления categorized() категорию (os - в случае операционной системы, hw - в случае аппаратного компонента и svc - в случае службы) и id категории (то есть конкретный компонент, на котором был вbinолнен щелчок, например, «3Com 905b Network Card»). Функция categorized() принимает эти аргументы и извлекает из базы данных список всех серверов, содержащих выбранный компонент. После запроса на получения информации из базы данных функция categorized() передает полученные сведения шаблону «categorized.html». В примере 11.16 приводится содержимое шаблона «categorized.html».

Пример 11.16. Шаблон категории ( categorized . html )

Шаблон «categorized.html» отображает список всех серверов, полученный от функции categorized().

После этого пользователь может щелкнуть на выбранном сервере, что приведет к вызову функции представления server_detail(). Функция представления server_detail() принимает параметр с идентификатором (id) сервера, извлекает информацию о сервере из базы данных и передает ее шаблону «server_detail.html».

Содержимое шаблона «server_detail.html» приводится в примере 11.17. Это самый большой шаблон в приложении, но он очень простой. Его задача заключается в том, чтобы отобразить отдельные элементы данных для сервера, такие как тип операционной системы, под управлением которой работает сервер, установленные в нем аппаратные компоненты, службы, запущенные на сервере, и IP-адреса, присвоенные серверу.

Пример 11.17. Шаблон отображения информации о сервере ( server_ detail. html)

Этот пример показывает, как создать довольно простое приложение базы данных, используя платформу Django. Административный интерфейс обеспечивает возможность наполнения базы данных, а добавив совсем немного строк программного кода, мы сумели создать собственные представления, позволяющие сортировать данные и перемещаться по ним, как показано на рис. 11.10, 11.11 и 11.12.

Рис. 11.10. Основная страница приложения управления системами

Рис. 11.11. Приложение управления системами - категория CentOS

Рис. 11.12. Приложение управления системами - информация о сервере

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

Set as favorite

Bookmark

Email This

Hits: 949

Комментарии (0)

RSS feed Comments

Написать комментарий

Имя

Электронный адрес

Вебсайт

Заголовок

Комментарий

smaller | bigger

Subscribe via email (Registered users only)

I have read and agree to the Terms of Usage.

Добавить комментарий