Разработка серверной части для мобильных приложений. Разработка мобильных приложений: Синхронизация с сервером Код серверной части приложения: РНР

Разработка серверной части клиент-серверного приложения начинается с проектирования архитектуры. От архитектуры зависим многое: начиная от расширяемости приложения и заканчивая его производительностью и удобством поддержки/сопровождения.

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

Необходимо определиться с протоколами обмена данными и форматами передачи данных.

API (application programming interface) – интерфейс прикладного программирования. Если выражаться более понятным языком, то это набор запросов к серверу, который последний понимает и может дать корректный ответ. API определяет функциональность серверной логики, при этом API позволяет абстрагироваться от того, как именно эта функциональность реализована. Другими словами, API – это необходимая часть общей клиент-серверной инфраструктуры.

Сравнить JSON и XML. Привести пример протоколов в зависимости от типа приложения.

Многопоточность

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

Многопоточность – свойство платформы (например, операционной системы, виртуальной машины и т. д.) или приложения, состоящее в том, что процесс, порождённый в операционной системе, может состоять из нескольких потоков, выполняющихся «параллельно», то есть без предписанного порядка во времени.

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

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

К достоинствам многопоточности в программировании можно отнести следующее:

Упрощение программы в некоторых случаях за счёт использования общего адресного пространства.

Меньшие относительно процесса временные затраты на создание потока.

Повышение производительности процесса за счёт распараллеливания процессорных вычислений и операций ввода-вывода.

Поток (threаd) – это управляемая единица исполняемого кода. В многозадачной среде, основанной на потоках, у всех работающих процессов обязательно имеется основной поток, но их может быть и больше. Это означает, что в одной программе могут выполняться несколько задач асинхронно. К примеру, редактирование текста в текстовом редакторе во время печати, т.к эти две задачи выполняются в различных потоках.

На обычном процессоре управление потоками осуществляется операционной системой. Поток исполняется до тех пор, пока не произойдёт аппаратное прерывание, системный вызов или пока не истечёт отведённое для него операционной системой время. После этого процессор переключается на код операционной системы, который сохраняет состояние потока (его контекст) или переключается на состояние другого потока, которому тоже выделяется время на исполнение. При такой многопоточности достаточно большое количество тактов процессора тратится на код операционной системы, переключающий контексты. Если поддержку потоков реализовать аппаратно, то процессор сам сможет переключаться между потоками, а в идеальном случае – выполнять несколько потоков одновременно за каждый такт.

– Временная многопоточность (один поток)

– Одновременная многопоточность (несколько потоков одновременно)

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

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

Другим использованием многопоточности, применяемым даже для однопроцессорных систем, является возможность для приложения реагирования на ввод данных. В однопоточных программах, если основной поток выполнения заблокирован выполнением длительной задачи, всё приложение может оказаться в замороженном состоянии. Перемещая такие длительные задачи в рабочий поток, который выполняется параллельно с основным потоком, становится возможным для приложений продолжать реагировать на действия пользователя во время выполнения задач в фоновом режиме. С другой стороны, в большинстве случаев многопоточность – не единственный способ сохранить чувствительность программы. То же самое может быть достигнуто через асинхронный ввод-вывод или сигналы в UNIX.

Всего различают две разновидности многозадачности: на основе процессов и на основе потоков . Отличия многозадачности на основе процессов и потоков сводится к следующему: многозадачность на основе процессов организуется для параллельного выполнения программ, а многозадачность на основе потоков – для параллельного выполнения отдельных частей одной программы.

Всего различают два типа потоков:

Потоки переднего плана (foreground threads) или приоритетный. По умолчанию каждый поток, создаваемый через метод Thread.Start(), автоматически становится потоком переднего плана. Данный тип потоков обеспечивают предохранение текущего приложения от завершения. Среда CLR не остановит приложение до тех пор, пока не будут завершены все приоритетные потоки.

Фоновые потоки (background threads). Данный вид потоков называется также потоками-демонами, воспринимаются средой CLR как расширяемые пути выполнения, которые в любой момент времени могут игнорироваться. Таким образом, если все потоки переднего плана прекращаются, то все фоновые потоки автоматически уничтожаются при выгрузке домена приложения. Для создания фоновых потоков необходимо присвоить свойству IsBackground значение true.

Рассказать про состояния потоков: запущенный, приостановленный, запущенный, но ожидающий чего-то.

Проблема синхронизации потоков и общие ресурсы.

Взаимодействие потоков

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

Мьютекс – это объект синхронизации, который устанавливается в особое сигнальное состояние, когда не занят каким-либо потоком. Только один поток владеет этим объектом в любой момент времени, отсюда и название таких объектов (от английского mutually exclusive access - взаимно исключающий доступ) - одновременный доступ к общему ресурсу исключается. После всех необходимых действий мьютекс освобождается, предоставляя другим потокам доступ к общему ресурсу. Объект может поддерживать рекурсивный захват второй раз тем же потоком, увеличивая счетчик, не блокируя поток, и требуя потом многократного освобождения. Такова, например, критическая секция в Win32. Тем не менее, есть и такие реализации, которые не поддерживают такое и приводят к взаимной блокировке потока при попытке рекурсивного захвата. Это FAST_MUTEX в ядре Windows.

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

События . Объект, хранящий в себе 1 бит информации «просигнализирован или нет», над которым определены операции «просигнализировать», «сбросить в непросигнализированное состояние» и «ожидать». Ожидание на просигнализированном событии есть отсутствие операции с немедленным продолжением исполнения потока. Ожидание на непросигнализированном событии приводит к приостановке исполнения потока до тех пор, пока другой поток (или же вторая фаза обработчика прерывания в ядре ОС) не просигнализирует событие. Возможно ожидание нескольких событий в режимах «любого» или «всех». Возможно также создание события, автоматически сбрасываемого в непросигнализированное состояние после пробуждения первого же – и единственного – ожидающего потока (такой объект используется как основа для реализации объекта «критическая секция»). Активно используются в MS Windows, как в режиме пользователя, так и в режиме ядра. Аналогичный объект имеется и в ядре Linux под названием kwait_queue.

Критические секции обеспечивают синхронизацию подобно мьютексам, за исключением того, что объекты, представляющие критические секции, доступны в пределах одного процесса. События, мьютексы и семафоры также можно использовать в однопроцессном приложении, однако реализации критических секций в некоторых ОС (например, Windows NT) обеспечивают более быстрый и более эффективный механизм взаимно-исключающей синхронизации – операции «получить» и «освободить» на критической секции оптимизированы для случая единственного потока (отсутствия конкуренции) с целью избежать любых ведущих в ядро ОС системных вызовов. Подобно мьютексам объект, представляющий критическую секцию, может использоваться только одним потоком в данный момент времени, что делает их крайне полезными при разграничении доступа к общим ресурсам.

Условные переменные (condvars). Сходны с событиями, но не являются объектами, занимающими память – используется только адрес переменной, понятие «содержимое переменной» не существует, в качестве условной переменной может использоваться адрес произвольного объекта. В отличие от событий, установка условной переменной в просигнализированное состояние не влечет за собой никаких последствий в случае, если на данный момент нет потоков, ожидающих на переменной. Установка события в аналогичном случае влечет за собой запоминание состояния «просигнализировано» внутри самого события, после чего следующие потоки, желающие ожидать события, продолжают исполнение немедленно без остановки. Для полноценного использования такого объекта необходима также операция «освободить mutex и ожидать условную переменную атомарно». Активно используются в UNIX-подобных ОС. Дискуссии о преимуществах и недостатках событий и условных переменных являются заметной частью дискуссий о преимуществах и недостатках Windows и UNIX.

Порт завершения ввода-вывода (IO completion port, IOCP). Реализованный в ядре ОС и доступный через системные вызовы объект «очередь» с операциями «поместить структуру в хвост очереди» и «взять следующую структуру с головы очереди» - последний вызов приостанавливает исполнение потока в случае, если очередь пуста, и до тех пор, пока другой поток не осуществит вызов «поместить». Самой важной особенностью IOCP является то, что структуры в него могут помещаться не только явным системным вызовом из режима пользователя, но и неявно внутри ядра ОС как результат завершения асинхронной операции ввода-вывода на одном из дескрипторов файлов. Для достижения такого эффекта необходимо использовать системный вызов «связать дескриптор файла с IOCP». В этом случае помещенная в очередь структура содержит в себе код ошибки операции ввода-вывода, а также, для случая успеха этой операции - число реально введенных или выведенных байт. Реализация порта завершения также ограничивает число потоков, исполняющихся на одном процессоре/ядре после получения структуры из очереди. Объект специфичен для MS Windows, и позволяет обработку входящих запросов соединения и порций данных в серверном программном обеспечении в архитектуре, где число потоков может быть меньше числа клиентов (нет требования создавать отдельный поток с расходами ресурсов на него для каждого нового клиента).

Пул потоков

Рассказать про пул потоков

Разработка серверной части приложения

Введение

Присутствие в интернете стало необходимостью для современных компаний. Без этого невозможно выстроить полноценного взаимодействия с клиентами. Часто для решения подобной задачи прибегают к созданию клиент-серверных приложений. Каждое из них состоит из клиентской части и Back-end. Под последним термином подразумевается серверная часть приложения. Если в дальнейшем нужно самостоятельно изменять контент мобильной программы, то Back-end должен быть создан особенно качественно. Компания Appomart гарантирует выполнение поставленных задач в соответствии предъявляемым требованиям. Поэтому, заказывая создание серверных приложений, можете быть уверены в надлежащем результате.

Для чего нужен Back-end?

Разработка клиент-серверных приложений подразумевает создание двух частей. Первая, Front-end, принимает запросы от пользователей. Она видна с экранов мобильных устройств клиентов. Вторая, серверное приложение, обрабатывает полученные запросы, выполняет роль административной панели. Здесь хранятся базы данных, логика программы. Без этого не будет работать ни одно клиент-серверное приложение. По сути Back-end - это сердце программы. Это интеллект, который отвечает за обработку запросов клиентов, скорость работы приложения. Поэтому важно, чтобы архитектура серверного приложения была продумана до мелочей, чтобы даже высоконагруженные сервисы работали бесперебойно и быстро.

Как выбрать язык программирования?

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

Важность документации и "брошенные" проекты

В Appomart довольно часто обращаются заказчики, которых "бросили" по тем или иным причинам другие подрядчики. И мы берем чужой, порою даже некорректно работающий проект, осуществляем его аудит и последующую доработку и поддержку. В процессе изучения исходного кода и материалов, полученных от заказчика, мы сталкиваемся с тем, что многие разработчики намеренно не документируют методы сервера, чтобы привязать к себе клиента, за счет несоизмеримости трудозатрат передачи проекта в поддержку другому разработчику, ввиду отсутствия документации к серверной части, а порой просто из-за непрофессионализма. Данный факт, к сожалению, является не только печальным но и распространенным. Заказчику, в этом случае, необходимо оплачивать разработку документации по существующему проекту, а также аудит исходного кода, прежде чем можно будет судить о работоспособности, удобстве и целесообразности поддержки проекта. Сотрудники Appomart всегда ведут электронную документацию методов серверной части в формате, поддерживаемом Postman и Swagger, для последующего использования.

Как проверить подрядчика до подписания договора?

Мы призываем Вас внимательно выбирать подрядчика, и ориентироваться не только на заманчивую цену, но и на перечень документов, которые вы получите вместе с проектом, а также условия передачи исходного кода, и покрытие кода комментариями, схемы баз данных (будь то Mongo DB или MySQL). Залогом успеха, как правило становится грамотная рабочая документация, которая явно указывает на требования к передаваемой Вам по завершению каждого из этапов работы материалов.

Особенности разработки

PHP для серверной части

Создание серверной части приложений (не путать с серверами как "железом" или компьютерами, так как речь идет о программной части) требует специфических профессиональных навыков и знания языка программирования, который применяется на стороне сервера. Если рассматривать примеры клиент-серверных приложений, то видно, что популярностью пользуется PHP. Это бесспорный лидер в области разработки серверных приложений. На этом языке написано в той или иной конфигурации более половины сайтов в мире. PHP удобен для разработки и поддержки, и кроме того существуют специальные framework-и для ускорения разработки на PHP.

Framework

Framework (программная платформа) - используется для систематизации и повышения уровней абстракции, что позволяет сделать проект более гибким и масштабируемым. Однако, стоит понимать, что framework должен быть выбран корректно, на основе глубинного анализа рабочей документации проекта, без которой невозможно разработать качественный продукт.

Delphi, JAVA, Python

Есть и другие языки, которые используются для создания Back-end. Так, распространены созданные в среде Delphi серверные приложения. С ее помощью программа получает улучшенную отладку, в среде также просто сформировать уникальные программы, предусмотрено визуальное создание, что дает возможность сделать красивый, понятный и удобный интерфейс. Также популярность получили серверные приложения на Java. Такие легко дополняются, легко исполняются на любых платформах и отличаются достойным уровнем безопасности. Еще одним популярным языком считается Python. Серверные приложения с его помощью создаются быстро, просто, без серьезных затрат.

Распространение

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

Создадим клиент-серверное приложение Android, iOS качественно и в срок

Разработка "под ключ"

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

Back-end в Appomart

Наши программисты работают с различными технологиями и делают это в равной степени хорошо. В Appomart вы можете заказать клиент-серверное приложение на Java, PHP и Node.JS. Системные требования анализируются для каждого из проектов индивидуально, что позволяет обеспечить оптимальную производительность программы. Создадим клиент-серверное приложение Java, PHP и Node.JS с нуля или возьмем в саппорт существующее для улучшений и обновлений. Если Вас интересует разработка новой серверной части или поддержка существующей - оставьте заявку, чтобы получить подробный расчет стоимости работ и вариантов сотрудничества.

Офлайн в прошлом, быть Онлайн сегодня обязательно. По крайней мере для современного делового мира. Презентации продукции и услуг брендов, онлайн-заказ и доставка, ведение клиентской базы, общение с клиентами, а также многое другое - все это просто невозможно без присутствия в Интернете. Если вы нуждаетесь в приложении, вы должны иметь как Front-end (веб-интерфейс), так и Back-End (серверная часть вашего приложения). И если вы хотите иметь возможность редактировать контент вашего приложения без участия разработчиков, вам потребуется хорошая административная панель.

В то время как Front-end в сфере мобильных приложений создается с помощью таких технологий, как X-Code и Java, Back-end, где будет храниться база данных и вся логика приложения, требует профессионального знания языка программирования на стороне сервера. Хорошим примером является PHP, который является, пожалуй, самым популярным языком программирования, который используется для разработки почти любой серверной части. Это бесспорный лидер.

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

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

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

488 Часть IV. Ajax в примерах

ботки, и вызывает сервер, который динамически создаст ответные данные, основываясь на отправленном значении строки запроса. Первым параметром функции LoaciXMLXSLTDoc () является URL страницы РНР, которая генерирует XML-документ, объединенный со строкой запроса, сформированной ссылкой на значений поля HTML-формы О. Второй параметр - это имя XSLTфайла ©, используемого в преобразовании XML-данных. Третий параметр, требуемый функцией LoadXMLXSLTDoc (), представляет собой идентификатор элемента div, в который следует помещать результаты поиска. Идентификатор - это строковое имя выходного элемента, а не ссылка на объект; в данном случае в качестве идентификатора используется строка "results" .

На следующем этапе мы с помощью методов DOM добавляем на Webстраницу изображение-индикатор. Создается элемент изображения © и устанавливается атрибут источника изображения О. Этот созданный элемент добавляется к элементу div с результатами ©. Таким образом, когда наша функция вызывается из обработчика событий onsubmit формы, на страницу помещается файл изображения. Вообще, для пользователя важно создать визуальную обратную связь - сообщение или изображение, - указывающую, что обработка находится в процессе. Благодаря этому пользователь не будет повторно щелкать на кнопке отправки форы, думая, что ничего не происходит (помните, процесс Ajax - "незаметный").

Последний этап - это вызов функции LoadXMLXSLTDoc () ®, инициирующей процесс отправки информации на сервер. Функция LoadXMLXSLTDoc (), описанная в разделе 12.4, обрабатывает вызов объекта ContentLoader (), который запрашивает документы с сервера. Задавая в качестве параметра выходное положение (а не кодируя значение жестко в функции LoadXMLXSLTDoc {)), мы можем многократно использовать данную функцию на одной странице, не требуя для разделения функциональных возможностей добавления множества процедур или операторов if. Следовательно, мы перенаправляем результаты различных поисковых запросов на различные части страницы. Однако, прежде чем мы все это сделаем, давайте посмотрим, как создать на сервере документы XML и XSLT.

12.3. Код серверной части приложения: РНР

В данном разделе мы создадим для проекта динамический XML-документ, используя РНР - популярный язык подготовки сценариев с открытым исходным кодом (как вы знаете, инфраструктура Ajax совместима с любым серверным языком или платформой). XML-документ генерируется динамически по набору результатов, полученному в ответ на запрос клиента к базе данных. Кроме того, мы покажем, как создать статический документ XSLT, который расположен на сервере и извлекается каждый раз, когда запрашивается динамический файл. Оба указанных документа возвращаются клиенту независимо, когда объект ContentLoader запрашивается в двух отдельных запросах (листинг 12.7). XSLT-код преобразовывает наш динамический XML-документ на стороне клиента и создает HTML-таблицу, которая отображается пользователю.

Глава 12 "Живой" поиск с использованием XSLT 489

12.3.1. Создание XML-документа

Поскольку мы используем XSLT, нам нужен структурированный XMLдокумент, представляющий собой простую запись информации, чтобы XSLфайл мог выполнить стандартное преобразование. В данном проекте мы создадим динамический XML-файл, когда клиент затребует РНР-файл.

Разработка XML-структуры

Прежде чем мы начнем создание XML-файла, необходимо создать шаблон для него. Этот шаблон должен отражать структуру данных, возвращаемых при поиске. В выбранной формулировке задачи (телефонная книга) мы будем возвращать название компании, имя контактного лица, страну и телефонный номер. В листинге 12.3 показан базовый XML-шаблон, содержащий четыре поля.

Листинг 12.3. Базовый XML-файл

Company Name Contact Name Country Name Phone Number

Первым элементом является phonebook. Следующий - элемент entry, содержащий подэлементы со всеми деталями, которые связаны со всеми контактными телефонами, найденными в запросе. Если у нас есть пять результатов, в XML-документе будет пять элементов entry. Имя компании отображается в элементе company. Кроме того, мы добавили имя контактного лица, название страны и номер телефона. Мы не ограничены только указанными полями; в зависимости от того, какую информацию необходимо отобразить, поля можно добавлять и удалять.

Если результаты не найдены, то вместо отображения предупреждающего сообщения можно создать элемент, отображающий эту информацию для пользователя. STO облегчит нам задачу возврата результата пользователю и не потребует дополнительного кода в клиентской части приложения. Код, приведенный в листинге 12.4, практически не отличается от кода из листинга 12.3, но на этот раз мы вводим текст в элементы XML, которые желаем показать пользователю, чтобы сообщить, что результаты не найдены.

Листинг 12.4. Файл XML без результатов

No Results

// О Вместо имени компании отображается "No R e s u l t s " N/A

490 Часть IV. Ajaxв примерах

// © Вместо оставшихся полей отображается "N/A"

N/A

С помощью данного кода мы отображаем пользователю единственную строку, сообщающую, что затребованная информация отсутствует. В дескрипторе company О отображается информация, сообщающая, что результатов нет. В других дескрипторах 0 пользователю сообщается, что информации нет. Если мы не желаем отображать текст "N/A" ("не доступно"), можно добавить вместо него неразрывный пробел, что позволит показать ячейки таблицы. Если бы мы не добавили вообще никакой информации, ячейки в таблице не появились бы.

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

Создание динамического XML-документа

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

Листинг 12.5. Сценарий phoneXML.php: генерация XML-документа на сервере

// О Объявить тип MIME header("Content-type: text/xml"); echo("\n");

$db = mysql__connect ("localhost", "ajax", "action"); rnysql_select_db("ajax",$db);

$result = mysql_query("SELECT *

$_GET["q"] ."%"",$db); ?>

// О Проверить результаты

if ($myrow = mysgl_fetch_array($result)) { do {

Глава 12. "Живой" поиск с использованием XSLT 491

001">

}while ($myrow - mysql_fetch_array{$result)); }else{

телефонной книги, либо выдаем сообщение "No Results" 0.

12.3.2. Создание документа XSLT

Используя XSLT, наш XML-файл с помощью пары строк кода можно преобразовать в красивую таблицу HTML. XSLT-документ разрешает сопоставление с шаблоном, если оно необходимо для отображения данных в любом требуемом формате. При сопоставлении с шаблоном для отображения данных применяется структура-шаблон. При этом мы проходим по узлам дере-

492 Часть IV. Ajax в примерах

ва источника, используя XSLT. XSLT-доку мент принимает структурированный XML-файл и преобразует его в формат, который удобен для просмотра, обновления и изменения. В нашем случае XSLT-доку мент определяется статически.

Структура XSLT

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

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

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

Создание XSLT-документа

Сформировать XSLT-преобразование для данного проекта сравнительно просто. Поскольку мы собираемся получить таблицу, никакое необычное сопоставление с шаблоном не потребуется; мы просто последовательно пройдем по всем узлам-элементам исходного дерева. Ниже мы разработаем шаблон, формирующий таблицу HTML с четырьмя столбцами. Соответствующий XSLTфайл для данного проекта показан в листинге 12.6.

i Листинг 12.6. XSLT-файл

"ISO-8859-l"?>

// О Установить версию XML и кодировку

// О Добавить элемент table

Глава 12 "Живой" поиск с использованием XSLT 493

// 0 Последовательно пройти по элементам телефонной книги

Company	Contact	Country	Phone

При создании XSLT-преобразования необходимо указать кодировку и версию XML О, а также задать пространство имен XSLT ©. Пространство имен определяет правила и спецификации, которым должен соответствовать документ. Элементы в пространстве имен XML распознаются в исходном документе, но не распознаются в документе результатов. Для определения всех наших элементов в пространстве имен XSLT применяется префикс xsl. Далее молено установить правило шаблона - искать структуру / ©, которая соответствует всему документу.

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

Последовательно проходя по множеству узлов исходного дерева, мы получаем остальные строки таблицы. В данном случае используется цикл for-each ©, в процессе обработки записей выдающий узлы, расположенные в phonebook/entry.

Поскольку мы последовательно проходим по дереву документа, необходимо выбрать значения столбцов. Чтобы выбрать значения из узлов, используется оператор value-of в, извлекающий значение элемента XML и добавляющий его в выходной поток преобразования. Чтобы задать элемент XML, текст которого мы желаем извлечь, используем с именем элемента атрибут select. Сформировав XSLT-фаЙл и создав код для динамической генерации документа XML, можно завершить создание JavaScript-кода и посмотреть, как объединение XSLT-преобразования со структурированным XML-файлом позволяет получить удобную для просмотра таблицу.

На следующем этапе мы снова возвращаемся на сторону клиента, извлекающего файлы, созданные только что с помощью НТТР-отклика.