Заполучить определённые сведения с динамического сайта – это не сказать что очень редкая, но всё же специфическая задача, решение которой и предлагает статья (без покидания, насколько возможно, уютных рамок Delphi); под динамической страницей автор понимает не просто сайт, содержащий JavaScript (в современных реалиях найти ресурс без него довольно сложно), а страницу, на которой интересующие разработчика данные изначально отсутствуют в документе, полученном от веб-сервера, появляясь исключительно после отработки JS-кода, каким-то образом вычисляющего их, либо запрашивающего нужную информацию от некоего сервера.

Если читатель раньше не сталкивался с подобной проблематикой, то наверняка приведённое сжатое описание малопонятно, поэтому обратимся к конкретному примеру – пусть требуется извлечь альбомы некоторой группы с metal-archives.com:

Один из способов доморощенной классификации служб основывается на времени их жизни: некоторые из них запускаются сразу же при старте ОС, оставаясь активными постоянно (сюда, скажем, можно отнести веб-серверы и СУБД), другие же запускаются лишь при необходимости, делают свои архиважные дела и сразу завершаются; при этом, ни один из вариантов сам по себе не делает реализацию службы сложнее, однако второй требует от разработчика как минимум ещё и умения программно стартовать, а при необходимости и досрочно останавливать её работу. Именно указанный аспект управления службой, плюс добавление некоторых отсутствующих в штатной поставке Delphi возможностей, и сподвиг автора на данный опус.

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

Автор должен признаться: статья родилась и выросла из довольно небольшой и не претендующей на откровение оптимизации сайта, описанного в другом материале. Сайт этот связан с музыкальной тематикой и, соответственно, активно отображает обложки альбомов, хранящиеся (до поры до времени) на сервере не в ФС, как обычно бывает, а в БД SQL Server (в BLOB-поле, о чём несложно догадаться); в старом варианте пора извлечения изображений из базы и сохранения их в виде файлов возникает в момент запроса альбомов пользователем, после чего (по истечении сессии) они удаляются.


Чтобы почти окончательно развеять куцую интригу и помочь возможному читателю определиться с тем, имеет ли смысл продолжить чтение, опишу конечный результат оптимизации: обложки по-прежнему останутся в базе данных, причём в поле того же типа, но вот веб-сервер, отдающий в итоге изображения клиенту, будет «обманут» и станет обращаться за файлом знать не зная, что его на самом деле нет в ФС, а вызов идёт сразу и непосредственно к СУБД. Такой «обман» конечно же не является самоцелью – всё в основном затевалось ради уменьшения нагрузки на дисковую подсистему.

На самом деле, статья несколько шире – она описывает способ, позволяющий прозрачно задействовать и многие другие библиотеки (причём не только из мира Free Pascal), а InternetTools выбрана из-за своего замечательного свойства – это тот случай, когда (как ни удивительно) отсутствует Delphi-вариант с такими же широкими возможностями и удобством использования.

Эта библиотека предназначена для извлечения информации (парсинга) из веб-документов (XML и HTML), позволяя использовать для указания нужных данных как языки запросов высокого уровня, такие как XPath и XQuery, так и, в качестве одного из вариантов, предоставляя прямой доступ к элементам дерева, построенного по документу.

uniGUI – это библиотека, позволяющая создавать веб-приложения в классической Delphi-манере, посредством визуальных компонентов, причём, что является немаловажным, в большинстве случаев она полностью скрывает от разработчика всю клиентскую (браузерную) «кухню»: не требуется знать ни HTML, ни CSS, ни JavaScript, а вся разработка ведётся лишь на одном языке – Delphi.

Если смотреть на картину издалека, то вырисовываются 3 сценария использования библиотеки:

1. Наиболее благоприятный, для которого она в целом и создавалась, когда описанная сильная, радужная сторона uniGUI проявляет себя в полной мере – перенос (полный или частичный – неважно) настольных приложений в веб, что возможно проделать быстро, привычным способом и с высоким качеством только в случаях, когда поставляемые с библиотекой компоненты сразу обеспечивают требуемый функционал – к примеру, фильтрацию и сортировку по столбцам таблицы.
2. Очень похож на первый и в какой-то мере вытекает из него, с тем лишь отличием, что штатный набор компонентов не покрывает все необходимые по ТЗ возможности; если снова взять для примера таблицу, то таким требованием может стать многоуровневая группировка строк по произвольным столбцам. Если удастся найти сторонние решения с нужными возможностями, то сценарий сводится к первому, а если нет, то потребуется самостоятельная доработка, что уже весьма нетривиально, т. к. здесь не обойтись не просто без знаний JavaScript, а ещё и глубокого владения фреймворком Ext JS, на основе которого работает браузерная сторона uniGUI.
3. Последний сценарий может показаться странным и даже чужеродным для тех, кто применял на практике в основном первый, – речь об отказе от всей богатой палитры визуальных компонентов и разработке клиентской части веб-приложения исключительно с использованием родной для неё триады – HTML, CSS и JavaScript. Данная статья покажет, в каких случаях подобное допустимо, а также продемонстрирует способ реализовать задуманное.

Доводилось ли Вам реализовывать объёмный сетевой обмен посредством TCP- или HTTP-протокола? Насколько, в случае такого опыта, Вы были удовлетворены сопровождаемостью конечного решения? Утвердительный ответ на первый вопрос (пусть даже и без «объёмистости» обмена) и недовольство гибкостью получившейся реализации позволяют рекомендовать эту статью как содержащую один из способов избавления от такого несчастья.

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

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

В предыдущем материале «Выбор СУБД для мобильного Delphi-приложения», как следует из его названия, был показан первый этап в разработке той подсистемы приложения, что отвечает за хранение и бо́льшую часть обработки его данных; уточнение про «бо́льшую часть» сделано неспроста, т. к. в итоге обозначенный выбор пал на СУБД Interbase именно из-за возможности применять хранимые процедуры (ХП), которые и стали сосредоточением основной логики по работе с данными, оставляя за Делфи-кодом несложную задачу по их вызову.

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

Данная статья написана по мотивам – мотивам разработки мобильного приложения, недавно вышедшего на платформах iOS и Android. Это событие можно было бы назвать заурядным и мало кому интересным, если бы не одно большое и несколько незначительных «но»: вся разработка (включая сервер) велась на Delphi, а в качестве СУБД, как ни странно, задействована совсем не SQLite. Автор, безусловно, понимает, что на текущий момент уже существуют мобильные Delphi-приложения, включая доступные в официальных магазинах, однако не наблюдает обилия русскоязычных публикаций, призванных, как минимум, предостеречь читателей от ошибок, сделанных разработчиком таких проектов. Написанное же здесь преследует цель помочь тем, кто сейчас выбирает СУБД для своего творения, либо уже остановился на каком-то варианте, но желает убедиться в правильности своего решения.

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