 |
Технология Клиент-Сервер 1998'3
|
|
|
БЫСТРО - это CWIC
Стив Паркер
Первым узлом, использующим Clarion Internet
Connect стал узел фирмы Sablesoft по адресу
http://sablesoft.brisnet.org.au. Благодаря Биллу Хелгесону -
сетевому инженеру фирмы Microbite (пользователь Clarion
и выдающийся сетевой гуру), появился второй по
адресу http://www.scnetwork.com:8080 a/k/a http://208.133.68.2:8080 (не
забудьте двоеточие).
Эта статья основывается на информации
о втором узле, просто потому, что я немного больше
с ним знаком: я делал приложения, которые были в
него включены. Здесь описаны приключения,
связанные с их установкой на World Wide Web и проверкой
корректности информации TopSpeed о продукте (Clarion
Internet Connect).
Прежде чем перейти к обсуждению
заявлений TopSpeed о CWIC (произнесение "квик"
было рекомендовано мне крайне авторитетным
источником), заметьте, что я не говорю о
"конвертации" моих приложений (в
действительности, однажды я использовал этот
термин и был больно побит со всех сторон
вышеупомянутым авторитетным источником).
Единственная конвертация состоит в переходе к
2003, если вы не сделали этого до сих пор, и если вы
назовете это "конвертацией". Как мне было
указано, достаточно корректно, вы добавляете
распределенный шаблон (template), убеждаетесь, что
ваш целевой .exe-модуль - 32-битный, и компилируете
приложение. И никаких изменений в арр-модуле. На
самом деле, выполнение расширенного
СWIC-приложения прямо из операционной системы
никак не проявляет его вторую сущность. Поэтому
правильнее говорить о "web-приспособлении"
CW-приложения (включении возможности
использования приложения в Web). В результате
создается то, что я называю "дуальным"
приложением, а TopSpeed называет "гибридным".
Любые .APP?
Первым утверждением Topspeed является то,
что Вы можете взять существующие приложения,
добавить распределенный шаблон и создать
Web-приложения.
Четыре из шести приложений, доступных
на нашем узле, были сделаны из существовавших
ранее приложений. Три были написаны для JOBTRAK
Corporation (для ведения списка работ университета), и
одно – это "библиотечная" программа,
которую я использовал для ведения каталога
статей о программировании на Clarion. Пятое
приложение? Я хотел посмотреть, поддерживает ли
CWIC С3 Development's Browse Form Temрlate (полный просмотр
записей). Хотя я уже знал, что пометка записей BoxSoft
работает (я использую ее в одном из приложений;
LIBs, не DLLs), поддержка шаблонов третьих фирм не
была и, по очевидным причинам, не могла быть
гарантирована TopSpeed (между прочим, шаблон
работает так же, как несколько функций из моей
персональной библиотеки). Шестое – книга записи
посетителей – единственное приложение,
специально написанное для узла Web.
В свете этого можно с уверенностью
сказать, что верно утверждение TopSpeed о том, что к Web
можно приспособить ранее существовавшие
приложения. В действительности даже гостевая
книга была написана и отлажена в 2003 в отсутствие
распределенного шаблона, который необходимо
было добавить с целью приспособления к Web.
Гибридные приложения?
Следующее утвеждение Topspeed – то, что
Web-пригодные приложения являются гибридными,
"дуальными". Это означает, что они могут
выполняться на Web и на локальных PC/сетях, ограждая
разработчиков от необходимости сопровождения
множества приложений, часто
многоязычных/многосредовых, удовлетворяя
разнообразные потребности разработчиков. (Даже
"editors choice" продукты этого не делают).
Действительно ли запускаются одни и те
же исполняемые модули на PC/сетях и на Web? Да.
Один шаг?
Это, возможно – одно из самых важных
утверждений Topspeed о продукте. Приложения,
присутствующие на моем Web-узле, были созданы в
различных релизах Clarion for Windows (генеалогия одного
из них восходит к CPD2.0, около 1991). После добавления
расширяющего шаблона и перекомпиляции в CW2003, я
запустил броузер и разработческую копию Clarion
Application Broker. Приложение работало на Web.
Так что приспособление СW-приложений
может быть одношаговым процессом.
Приложения вели себя по-разному в WWW и
на моем компьютере. В действительности, мое
первое впечатление до анализа того, что
происходило, – что они работали как-то странно.
Например, казалось, что проверка правильности
данных не работает. Поиск в справочниках не
производился, когда должен был бы. Иногда кое-что
срабатывало, когда я нажимал кнопку О'к, а
остальные проверки и поиски не работали вообще,
хотя должны бы были. Вычисление Run-time полей не
отображалось. Таким образом, рассматриваемый
обычный код не выполнялся, и часть
функциональности казалась утраченной. В
процессе дальнейших экспериментов я открыл, что
этот код на самом деле выполнялся, но не тогда,
когда я этого ждал.
По моему мнению, код, который
выполняется не тогда, когда ему положено, - хуже,
чем тот, который не выполняется правильно или
совсем не выполняется. Неверный код я могу
отладить. Но если код выполняется в другое время,
все мои усилия по отладке бесполезны.
Опуская путь к пониманию, почему это
было так, могу сказать, что разница между
запуском приложения на PC'cети и на Web зависит от
"природы зверя" (Internet). В своей
непредусмотрительности я забыл, что такое Internet.
Необходимо помнить, что целью Internet является
обеспечение платформы для независимого обмена
информацией. При описании приложений баз данных
мы часто используем метафору файловых каталогов.
Метафора крайне неупотребима к Web. Гораздо более
точная метафора – буклет.
Host (сервер) представляет страницы
(секции буклета). Эти страницы – статические. Это
важно для того, чтобы сделать их видимыми для
любого вида клиентов. Но, как только вы
добавляете встроенный код, вы создаете
необходимость динамической печати страницы. Да,
но печать страниц так не работает и никогда не
будет. В самом деле, одна из основных направлений
переднего края распространения HTML, броузеров и
Web-серверов – это более динамичные страницы,
обычно с использованием таких вещей, как JavaScript и
Java (которые позволяют клиенту "менять"
страницу динамически, но существующие
исполнения противоречивы).
Если, например, Вы добавляете код для
проверки данных в элементa управления Event:Accepted
,то, как разработчик на Clarion Вы предполагаете, что
он выполнится, когда пользователь завершит ввод
в поле, так как Accept() генерирует событие по
завершении обработки управляющего элемента.
Web-страницы ведут себя иначе: события не выдаются
по принципу поле-за-полем. На самом деле, сервер
"печатает" и предоставляет страницу.
В пригодном для переноса в WWW
CW-приложении оператор ACCEPT завершается, только
когда нажимается кнопка. В зтот момент Ваш код
исполняется. Поэтому Web-пригодные приложения
ведут себя так, как будто цикл ACCEPT исполняется
единожды, когда нажаты кнопки OK или Cancel.
Вот что действительно происходит.
Когда пользователь нажимает OK, содержимое
страницы возвращается на сервер и выполнение
программы продолжается на сервере (в CWIC это то,
что позволяет поддерживать положение дел; при
использовании стандартных Web-серверов, сервер
выполняет то, чего требует скрипт-файл и ожидает
следующего запроса). Это фундаментальное отличие
от подхода, который мы использовали. В сети все
исполнение программы производится на клиентской
станции. Даже в приложениях, выполненых в
соответствии с технологией клиент/сервер
большая часть работы исполняется на клиенте
(заметным исключением являются возвращение
требуемых записей и проверка ссылочной
целостности). В Internet клиент - это немногим больше,
чем устройство ввода-вывода, а большая часть кода
выполняется на сервере.
Единичный цикл ACCEPT объясняет, почему
часть моих lookups не выполнялась. Они все были
написаны вручную и, так как я не хотел их
исполнения во время non-stop режима при работе в
сети, я заключил их в ...
IF ~{Prop:AcceptAll}
!lookup code
END
Когда кнопка OK нажата, Prop:AcceptAll=True. Даже
если поля имели неверные значения или не имели их
вовсе, условие не выполнялось, и код делал то, что
и предполагалось: ничего.
Вообще, Web-страницы посылают события
только двумя предопределенными методами: Get или
Post, – и двумя типами действий (Submit или Reset;
настоящим же "действием" обычно является
скрипт), которые связаны с кнопками на форме HTML.
Это – часть спецификаций HTML. Вот какова природа
Internet.
Приспособление CW-приложений и
прогнозирование исполнения Вашего, зависящего
от событий, кода сравнимо с произведением
операций над файлами с использованием только
текстового редактора.
Поскольку мои приложения содержат
много встроенного кода и используют много
процедур c шаблоном типа Source, я столкнулся с
серьезными проблемами программирования. Дело
было не в том, чтобы мои приложения работали. Они
работали. И не в том, чтобы все, что должно
произойти, происходило. Происходит. Дело в том,
чтобы вещи происходили в порядке, имеющем смысл
для пользователя (включая меня).
Один из самых больших мифов Windows - это
то, что пользователь "управляет". Если Вы на
это купились, то Вы – в глубоком заблуждении. У
пользователя ровно столько возможностей для
управления, сколько я ей (ему) даю, и не больше.
К примеру, lookup, случающийся после
нажатия ОК, не кажется мне имеющим смысл. Поэтому,
пока я оставлял проверку данных на месте, я также
добавлял кнопки, следующие за полями. В кнопках я
встроил такой же вызов lookup-процедуры, как код,
присваивающий возвращаемое значение целевому
элементу управления (target control). В моей обычной
практике - обеспечивать обе формы проверки: одну
– в пункте Actions элемента управления и одну – в
кнопке, следующей за полем. Это дает пользователю
два способа получения допустимого значения в
поле. В этот раз это был один из редких случаев,
когда я сделал не так.Пока это делает мое
приложение более похожим с виду на стандартные
приложения Web (а я не думаю, что это особенно
хорошо) и дает ему преимущества Web-стандарта.
Можно ожидать, что пользователь Web поймет его с
первого взгляда. И это значит, что она/он знает,
что делать с кнопками. К тому же, это делает
понятным любой очередной lookup, когда он появится.
Если пользователь не воспользовался кнопкой и
ввел плохое значение (или не ввел никакого),
появится lookup (помните, что я не убрал изначальный
код проверки данных). Но в этот момент ваши
пользователи должны будут понять, почему lookup
появился, когда они это сделали. Так как эта
кнопка предназначена только для выполнения в
Web-режиме, я могу предотвратить ее появление,
когда приложение не работает в Web. Я использую
метод Active объекта Broker во вставке After Opening Window:
IF ~(Broker.Active)
DISABLE(?LookupButton)
HIDE(?LookupButton)
END
Похожим образом, если есть код, который
я хочу выполнять только в Web:
IF Broker.Active
ENABLE(?Find2)
END
Требуется
переосмысление?
Итак, проверка данных работала, но не
тогда, когда я этого ждал. И это было причиной
моего промаха (а не недостаточное чтение
литературы). К счастью, простое решение нашлось
само собой. В других случаях все было не так
просто. Я упоминал приложение для инвентаризации
статей о Сlarion. Когда я ввожу объем и источник,
приложение вычисляет месяц и перемещает курсор
внутри поля для ввода года. При работе в Web этого
не случится, пока не будет нажата кнопка. Это –
тот случай, когда я не хочу, чтобы код выполнялся,
и пакую его в...
IF ~Broker.Active
Code goes here
END
Да, я потеpял функциональность, но что я
могу поделать? (Почему я должен был ее потеpять?
Потому что вычисление месяца и pазмещение куpсоpa
пpоизойдет только после нажатия кнопки, то есть
после того как я уже ввел дату!)
Таким обpазом, пpи пpогpаммиpовании для
Web важно учитывать тот факт, что цикл Accept не
делает прохода на каждом элементе упpавления. Это
означает, что мы должны пpосматpивать каждый
элемент упpавления и pешать (и вpемя от вpемени
обнаpуживать, что это тяжелый путь), какой код
пpигоден для Web,а какой нет – выполняется ли он
как вы того ожидали, или нет. Коpоче говоpя, Вам
необходимо пеpемещать, пpизнавать негодным
встpоенный код или обеспечивать ему
альтеpнативный по следующим кpитеpиям:
- Можно ли безопасно пеpеместить код внутpь события OK
Accepted для обоих опеpационных режимов?
- Допустимо ли выполнение на стpанице Accept?
- Может ли код быть запpещен к выполнению на Web?
- Должен ли код выполняться только на Web?
- Должен ли код выполняться в обоих режимах (когда
кнопка ОК - не ОК)?
Что касается меня, то мое довеpие к
встpоенному коду на Web уже достигло минимума, и я
сеpьезно поpазмыслил, как же пpогpамма должна бы
была себя вести на Web. Я думаю, что это ключ к
успеху Web-пpиложений: Web pаботает по-pазному,
значит, и мои пpиложения должны pаботать
по-pазному.
Код, который должен выполняться.
Это, действительно, единственный
тpудный случай: потому что он должен выполняться,
но, если это зависит от случайности, как часто
бывает, – не выполняется. Значит, должны быть
найдены пути это пpеодолеть.
Lookup, локатоp и код пpовеpки тpебуемых
полей должны, на мой взгляд, выполняться
независимо от опеpационного режима. Lookup и
локатоpы не могут быть обоснованно пеpенесены в
конец Accept loop, пока пpовеpка тpебуемых полей, как ей
это свойственно, находится в конце Accept loop.
Как было отмечено, можно довольно
точно упpавлять lookups с помощью кнопок.
Оказывается, похожим обpазом можно обходиться с
локатоpами. Я скопиpовал стандаpтный код lookup из
сгенеpиpованного исходного текста в кнопочное
Event:Accepted, и его функции - в точности такие же, как у
любой дpугой кнопки Web Find или Search.
Тpебуемые поля были чуть поинтеpеснее.
Бpокеp возвpатит стpаницу, если вы делаете пpовеpку
тpебуемых полей, и одно из них - пустое. Но, так как
бpoузеp упpавляет куpcopoм, пустое поле не будет
выделено. Это, я думаю, излишне запутывает (если
не пользователей, то меня - несомненно).
Возможны несколько pешений (помните,
что никаких изменений - для PC-режима). Вы могли бы,
напpимеp, послать пользователю сообщение с
названиями полей, вызывающих этот код только пpи
Broker.Active. Большинство Web-пpиложений, котоpые я
видел, делают именно так.
Или вы могли бы иметь набоpы
дополнительных фоpм (по одному для каждого поля),
вызываемых пpи условии, что бpокеp активен, а поле
пусто. В общем, легкого pешения нет.
Что окончательно меня добило, так это
то, как CWIC-пpигодное пpиложение по умолчанию
фоpматиpует стpаницы: две из опций pасшиpения могут
быть скомбиниpованы для динамического сокрытия
отключенных управляющих элементов. Дано, что
текущая стpаница должна быть обновлена, но почему
бы не отключать уже заполненные упpавляющие
элементы? Это дало бы основание их скpыть, и
оставить на экране только пустые поля. Это также
означает уменьшение размера страницы, которое
дает ускорение процесса обновления экрана, что в
свою очередь даст ускорение возврата страницы и
уменьшение трафика (неплохо ведь, когда
одновременно решается несколько проблем?). Что до
меня, то я пpосто отключил все необязательные и
некоторые обязательные поля, заполненные
значениями. Поэтому при воспроизведении
страницы на ней были только поля (требуемые) без
значений. Я переустанавливал заголовок, чтобы
пользователь мог знать, почему страница была
предъявлена:
IF Incomplete()
IF Broker.Active
DISABLE(?pre:not_required_field:prompt,?pre:not_required_field)
QuickWindow{Prop:text} = 'Please complete required fields'
IF pre:field<> ''
DISABLE(?pre:field:Prompt,?pre:field)
END
END
SELECT(Incomplete())
IF Broker.Active
ForceRefresh = True
DO RefreshWindow
END
CYCLE
END
Этот код идет в разделе Accepted кнопки Ok
до встроенного сгенерированного кода. В
действительности, это – просто модификация
моего стандартного кода проверки обязательных
полей.
"Просто" тянет за собой страшное
количество кода. Но это того стоит.
Прочие соображения.
Я убежден, что для эффективной работы в
CWIC важно по меньшей мере изучить основы HTML.
Существует много хорошей литературы, которой
можно воспользоваться. Я слышал, что есть даже
узлы World Wide Web, посвященные этой теме.
Вы можете также взять для изучения
первоисточник со страниц, которые вам
приглянулись (это мой собственный излюбленный
метод, и я считаю, что он дает больше, чем изучение
спецификаций HTML).
Используя стандартный НTML, например, вы
можете сделать стандартную домашнюю страницу
входом в ваши приложения. Это - то, что вы увидите
на моем узле.
Я думаю, полезно, когда у вас есть
некоторое число приложений, которые вы хотите
выполнять на одном узле, но не хотели бы вызывать
их из одной Frame-процедуры(то есть, создать новое
приложение, включающее процедуры всех других
приложений).
Из-за того, что при работе в Web события
не отсылаются способом, который использовали
ранее(в PC-режиме) для их отправки, ваш код будет
себя вести в Web-режиме не так, как ожидается.
Поэтому вы не можете полностью отладить
приложение кроме как при работе в броузере.
Конечно, это значит также, что
процедуры, созданные wizard, и процедуры без вставок
прекрасно действуют в Web и не требуют
специального рассмотрения. Аналогично, вставки
после кнопок тоже склонны работать без
изменений, так как кнопки, сгенерированные как
Submit в HTML, пересылают события правильно (то есть
тем же способом, что и РС-приложение).
Наконец, я верю, что очень важно
переосмысливать приложения, если вы взялись
приспосабливать их к Web. Фактически, даже
несмотря на то, что on-line документация обещает
лучше поддерживать управляющие события, я не
уверен, что мы захотим воспользоваться этим в
полной мере.
Если один и тот же код исполняется в
обоих режимах, почему бы этим на воспользоваться
в полной мере. В зависимости от того, как TopSpeed это
сделает, обработка событий на уровне управляющих
элементов может повлечь скачок
производительности, так как посылка событий
стандартными путями требует рейса на сервер и
обновления страницы HTML. Другие методы пересылки
событий могут включать подкачку на клиента
дополнительных классов. Бывают ли случаи, когда
мы хотим достичь лучшей производительности? Вне
всяких сомнений! Хотим ли мы мы достичь этого для
задачи управления множеством полей в
единственной процедуре? Это надо еще посмотреть.?
С вопросами и предложениями
обращайтесь digraph@rinet.ru
Copyright © 1994-2016 ООО "К-Пресс"
Home
Поиск
Издания
Контакты
