Bob Swart - Интернет решения от доктора Боба

Подобно любому ActiveX контролу, ActiveForm требуется Win32 платформа для исполнения, но это должна быть Win32 платформа, так как ActiveForm это обычный ActiveX орган, и может быть использован внутри других средств разработки, поддерживающих ActiveX, таких как C++Builder, Visual Basic, PowerBuilder, и также Internet Explorer. Последнее означает, что мы можем использовать ActiveForm для распространения Интернет приложений в Интернет или Интранет.

Простой откомпилированный ActiveForm проект может оказаться в .OCX размером свыше 300 Kb, даже если были использованы совсем немного контролов и всего лишь несколько строк кода. Компиляция с пакетами, VCLx0 (стандарт) или VCLDBx0 (data-aware) может уменьшить этот размер до 50 Kb, более мене функциональные ActiveForm будуь порядка 100 Kb. Пакеты значительно увеличивают размер (VCLx0 пакет это более мегабайта), но они должны ставиться у клиента только один раз, и могут быть уже предустановленны у клиента, что позволяет уменьшить время загрузки.

Поскольку ActiveForm это просто другое Win32 приложение, то даже когда оно запускается из Internet Explorer то могут произойти неприятные вещи у неискушенных пользователей. По одной причине, ActiveForm имеет доступ ко всей машине, и если пользователь зарегистрировался в сети, то ActiveForm, подобно вирусу может сделать все что угодно на вашей машине (отформатировать жесткий диск? Послать e-mail? Разрушить базу данных? Все что вы в состоянии представить и еще более). Поэтому при загрузке из Интернета (но не внутренней сети компании), мы должны считать ActiveForm или любой ActiveX орган потенциальным вирусом. Авторы ActiveForm и ActiveX контролов могут использовать цифровую подпись, которая только подтверждает, что данная вещь принадлежит автору, но ничего не говорит о самом органе. Internet Explorer имеет некоторые настройки безопасности, которые могут быть установлены в максимум (не принимать не подписанные ActiveX), в средние (давать предупреждение, но позволить решать пользователю) или слабые (принимать все без предупреждения). Разработчики подобно нам могут использовать средние, но конечный пользователь должен всегда использовать максимальный настройки безопасности.

Отвлекаясь от проблем с безопасностью, ActiveForm также требуется BDE на локальной машине (клиентская сторона) при использовании локальных баз и таблиц. Даже если алиас указывает, что база расположена на файл-сервере, BDE все равно должен быть установлен на клиентской машине. Использую MIDAS, TClientDataSets, DataSetProvider и Connection components, мы можем превратить ActiveForm в multi-tier приложение, когда база данных расположена на web сервере (или даже на отделном сервер баз данных).

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

Можно констатировать, что Delphi ActiveForm прекрасная вещь для Intranet.

Bug Report:ActiveX Controls in Internet Explorer 4.0 (or higher)

По заявлению Microsoft, "в связи с архитектурными изменениями в Internet Explorer 4.0 (и выше), что требуется для поддержки более широкого спектра более эффективных контролов, некоторые ActiveX контролы могут выполняться не совсем так, как это было в Explorer 3.0. Основная причина в том, что эти контролы разработаны не в Apartment Model Aware."

В Delphi 4 эта проблема разрешена и ActiveForm сделанные в Delphi 4 (и выше) теперь поддерживают Apartment threading model.

С помощью JBuilder возможно разрабатывать 100% pure Java апплеты, приложения., но мы не должны забывать и о том, что с помощью Дельфи так же можно создавать интересные Интранет решения используя такие вещи как ActiveFormsи web modules…

ActiveForm это великое решение для Интранет, когда само приложение исполняется на клиентской машине. Для подлинно независимых от платформы решений, мы должны сфокусировать наше внимание на web сервера. В этом случае, мы можем использовать Delphi для написания CGI или WinCGI приложений, или ISAPI/NSAPI (Internet или Netscape Server API) DLL расширений для web сервера. Мы можем использовать HTML на клиентской стороне, с помощью CGI форм посылая данные от клиента на сервер, в то же время в ответ генерирует динамические HTML страницы.

Написание CGI, WinCGI или ISAPI/NSAPI с помощью Дельфи не совсем тривиальная задача. Особенно переключение от одного решения к другому может оказаться очень трудным, так как поставщики продуктов третьих сторон, часто используют различные пути поддержки своих серверных Интернет приложений, например WebHub.

Delphi 3 и 4 Client/Server (а также Delphi 4 Professional с дополнениями) и Delphi 5 Professional часто приходят со специальными мастерами (Wizard) и компонентами для поддержки такого рода серверных приложений, называемых как Web Modules (или также известные под названием WebBroker). Используя Web Module, мы можем создавать CGI, WinCGI и ISAPI/NSAPI серверные приложения, и в этом случае мы можем переходить от одного типа к другому, самом приложение полностью абстрагируется от деталей реализации. Единственная разница (учитывая тот факт, что ISAPI DLL остается загруженным на Web сервере, а CGI EXE нет) в том что, ISAPI приложение легче отлаживать, используя IntraBob, чем CGI приложение. В существующем проекте с Web модулем отсутствует возможность определения, что используется, CGI или ISAPI/NSAPI приложение; только главный модуль проекта содержит эту информацию (которую можно изменить, что бы перейти к другому типу Web серверного приложения). Я думаю, что очень важная вещь: программист использует один набор компонент для обработки WebActions, WebRequests, WebResponses и т.д.

Используя специальный компонент WebDispatcher, мы можем даже мигрировать из существующих модулей данных (Data Modules) в Web модули. WebDispatcher встроен в обычный Web модуль, и используется для для диспетчеризации действия (Action) в Web модуле (Web серверное приложение может обрабатывать и выполнять разнообразные запросы и выполнять различные действия, для определения которых используется WebDispatcher).

Каждый WebAction может программироваться отдельно, но так же использовать что угодно их WebModule. Это включает все таблицы и бизнес правила, также другие процедуры и ресурсы. WebAction может напрямую писать в строку Response, или использовать один их трех специальных компонент для генерации динамических HTML и обслуживать запросы.

Компонент PageProducer используется для генерации динамических HTML страниц, включая специальные теги, которые могут использоваться для подстановки в run-time. Компонент DataSetTableProducer может использоваться для генерации динамических HTML страниц в табличном виде, используя колонки из таблицы базы данных. Вывод может полностью конфигурироваться, и требует наличия BDE на web сервере. Компонент QueryTableProducer подобен компоненту DataSetTableProducer, только использует запросы (query) вместо таблиц (table). Существует особая возможность использовать запросы с параметрами, встроенными в напрямую HTML CGI.