Вступление
Как известно, начиная с 9-ой версии, в Sybase ASA появилась возможность использовать ее в качестве самостоятельного небольшого веб-сервера и создавать на WatcomSQL веб-сервисы с поддержкой RAW, HTML, XML, SOAP и DISH. Так же были добавлены системные процедуры и функции, позволяющие производить различные полезный операции при работе с вебом (например манипуляции с урлами, переменными форм и т.д.). Не сказать, что присутствуют все необходимые с точки зрения веб-программиста функции, но основной базис есть.

Предисловие
Еще с прошлого года я посматривал на веб-сервисы ASA, но особого применения им не находил, так как был занят и главное не было реального места в проекте, где их можно было бы использовать. Совсем недавно я столкнулся с проблемой генерации сложных по форме и заполнению форм строгой отчетности (отчеты по ЕСН, НДФЛ, кадры и т.д.). Такие отчеты невозможно нормально реализовать на бэндовых отчетниках, будь то Crystal Report, PB DataWindow или другой. Плюс такие отчеты желательно выгружать в редактируемый формат, чтобы перед печатью пользователь мог его изменить. Как следствие, обычно они реализуются как макет в MS Word и через COM/OLE заполняются нужными данными. Такой подход имеет много слабых сторон:
1. Тиражный продукт привязывается к чужому ПО и требует его инсталяции.
2. Макет и код его заполнения никак не связаны, поэтому изменяя макет, приходится потом переписывать код.
3. Код получается сложным, вперемешку с логикой получения данных с БД, бизнес-логикой заполнения макета и логикой работы с интерфейсом OLE.
4. Скорость работы получается достаточно низкой при использовании OLE/COM технологии для заполнения макета.
5. Нет возможности поддержки из за использования специализированных протоколов кросс-независимых отчетов, способных открываться и изменяться не только в MS Word, а например в Open Office (или же придеться все генерить через Ворд, сохранять и открывать в Open Office).

Думаю при желании недостатков подхода генерации через Word можно найти еще много. Соотвествующе я вспомнил об веб-сервисах ASA и с учетом того, что моя БД работает на ASA, решил попробовать покопать в сторону разработки отчетов на HTML.

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

Так как основным требованиям отчета является его возможность открытия в MS Word и Open Office, то первым делом было выясненно именно это. Как оказалось, если в стилях генерить соотвествующие тэги, то можно добиться соблюдений условий форматирования, отступов, размеров страницы, перевода страницы и даже характеристик документа как в Word, так и OpenOffice. Сами браузеры игнорируют большинство таких управляющих тэгов, однако было выявлено, что они так же при печати различают тэг перевода страницы.

Вторым шагом были рассмотрены и изучены принципы работы ASA как веб-сервера. Как и предполагалось, ничего там сложного не оказалось, сервер запускается с параметром "-xs http(port=80)" и по указанному порту начинает принимать http-запросы. Для организации сервисов возврата HTML-страничек предусмотренны веб-сервисы с типом RAW, в теле которых должен быть указан запрос, возвращающий данные. На веб-сервис можно указать уровень доступа к нему (по логину, анонимный) и режим защищенной работы. Для веб-сервисов в ASA автоматически существуют расширения, позволяющие во первых управлять уровнем вложенности урлов и работы с переменными, полученными с клиентской сессии, обращение к которым элегатно сделано в форме ":ИмяПеременной".

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

Что получилось после одной недели изобретения велосипеда
Получилась технология построения динамических веб-страниц на основе макета HTML, с возможностью использования выборок на SQL, макросов и возможностью регулирования формирования потока контента на WatcomSQL, которой я присвоил кодовое название WebSQL. На текущий момент она поддерживает:
1. Секции - позволяют выделить определенный фрагмент HTML документа, описать на него запрос и при генерации страницы повторить его столько раз, сколько было возвращего записей с указанного запроса. Поддерживается неограниченный уровень вложенности секций. В запросе секции разрешается ссылаться на поля родительских секций (особенно полезно для связи) и формировать части запроса динамически (например разная сортировка в Order By).
2. Алиасы - позволяют ассоциировать поля с алиасами, использующимися в теле текста секции. Например если в секции указать алиас "F1" на поле "Field1", то везде в тексте вместо "F1" при ее построении на каждую запись запроса секции будет вставлено значение поля "Field1". Для алиасов определена локальная область видимости, то есть замена алиаса на поле будет производиться только в теле указанной секции и не действительна во вложенных секциях. Разрешается обьявлять алиасы на поля родительских секций, что позволяет использовать в теле секции значения полей родительских секций.
3. Локальные переменные и параметры ХП - позволяют определить для секции локальную переменную, указать для нее тип SQL и инициализационное значение (любое допустимое в WatcomSQL выражение). Имеют область видимости, где дочерние секции могут видят локальные переменные родителей, но имеют право создать собственные переменные, которые именами перекрывают переменные родительских секций. Для отображения значений переменных в теле секции необходимо так же ассоциировать их с алиасами.
4. Макрокоманды - позволяет в любом месте документа на WatcomSQL описать необходимую логику действий. Поддержка вставки внутри макета HTML операторов WatcomSQL дает всю мощь этого языка по управлению формированием динамической страницы и позволяет выполнять любую логику действий - от ветвления формирования документа, до поддержки аггрегированных действий на основе локальных переменных, определения собственной бизнес-логики, вызова ХП и т.д. Ограничений на использование в макрокомандах скриптов WatcomSQL нет.
5. Макросы - позволяют описать именованный блок текста, внутри которого разрешается ссылки на нумерованные параметры. Далее разрешается вызов макросов из любого места документа по его имени и с передачей параметров. Макросы позволяют создавать повторно используемые фрагменты текста, тэгов, параметров для тэгов, вызовов макрокоманд и любых других часто используемых фрагментов текстов. В теле макросов допускается вложение других макросов, что позволяет создавать эффективную иерархию повторно используемых решений. При обьявлении в секциях макросы имеют область видимости, где дочерним секциям разрешается использовать макросы, обьявленные в родительских секциях, но с правом переопределения макроса с существующим в родительской секции именем. Так же поддерживается библиотеки публичных макросов, в которых можно хранить общие и стандартные макросы, которые потом можно задействовать во множестве документов. Библиотеки являются именованными с поддержкой уровня вложенности модулей (например, "СтандартнаяБиблиотека.ПотокКонтента.Неформатированный"). Для библиотек и их иерархий модулей существуют аналогичные секциям правила области видимости макросов. Для использования в документе макросов публичных библиотек их необходимо обьявлять в секциях, указывая полный к ним путь. В теле секции возможно как обьявление использования всех макросов библиотеки (например "Библиотека.*"), так и перечисление конкретных используемых макросов (например "Библиотека.Модуль.Макрос1"). Для публичных макросов поддерживается возможность указания их алиаса при обьялении в теле секции, что позволяет обойти ограничение на уникальность имен макросов в теле секции или же перекрыть ранее обьявленный в родительской секции макрос с одной библиотеки макросом с таким же именем, но другой библиотеки.

Как это работает
WebSQL в полном смысле слова является компилятором макетов HTML в скрипт ХП на WatcomSQL. На вход ему нужен только текст макета. На выходе он создает в Вашей базе данных готовую хранимую процедуру на WatcomSQL, уже содержащую весь код генерации странички. Соотвествующе далее ASA компилирует ее в байт-код и далее к ней применимы все обычные правила по отношению к хранимым процедам в ASA (организация прав доступа пользователей, возможность скрытия исходного текста, работа в профайлере и дебаггере и т.д.). Еще одним плюсом компиляции является то, что в конечном приложении нет необходимости держать HTML макеты страниц и отчетов. Для организации возврата результата хранимой процедуры через веб теперь достаточно создать соотвествующий RAW веб-сервис, в теле которого поставить вызов этой процедуры c передачей в качестве параметров именнованных переменных, переданных клиентской сессией:

Весь движок WebSQL полностью написан на WatcomSQL и оформлен в виде отдельной базы данных. Для его инсталяции достаточно запустить на сервере ASA базу данных WebSQL.db. Если ASA запущена с поддержкой протокол http, то возможно использование в качестве клиентского приложения собственные веб-сервисы WebSQL через браузер. Планируется сделать на веб-сервисах полный интерактивный сайт для просмотра и изменения его настроек компилятора, работой с библиотеками макросов, страницей интерактивной компиляции макета с указанного HTML файла в скрипт хранимой процедуры в указанный файл sql и помощи по командам, библиотекам макросов, входящих в комплект стандартной поставки и пошаговому обучению работы с ним.

Так же возможно подключение и использование WebSQL для своих баз данных. Для этого необходимо запустить скрипт "install.sql", который подключит WebSQL в качестве удаленного сервера, ассоциирует удаленного юзера с локальным, подключит нужные удаленные хранимые процедуры и создаст специальные процедуры, позволяющие прямо из родной базы данных вызывать компиляцию макетов с автоматическим их созданием в базе данных. Для очистки обьектов WebSQL в базе данных так же существует скрипт uninstall.sql.

Где еще можно использовать WebSQL
На самом деле, являясь макро-технологией, WebSQL можно использовать везде, где необходимо по макету строить текст. Тут все зависит от полета фантации - начиная с генераторов текстовых отчетов и заканчивая генератором SQL скриптов по указанным обьектам базы данных (причем вполне возможно в дальнейшем расширить функциональность компилятора до уровня поддержки множества диалектов и генерации скриптов хранимых процедур не только на WatcomSQL, но и для того же PL/SQL).

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

За неделю написания этой технологии времени на создание примеров и уж тем более сайта, конечно же у меня не было. Сейчас в публично в интернете выложена в качестве демки одна страничка , макет которой я за 5 минут нарисовал в OpenOffice (он меньше тэгов по сравнению с Вордом генерит). Далее я еще потратил 10 минут на программирование этого макета, где помимо запроса на секцию, в которой HTML-таблица заполнялась записями с Customer, я организовал группировку по штатам (без вложенной секции, методов сортировки по штатам и отслеживания изменения штата), порядковый счетчик и 2 макроса для организации поддержки сортировки по колонкам HTML таблицы. Внизу странички есть ссылка на "чистый" HTML макет, на основании которого и была сгенерирована ХП, которая возвращает указанную страничку. Скорость генерации на моей домашней машине странички довольно высокая - время выполнения ХП составляет 20 мс.

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

Насчет сотрудничества
С учетом того, что технология будет SHAREWARE, причем с патентом и закрытыми при продаже исходниками, мне будет сложно одному попытаться ее раскрутить в пределах СНГ и за рубежом. Я бы не отказался взять в партнеры человека, который дружит с веб-дизайном, Java-скриптами и другими разными веб-технологиями. В паре с ним мы бы составить тандем, где я продолжать бы
наворачивать движок и начинать рисовать прототипы баз данных под различные решения (форумы, аукционы, новостные каналы и т.д.), а он бы сделал сайт под WebSQL и наращивал стандартные библиотеки макросов лучшими наработками веб-программирования.

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

P.S. Гм, после такого большого официального документа, хотелось бы просто услышать мнение уважаемых коллег, насколько действительно все это перспективно и интересно в первом чтении - а вдруг меня просто переклинило и я пытаюсь делать и толкать продукт, который никому не будет нужен :)

Технология и не подразумевает конкуренцию с бэндовыми отчетниками. Хотя бы по причине того, что пришлось бы реализовывать программный расчет высоты страницы HTML для перевода страниц. Лучше всего эта технология подходит для генерации динамических веб-страниц, создания отчетов с фиксированными страницами и организации пользовательского интерфейса через веб. Самое главное преимущество, как мне видиться в ней - это то, что не нужно использовать для этих целей сторонние средства и ПО, а так же изучать другие технологии и языки программирования. Фактически уже зная язык разметки документов HTML и являясь специалистом по проектированию баз данных на ASA, уже можно легко делать различные решения, причем все будет идти на языке хранимых процедур WatcomSQL. В итоге у нас получается самодостаточная база данных (не требуется даже инсталяция веб-сервера на ОС - IIS или Apache), которая и данные хранит, и бизнес-логику серверной и клиентской части реализует, генеря сайты и отчеты (в идеале хотелось бы выйти на приличную функциональность построения тонкого клиентского приложения прямо на браузере). Естественно, технология не способна обхватить различные направления и ньюансы создания интернет и интранет проектов, но как Вы сами правильно заметили, на Java существует достаточное кол-во решений, их охватывающих. С учетом того, что в ASA разрешена работа с Java, то это расширяет возможности моей технологии, позволяя подключать к собственным базам данных решения на Java как компоненты и используя их в более легком в освоении WatcomSQL, использующегося в качестве базового языка технологии WebSQL (можно привести аналогию с VB, который использует компоненты низкоуровневых языков). В итоге всегда можно подключить как бесплатный или коммерческий пакет Java, отвечающий за работу с электронными деньгами, генерящий графики, сложные групповые и кросстаб отчеты и т.д.. Особых ограничений на использование Java классов и хранение Java обьектов в ASA нет (если не считать бесплатной регистрации в Sybase для получения лицензии Java на ее использование в ASA).

Во первых, я хочу оспорить пару утверждений. Если вы не против, конечно :)
Я только за :)


ASCRUS
2. Макет и код его заполнения никак не связаны, поэтому изменяя макет, приходится потом переписывать код.
3. Код получается сложным, вперемешку с логикой получения данных с БД, бизнес-логикой заполнения макета и логикой работы с интерфейсом OLE.

Конкретно вот эти два пункта. Дело в том, что у меня уже довольно давно работает аналогичная система - Дельфийский GUI предлагает пользователю выбрать параметры отчета, запускает через SaVCL пачку ХП, и их резалтсеты забрасывает в MS Excel, для этого используется библиотека FlexCel. Связка между ХП и шаблонами отчетов только в наименовании колонок. При добавлении нового отчета или изменении старого приходится следить только за тем, чтобы поле резалтсета упомянутое в шаблоне действительно существовало в резалтсете. Итого: работа с OLE однажды сделаная, более не трогается.
В качестве примера я предлагаю рассмотреть отчет для зарплаты НДФЛ, состоящий из кучи листов строгой отчетности. Заваять их на Word или Excel представляется мне нелегким делом.


Можно ли в этот "текст макета" запихать команды управления процедурой? Например те же самые grant execute...?
Можно посмотреть результат компиляции макета?

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

авторЭ??? Данный WebSQL.db это что, "чистая" БД которую предпологается наполнять реальными таблицами/данными/процедурами? Может лучше оформить проект как скрипт который можно было бы наложить на существующую базу?
Действительно WebSQL реализован в чистой БД (размер страницы 1024), в которой лежат системные обьекты движка - таблицы и ХП. Их владелец DBA закрыт паролем и для пользования базой данных предлагается 2 логина - администратор и пользователь. Скриптом проект оформлять не хочется по 2 причинам:
1. Надо же как то защищать свои авторские права от просмотра текста хранимых процедур, где используются некоторые уникальные как я считаю наработки.
2. WebSQL и не нужен в конечной базе, так как он сам при компиляции не привязывается к обьектам этой базы - его задача из макета вернуть скрипт полноценной хранимой процедуры, которую потом можно просто наложить на нужную базу данных. Далее уже для работы этой процедуры ни макет, ни WebSQL не требуется.

авторЗачем нужен удаленный сервер?
Удаленный сервер нужен только в случае, если Вы хотите, чтобы WebSQL не только генерила скрипты ХП по макетом, но и автоматом их создавала. Для этой цели БД WebSQL подключается как удаленный сервер, далее подключается удаленная ХП sp_web_Compile и создается локальная ХП sp_web_CreateProc, которую теперь можно вызывать прямо из соединения своей БД, передавая ей имя файла макета и хранимой процедуры, на что она автоматически в Вашей базе данных создаст по макету указанную процедуру.

авторЕсли речь идет о распределении web и db серверов по разным физическим компьютерам, то лично я предпочел бы поставить на удаленном компьютере обычный http сервер и ходить к базе данных через ASP/ADO если в качестве http-сервера будет IIS или Perl/PHP с их библиотеками если сервером будет стоять Апач.
Вполне реально держать на внешнем слое Apache + ну и тот же PHP для реализации основной логики веб-приложения, а всю бизнес-логику на ASA во внутреннем слое, где PHP подгружает с веб-сервисов нужные HTML странички с ASA. А для внутренних нужд (интранет-сайты) можно вообще просто ставить прокси + ASA и все крутить (сейчас по указанной мной ссылке на демку именно все таки и крутиться).

авторЗавязывать DB сервер на работу с http имеет смысл только если данный DB сервер единственный доступный сервер. Если же в офисе организована нормальная LAN с DB-сервером внутри LAN, а доступ снаружи в LAN перекрыт файрволом, то использование выделенного "классического" http сервера становится единственным решением.
В данном случае ASA является классическим http сервером и я не вижу отличий от того же Апача (хотя каюсь - может быть не знаю всех его особенностей).

авторЧто-то использованный в показаном макете язык не очень то похож на WatcomSQL :)
Язык почти прозрачен, но к сожалению тяготеет к лапшеообразности. В частности использование переменных до их формального описания. Смесь собственных операторов и html текста тоже не добавляет читабельности. В общем, я пока не особо в восторге.
Во время предварительного чтения данного описания, я предполагал что-то типа ESQL текста, только вместо C/PowerScript чтобы был html текст. Оно по моему было бы намного проще в сочиненнии макетов.
Языка как такового в WebSQL нет. Есть макет, внутри которого вставлены управляющие команды его формированием. Самый близкий аналог - это та же похороненная Microsoft технология ASP. Не нужно макет воспринимать как программу. Ее нужно воспринимать как описанный документ, в теле которого с помощью SQL секций, WatcomSQL операторов и макросов описана бизнес логика, влияющая на формирование контента документа. Поэтому сравнивать макротехнологии с языками программирования честно говоря не корректно. С лапшеобразностью я ничего к сожалению поделать не могу, так как мне пришлось следовать по стопам MS Word-а (причем параллейно, так как я сам пытался подобрать семантику языка) и пользоваться для вставки макрокоманд тэгами комментариев. Причина этого кроется только в невозможности в HTML описывать собственные тэги, соотвествующе ввод несанкционированных тэгов повлек бы за собой возмущение различных дизайнеров и редакторов кода HTML. С другой стороны WebSQL не сильно привязан к определенным формальностям описания макросов и в любой момент я могу его расширить до уровня поддержки любых диалектов, заданным пользователем.

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

авторЛично мне была бы очень интересна библиотека типа уже упомянутого FlexCel, под Delphi или Java, а лучше и под то и под другое. Принимающая на вход шаблон отчета и пачку резалтсетов и формирующая html.
С точки зрения кодера да. С точки зрения проектировщика БД лично мне ближе получается для генерации сайтов WebSQL, хотя бы потому, что я не хочу пользоваться алгоритмическими языками типа Delphi или Java, или учить правила и особенности какого нибудь отчетника, когда я прекрасно умею проектировать базы данных, писать запросы и реализовывать логику на WatcomSQL.

авторНо если уходить от специально написаного клиента и использовать в качестве клиента стандартный браузер, то наилучшим решением на мой взгляд был бы модуль для http-сервера реализующий ESQL внутри html.
А именно так все и есть :) Наглядный пример генерации текстового отчета по таблице:
После генерации макета, компилятор WebSQL (ХП) вернет примерно такой код в виде выборки, состоящей из одной записи, c long varchar полем Content:
Далее по желанию этот код или будет оформлен, как тело ХП, или же Вы просто его сможете выполнить в ISQL, динамическом SQL, сохранить в файл скрипта SQL и т.д. и т.п. Причем как видно, уже ни WebSQL, ни сам макет уже не нужны.

авторНасколько надежен/функционален встроенный http-сервер в АСА?
Поэтому я выбираю Apache/PHP.
Насчет надежности - есть поддержка защищенных режимов работы и аутенфикации пользователей по таким же принципам, как и подключение к БД по другим протоколам связи. По функциональности опять же - сам веб-сервер особо ничего не делает - его задача через веб-сервис открыть сессию, залогиниться, выполнить уже нужный запрос или хранимую процедуру и вернуть полученный результат клиентской сессии. То есть в данном случае функциональность и скорость работы - это показатели работы сессий ASA и ее характеристик нагрузок как СУБД, а не как веб-сервера. Еще раз могу подчеркнуть, что использовать Apache и PHP не представляет собой трудности - ASA не обязательно запускать на 80 порт и ее можно сделать внутренним локальным сервером на закрытом для интернета порту, к которому будут обращаться тот же Apach и PHP. Далее уже определение степени интеграции логики на части ASA и части других средств будет зависеть только от программиста.

White Owlугу... кажется понял.
То есть, практически данный подход предполагает, что на каждый отчет, у нас будет одна хранимая процедура. Которая будет не только вытягивать несколько резалтсетов из БД, но и склеивать их в один, уже отформатированный, html.
Результатирующий html можно выдавать в клиентский браузер напрямую из ASA (если в нем будут уже объявлены заголовки), либо брать этот html и вклеивать его во внешний html (с заголовками, баннерами, счетчиками, и всякой другой фигней).
Внешний html может быть так же организован как ХП с ASA в качестве http сервера или ASP/SHTML страничка на классичком http сервере.
Так?

Угу, все так. В принципе как я уже и говорил на самом деле макрогенератор вообще ничего о языке макета не знает, поэтому макет чего он будет строить - HTTP с заголовками, без заголовков, макет SQL-скрипта, генератор XML или еще чего - это уже дело вкуса того, кто макет рисует :)

White OwlОстается вопрос, почему в качестве средства реализации был выбран сам ASA/Watcom SQL? Может имеет смысл сделать такой конвертор WebSQL -> WatcomSQL в виде обычной программы? Потом добавляем к ней менеджер проекта, в проекте регестрируем пачку шаблонов, и.... По большой, толстой, красной кнопке все обновленные шаблоны уже в виде готовых ХП отправляются в рабочую БД? :)
Кстати, подобный внешний, не привязаный к ASA конвертор мог бы работать и не только с ASA, но оно и под любой другой сервер заработает. Если конечно знать диалект этого сервера или использовать строго SQL-92.
Это конечно дико будет звучать, но на WatcomSQL у меня больше развязаны руки по доработке и расширению функциональности движка, чем если бы я это делал например на Java. Все что я описал по функциональности весит ровно 5 хранимых процедур и занимает на текущий момент примерно 500 строчек кода с обширными комментариями, которые я так люблю вставлять на любой чих в коде :) Я очень сильно сомневаюсь, что на Java я смог бы за неделю на классах реализовать подобную функциональность, с подобным кол-вом кода, чтобы все с первого раза заработало и легко расширялось и модифицировалось по функциональности :) Плюс так как я планирую хранить различные данные по движку (конфигурация, библиотека макросов, еще чего нибудь), то мне по любому бы пришлось задействовать базу данных, а из за этого бы пришлось подключать JDBC, делать бизнес-логику контроля за уникальностью имен обьектов и т.д. и т.п. В данном случае решение на WatcomSQL позволяет мне использовав всю мощь языка запросов и функциональности ASA обходиться малой кровью, да еще и без всяких интерфейсов доступа, причем компиляция занимает миллисекунды. В конце концов и сам MacroSQL именно на это и расчитан - ничего лишнего, зачем нам интерфейсы доступа на SQL для генерации HTML, когда мы внутри сессии и так видим, все что нам надо. В случае же написания компилятора на внешнем по отношению к ASA языку мы получаем проблемы с отладкой компилятора, поддержкой кроссплатформенности на разных ОС, более сложной инсталяции (БД надежнее и легче скопировать и подключить к другой БД, чем внешний выполняемый модуль к указанной БД) и еще и лишний язык для сопровождения компилятора. Ну и напоследок хочу добавить, что я так привык к вкусностям WatcomSQL и настолько привык думать множествами и запросами, что мне честно говоря даже немного претит чего то писать на алгоритмическом языке и заморачиваться с ООП, компонентами доступа или еще чем. Единственное исключение из этого правила составляет PowerBuilder, на котором я продолжаю работать и который меня радует возможностями своих DataWindow и PowerScript, но при условии что он только используется по назначению - построении клиентских приложений.

авторC другой стороны, компилятор на WatcomSQL позволяет хранить подготовленные шаблоны в блобах рабочей базы, и на лету, на каждый запрос делать компиляцию в процедуру с уникальным именем, запускать процедуру, и по завершению убивать ее. Но тогда все же компилятор надо будет хранить непосредственно в рабочей базе и распространять его в исходниках...
Все таки скрипты движка я открывать не буду, распостраняться они будут как база WebSQL.db, у которой скрыты исходные тексты ХП и нет возмодности изменить служебные обьекты из за того, что запоролен хозяин БД. Это мне еще гарантирует, что народ не будет удалять или менять то, что нельзя изменять и удалять. С другой стороны в этой БД пользователи могут создавать собственные обьекты и заполнять специальные пользовательские таблички тех же библиотек макросов, что позволит им описывать и расширять повторно используемые решения. Компилировать скрипты можно и так на лету, без обязательного создания ХП, полученный код будет прекрасно выполняться через EXECUTE IMMEDIATE или в ISQL, так что ничего лишний раз создавать или удалять не надо. Запустить WebSQL можно и на одном сервере с рабочей базой командой START DATABASE по мере необходимости и так же его остановить. Ну и плюс я напоминаю, что это только базовый комплект моего макродвижка и я собираюсь еще дальше его расширять (поддержка генерации секций и подсекций одним SQL-запросом с помощью подзапросов и функции LIST, если внутри них не используются макрокоманды, поддержка движения секции в виде цикла WHILE LOOP, возможность установки аттрибутов организуемых курсоров, и т.д. и т.п.). В общем двигаться куда есть, главное, чтобы движение было целенаправленным и в нужную сторону :)

авторА что проверка на синтаксис отсутсвует как класс?
WebSQL проверяет на синтаксис свои макрокоманды в компилируемом документе. Сам документ он не проверяет по той простой причине (повторюсь), что он ничего про него не знает. И ему и не надо знать - его задача скомпилировать по контенту макета хранимую процедуру, реализовав в ней всю указанную для него в документе логику управления формированием контента и привязкой его к SQL-запросам и операторам.

авторНу если внешний компилятор делать на java то и библиотеку его можно и нужно хранить в jar'ах. БД там совсем не нужна :)
Зачем чего то делать на Java и требовать наличия у пользователя JVM, когда это прекрасно работает на родном языке ASA WatcomSQL ? Другое дело, что на Java было бы неплохо сделать собственный дизайнер построения макетов, с поддержкой семантики WebSQL, но это уже из другой оперы. У меня неплохо с построением макетов справляется GoldFusion Studio и даже OpenOffice.

автор ASCRUSподдержкой кроссплатформенности на разных ОС,
Java. Если кроссплатформенность действительно нужна. Либо C компилируем перед распространением на разные платформы, а пользователи уж как-нибудь сами сумеют дополнительные макросы скомпилировать :)
Гм, зачем и тут Java, когда макросы - это имя макроса и тело макроса с поддержкой параметров, внутри которого могут идти WatcomSQL команды, тэги, текст, стили, вызовы вложенных макросов ... в общем все то, что нужно человеку для описания повторно используемого решения в макетах. То есть макрос - это кусок чего то, что можно повторно использовать. Особых требований к этому чего то нет - лишь бы параметры в теле макроса корректно обьявлялись.

авторВпрочем, "компилируемый макрос" уже звучит странновато :)
Макрос - это определенная последовательность действий, которую можно в дальнейшем повторно использовать (в случае с WebSQL макрос - это определеный фрагмент текста). Дальше уже зависит от логики технологии - можно макрос каждый раз интерпретировать и выполнять, можно сразу по его телу скомпилировать на каком то языке готовый скрипт и при ссылке на макрос уже сразу выполнять скомпилированный скрипт. В данном случае для WebSQL весь HTML макет можно назвать одним большим макросом, на основании которого строиться готовый к употреблению скрипт на WatcomSQL.

автор ASCRUS более сложной инсталяции (БД надежнее и легче скопировать и подключить к другой БД,
Ну да - ну да. А EBF кто накладывать будет? :) Разрешите напомнить - если база работала на более свежем сервере, то она откажется запускаться на более старом. А это значит что пользователи будут вынуждены выкачивать и накладывать пачку EBF'ов. А если они этого делать не хотят? Вот я например очень и очень долго не апгрейдил свои сервера с 7.0.2. Просто потому, что в 7.0.3 поменяли работу с локальными темп именами, и при переходе на 9-ку мне пришлось переписывать почти сотню ХП.
На 9-ке у меня таких проблем не наблюдается. Между версиями 7 и 9 по любому бы были конфликты хотя бы потому, что это можно сказать по ядру совершенно разные СУБД.

автор ASCRUSЕдинственное исключение из этого правила составляет PowerBuilder, на котором я продолжаю работать и который меня радует возможностями своих DataWindow и PowerScript, но при условии что он только используется по назначению - построении клиентских приложений.
"Tell me!" как говорят наши друзья американцы :) Только что два часа убил: пытался понять почему композитное DW начало криво рисоваться. В итоге экспортировал его в srd, стер из pbl, импортировал обратно - идеально отрисовалось. Что это было за явление так и не понял.
Ну это радости жизни :) PB всегда напоминает, что он то конечно молодец, но расслабляться с ним нельзя :)

автор ASCRUSКомпилировать скрипты можно и так на лету, без обязательного создания ХП, полученный код будет прекрасно выполняться через EXECUTE IMMEDIATE
Да действительно. Вечно я про эту команду забываю. Просто ни разу в реальной жизни ее не использовал :)
А вот поэтому и возникает некоторое непонимание, что я имею ввиду, потому как я частенько для автоматизации самого себя именно этой командой и пользуюсь. Стоит только заглянуть в FAQ/Примочки :)

Я тут чтобы особо на форуме не флеймить, решил кое какие описание развития моего MacroSQL (пришлось переименовать с WebSQL по причине того, что оказалось, что он не только Web) в форум Теста выкладывать. Кому интересно, можно глянуть:
/topic/121139#991228
- на этот раз я тут его прикрутил для генерации по однотипным шаблонам скриптов процедур, триггеров и функций WatcomSQL. Надоело мне ручками в БД одно и тоже писать, пусть теперь ASA за меня делает, я лучше буду мышкой галочки ставить где надо по табличкам БД :)

Честно говоря в забавном :) На его основе я разработал методологию экстремального программирования на базе прототипов сущностей с эталонными свойствами и процедурами, плюс механизм обвязки в зависимости от установленных на таблицу аттрибутов триггеров и ХП. Например, у меня сейчас по этому поводу в БД автоматом по шаблонам в зависимости от аттрибутов генерятся где то 200 ХП и 150 триггеров на таблицы по шаблонам. Так же сейчас делается инструментарий под все это дело, с автоматической генерацией по шаблонам представлений по библиотеке стилей в формате DataWindow под PowerBuilder и DataWindow.NET.

P.S. Я готов выложить MacroSQL в OpenSource, однако пока у меня нет времени на его документацию. Хотя там честно говоря учить особо нечего - ровно 3 команды управления генерацией контента и WatcomSQL в качестве встроенного языка шаблонов. Другое дело, что необходимо вникать в саму концепцию.

Сержя вот не могу понять, на основании каких исходных данных генерятся ХП и триггеры. И какой код в этих ХП и триггерах.

Можно на примере объяснить? Например, вот на таком примитивном:

Группа товаров (ИД, Наименование, Признак "не используется")
Товар (ИД, ИД группы, Наименование, Цена, Валюта, Описание, Признак "не используется").

Пусть условно нужно будет написать клиента для такой бд и сделать отчет (типа прайса).

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

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

Чем может тут помочь WebSQL?
Как известно любой проект состоит из 2 частей - непосредственной бизнес-логики, реализуемой по постановке и физической реализации на основании возможностей инструментария (системная логика). MacroSQL позволяет писать повторно используемые шаблоны решений для SQL (как для бизнес-логики, так и для системной логики), для генерации динамических страничек HTML, генерации по шаблонам XML и т.д.

Думаю по HTML и XML все понятно - рисуется шаблон, в котором указываются поля и правила их заполнения. В случае SQL все похитрее. Приведу одно из используемых мной решений:

Постановка
- в проекте есть понятие закрытого периода. Все данные, которые были введены ранее открытого периода не могут уже изменяться.

ТЗ
- на таблицы с такими данными нужны триггера BEFORE INSERT, UPDATE, DELETE которые запрещали бы изменения данных в закрытых периодах.

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

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

СержИ второй вопрос. Какова дальнейшая судьба этой затеи? Это будет опенсурс или платный продукт?
Я думаю это будет open-source. На его базе я сейчас веду эксперементальную разработку собственной платформы построения клиент-серверных приложений, так что было бы здорово, если бы технология MacroSQL получила распостранение и в силу возможности использования повторно используемых шаблонов и макросов обрастала бы решениями в различных направлениях. Звучит конечно помпезно, но на самом деле те кто видел эту технологию признают, что в этом что то есть :)

Серж ASCRUSДумаю по HTML и XML все понятно - рисуется шаблон, в котором указываются поля и правила их заполнения.

А как указываются правила? Ведь правило может быть совсем не тривиальным.
Без проблем. В качестве языка управления генерации контента используется сам WatcomSQL, думаю никто не будет отрицать, что на нем можно описать самое нетривиальное правило, ну а если вспомнить что на нем можно вызывать и использовать Java обьекты ... то вообще неразрешимых задач на горизонте не видно.

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

Слова красивые, но меня ими не запугать ;) Что понимается под платформой построения кс-приложений? КС-приложения состоят из серверной части (в нашем случае АСА) и клиентской, которую пишут на каком-то средстве. Что это будет за средство, ПоверБилдер?
Платформа поддерживает автоматическую генерацию по определенным стилям, описанных на DataWindow Expression, представлений DataWindow, экспортирующихся в библиотеки проекта на PowerBuilder или C#. Я мог бы конечно довести до полной автоматизации вообще построение клиентского приложения, но не вижу в этом смысла - у меня для PB есть целая иерархия продуманных и проверенных временем компонент и форм для построения качественного интерфейса. Полученный в результате генерации DataWindow элементарно можно далее просто открыть в DataWindow дизайнере PB, подредактировать (растащить мышкой поля, проставить lookup поля, дополнительные правила форматирования, проверок и т.д.). Далее достаточно наследоваться от нужной формы, прицепить туда готовый DataWindow и на коде PowerScript дописать интерфейсную часть бизнес-логики и сделать ее вызов с проекта. С учетом того, что при генерации DataWindow платформа уже проставила различные правила получения, сохранения и ввода информации, процесс получается быстрым и не сложным и вводить его дальнейшую автоматизацию означало бы лишать программиста клиентской части гибкости и подсовывать ему вместо PowerBuilder собственной средство разработки приложений, что было бы совсем печально (думаю такие печальные системы перечислять не стоит). Так что главный упор платформы - это не автоматизировать создание серверной или клиентской части, а реализовать 2 главных для проектирования парадигмы:
1. Обеспечить абстрагирование данных от кода - в платформе есть понятие прототипа сущности, у которого есть эталон полей, эталонные процедуры получения и сохранения информации, понятие связи с другими прототипами и юнит-тесты, успешное выполнение которых гарантирует правильность физического отображения в БД прототипа. Получается, что в независимости от способа физического проектирования и реализации сущности в БД, прототип всегда будет абстрагирующим слоем, гарантирующем серверной и клиентской части корректность и правильность работы с ожидаемой информацией.
2. Обеспечить разделение бизнес и системной логики. В данном случае моя платформа требует, чтобы вся основная бизнес-логика хранилась только на сервере. Клиенту оставляется только интерфейсная часть бизнес-логики. В тоже время платформа, в которую входит MacroSQL и мои компоненты построения интерфейсной части под PowerBuilder настаивает, чтобы системная логика как для БД, так и клиентской части была максимально повторно-наследуемой и автоматической. Если условия БД требуют, чтобы на определенные таблицы вводилась триггерная проверка на невозможность изменения информации задними числами, значит такая проверка должна быть написана в виде шаблона и для соотвествующих таблиц установлен аттрибут из словаря аттрибутов, который укажет шаблону, что на них будут сгенерированы соотвествующие триггера. Для клиентской части в плане системной бизнес-логики предоставляется ООП иерархия компонент и форм, что позволяет просто наследоваться от нужных обьектов и изначально получать требуюмую функциональность. В данном случае в моей иерархии ключевыми фигурами являются прототипы главных и дочерних форм, компонент для построения визардов ввода и изменения информации, а так же наследованный DataWindow контрол с расширенной функциональностью. Все обьекты автономны и при использовании в проекте могут быть наследованы для дальнейшего расширения их базовой функциональности и использовании при построении клиентской части приложения.

ASCRUS
Или может будет все на АСА, а клиент - использование возможностей веб-сервера АСА?
Вариант построения тонкого клиента на браузере вполне возможен и с помощью MacroSQL легко автоматизируется, где можно взять любой HTML редактор для рисования шаблонов форм и отчетов, бизнес-логику вынести в ХП, а управляющий код интерфейса (системную логику), описываемых тэгами и JavaScript, автоматизировать с помощью использующейся технологии макросов (по принципам ближе всего к функциональным языкам). Будет неудобство в том, что HTML редакторы будут управляющий код для MacroSQL видеть как комментарии, так что в случае написания собственного RAD средства можно было бы добиться действительно удобной для рисования HTML-клиентов IDE. Однако во первых я не имею времени писать свою IDE, во вторых будет очень сложно реализовать на JavaScript для браузера всю ту функциональность, которую изначально предоставляет PowerBuilder. Лично я предпочитаю идти по пути наименьшего сопротивления и всегда пользоваться существующим, чем изобретать свое. Однако для генерации динамических сайтов думаю при соотвествующей обвязке с веб-сервером и тем же PHP мой MacroSQL мог бы принести несомненную пользу и перенести с PHP на ASA всю бизнес-логику сайта, оставив PHP такие системные вещи, как управление сессиями, обеспечение защиты, работы с электронными деньгами и т.д.

Хорошо - я на выходные постараюсь на ASADemo чуть порисовать шаблонов на HTML. Если все получится, то я исходники MacroSQL и шаблоны выложу прямо на SQL.RU .

P.S. Данный ip не пингуется, потому что это мой домашний компьютер, сейчас он в оффлайн днем, так как вроде никто особо к нему не обращается. Скоро он будет работать в режиме с 8-00 до 22-00 кроме выходных, так как на нем я хочу открыть FTP. Можно будет тогда на нем и ASA как веб-сервер поднять.

Начал делать сайт на базе демонстрационной базы ASADemo. Сайт доступен тут: http://62.141.90.19 , предположительно будет работать с 8-00 до 22-00 ежедневно. Все остальное я буду выкладывать в его новости.

Гм, работать то он начал, только пока по интернету почему то недоступен. В понедельник буду выяснять у провайдера.

Сервак стоит у меня дома, то есть в Москве. Соответствующе и время московское. Почему с 8 до 22 - гудит же он, спать моим будет мешать :)

Придеться подождать с пару дней. Как оказалось мой провайдер сейчас меняет канал и у него сейчас идет перенастройка всего. С работы же на SQL.RU я положить не могу - у нас тут админы так зафайреволились, что сами себе ничего закачать или уплоадить не могут :)

Высылаю по почте что есть. Описание выкладываю сюда, чтобы если что, не повторяться. Итак разворачиваем архив MacroSQL.rar в папку MacroSQL:

Код: plaintext

1.

MacroSQL
  \Demo

в самой папке MacroSQL файлы:
install_struct.sql
- инсталяция структуры таблиц MacroSQL

install_data.sql
- загрузка в таблицы данных. здесь необходимо переправить параметр пути [C:\MacroSQL] на другой путь к инсталяционному директорию, если он другой

install_data_load.sql
- вызывается из install_data и загружает данные (но не очищает перед этим таблицы)

install_proc.sql
- инсталяция процедур генератора MacroSQL

*.dat
- данные для таблиц MacroSQL

В папке DEMO лежит образ сайта, который я начал на выходных делать на MacroSQL. В качестве БД использованна ASADEMO.db, на которую я накатал инсталяцию MacroSQL. Пока все что и как работает можно посмотреть как раз на ее примере. Необходимо поднять эту базу со следующими параметрами:
так же там лежат макеты (*.html) шаблонов, по которым был скомилирован сайт. В БД для обеспечения функционирования сайта были введены таблички:
web_Config
- конфигурация сайта. любое изменение в таблице вызывает перекомпиляцию новостей (см. ниже). Здесь нужно правильно расставить параметры, чтобы привязаться к текущему серверу.

web_News
- новости, в поле Content храниться текст новости, допускается использование HTML тэгов и операторов MacroSQL. Так же есть поле CompileContent, которое хранит в себе уже автоматически откомпилированную через MacroSQL новость. В данном случае я не стал заморачиваться с динамической компиляцией новостей во время построения контента для сессии и сделал это статически.

Так же в папке DEMO лежит скрипт generate.sql, в котором прописано через вызовы ХП MacroSQL компиляция шаблонов в ХП. Такие ХП в БД лежат по маске web_html_* и web_include_* . Так же для БД я написал различные дополнительные ХП для возвращения по имени конфигурационного параметра его значения, получения с диска текста макета, картинки, возвращения скрипта ХП и т.д. Ну и собственно говоря в БД прописаны сами web-сервисы, отвечающие за работу сайта.

на текущий момент реализованы режимы - новостной канал (грид с сортировкой по дате новости), краткое описание технологии и кратко о себе. Шаблоны я делал в OpenOffice, далее через Notepad вставлял в них нужные описание секций и скриптов. Если знакомы с HTML, то код MacroSQL в них будет четко виден. Дизайн естественно никакой.

После запуска БД и настройки параметров в web_Config сайт можно поднять через броузер, написав http://localhost .

Вот вроде краткая инструкция, пробуйте, заодно здесь откорректируем инструкцию и инсталяцию :)

dp_tndПопробовал покрутить MacroSQL. стартовая страничка web-сервера работает. А вот что-либо перекомпилировать не удается. База с грохотом падает. :(

Пошел другим путем - взял asademo.db из комплекта своего сервера, накатил на нее MacroSQL и попытался откомпилировать простейший шаблон. Результат тот-же :( База с грохотом падает, да еще и log умирает.

Создал базу с 0. Накатил MacroSQL и попытался откомпилировать еще более простейший шаблон.
Результат опять отрицательный. :-0

Трассировка показала, что база рушится на операторе

SET @CurPos = Locate(@Content, Char(1) || '<section', @PrevPos);

процедуры MacroSQL_Generate_Content(). Причем вне зависимости от наличия/отсутствия секций и длины шаблона.

Все это проверялось под ASA 9.0.1.1751
У меня ASA 9.0.1.1922 - все работает нормально.

dp_tndТеперь вопросы по спецификациям:

1. Из примеров на не понятно, в чем разница между макрокомандой на WatcomSQL и макросом и вообще, формальные правила определения и использования макросов.
Макрокоманда WatcomSQL - это фактический скрипт, который будет вставлен как WatcomSQL операторы в непосредственно генерящуюся процедуру. Макросы - это параметризированный шаблон, который сначала будет преобразован как текст с подстановкой параметров и если установлен тип макроса Script - следом выполненен, а результат возвращенный макросом вставлен в то место шаблона, откуда он вызывался, с дальнейшей его обработкой. Фактически если провести аналогию с компиляторами Си и Паскаля, то макросы можно рассматривать как препроцессорные Inline директивы, а макрокоманды WatcomSQL как директивы, управляющие компиляцией.

dp_tnd2. Не до конца очевидно применение конструкции
<!--!IF @IsFullContent = 1 THEN!--> . . . <!--!END IF;!-->

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

dp_tndНекоторые замечания по внутреннему дизайну:

1. В таблицу MacroSQL_Oper недурственно добавить поле комментарий и вписывать туда краткое описание.
Согласен. Фактически везде есть Description, осталось только найти время и заполнить их :)

dp_tnd 2. MacroSQL спроектирован для использования в рамках ASA 9+. Значит можно воспользоваться
call sa_make_object( );
alter procedure|function ...
Что и используется в примерах по web-серверу ASA. (...\Sybase\SQL Anywhere 9\Samples\ASA\HTTP)
Спасибо за совет, я как то не догадался. Очень удачное решение.

dp_tndКстати, я не нашел информации о том, как поведет себя ASA с объявленным web-сервисом в случае, когда будет дропнута используемая в нем процедура. В следующих билдах это поведение может поменяться. А связка sa_make_object() + alter... избавляет нас от зависимости от изгибов генеральной линии Sybase :))
Веб-сервер ASA в случае любой ошибки при выполнении сервиса просто возвращает код и текст ошибки в виде HTML странички.

dp_tnd3. Если рассматривать MacroSQL со стороны генератора html отчетов, то логично было бы определение имени генерируемой процедуры, declare, init блоков и пермишенов на ее исполнение было бы логично поместить в параметров секции Main, а в прочих секциях их игнорировать.
В секциях на обьявляемые переменные поддерживается область их видимости. Область видимости алиасов распостраняется снизу вверх - то есть сначала преобразовываются алиасы в значения обьявленные в обрабатываемой секции, далее накладываются алиасы из родительской секции и т.д. Область видимости переменных позволяет создавать сложные макеты с большим уровнем вложенных секций и их описание в главной секции привело бы к нечитабельности макета. Плюс стоит помнить, что секции, организованные на запросы изначально организовывают по полям запроса переменные в пределах секции с видимостью во вложенных секциях (если там не были переобьявленны переменные).

dp_tnd4. Может быть нужно процедуры, которые возвращают результат работы при помощи конструкции
SELECT @Content AS Content;
превратить в функции, возвращающие long varchar ? Похоже в моем случае сервер запутывается от обилия полей с именем Content :))[quot dp_tnd]
Так и было. Вот только в ASA периодически на long varchar, возвращаемый как result из функций или out-параметр с процедуры проскакивает баг, который я пока не смог точно локализовать, который напрочь вышибает сервер. Поэтому пришлось все перевести на SELECT. Судя по всему в Вашем EBF в том числе присутствуют проблемы с long varchar в SELECT.

[quot dp_tnd]В заключение, несколько мыслей по экстремальному программированию БД.
Для создания и сопровождения БД под ASA мы уже лет 5 используем PowerDesigner. Точнее его урезанный вариант для работы с физической моделью, который идет в комплекте ASA.

Неоднократные попытки использовать PD в полном объеме выявили несоответствие нашего подхода и мышления разработчиков PD. А вот физические модели - это просто замечательно.
Сейчас у меня в проекте задействовано 18 SQL макетов, каждый из которых генерит серию функций, процедур и триггеров по указанным параметрам на таблицу или таблицы. Так же в своей БД я нарисовал таблички, где на каждую таблицу расписываются различные аттрибуты их логического назначения (от способа хранения периодов информации для таблиц с историей изменения информации, до таких вещей, как проверки на изменения записей, помеченных как системных, процедур, возвращающих данные по указанным параметрам и т.д.). Так же написана процедура, которая на указанную таблицу получает ее аттрибуты и в зависимости от них возвращает список процедур (скомпилированных макетов) и их параметров, необходимых для обвязки этой таблицы. Ну и естественно написан свой дизайнер, позволяющий удобно расставлять по таблицам проекта нужные аттрибуты (его скриншоты я приведу в следующих сообщених). В итоге такая централизация логики позволила мне на 2/3 сократить ручной труд по написанию бизнес-логики в БД, быстро вводить в проект новые таблицы с автоматической генерацией по ним нужных скриптов и дала возможность централизованно воздействовать на код бизнес-логики проекта. Буквально только сейчас я например решил, что для таблиц, хранящих данные в виде истории изменения аттрибутов, в том числе задними числами не хватает процедуры, возвращающей все активные данные на текущий и будующие расчетные месяцы. Открыл нужный шаблон, отвечающий за генерацию процедур получения данных по истории, за 3 минуты докатал в него шаблон новой ХП, сохранил, за 1 сек скомпилировал его и нажал в своем дизайнере "Перегенерировать все" и через 3 сек. получил на все нужные таблицы в довесок новые процедуры, которые тут же люди начали прицеплять в клиентском приложении.

dp_tndКстати, это позволяет создать автоматизированную процедуру корректной перегрузки данных в новую версию БД, например при апгрейде сервера, даже при очень вычурной бизнес-логике БД. Недавно пришлось делать это для клиента, который решил переехать с ASA6 на ASA9.
Ну по идее тоже самое можно сделать на шаблонах MacroSQL :)

dp_tndКстати, PD умеет генерировать и datawindow и набор атрибутов в репозиторий, но к сожалению, корректность его работы в этой части проверить руки не доходят.
Пока с PB я затею бросил - фактически есть классы, написанные на PB, которые позволяют по указанному шаблону стиля сгенерить довольно приличный DataWindow и сохранить его в указанную PBL, пока этого хватает, все лучше, чем пользоваться визардами генерации DW самого PowerBuilder, так как в отличие от их визардов у меня можно описать шаблон стиля DW не только на его общий вид, но и на банды, текстовые поля и колонки, причем в текстовые поля сразу вставляется текст из ремарки поля из таблицы. На дальнейшее творчество просто нет времени, так что это откладывается на потом.

Так как я в основном использовать в последнее время MacroSQL на генерацию по диалекту WatcomSQL, то естественно перед тем как Вам выслать пришлось подравнивать его под HTML диалект и усовершенствовать под функциональность сайта. Соотвествующе пару ошибочек я все таки да сделал. Сейчас они поправлены. Если есть дальнейшее желание поюзать его, могу переслать новую версию скриптов ХП (все остальное не изменялось).

Сами скриншоты дизайнера:

А это вкладочка, где показано, какие процедуры, скомпилированные по макетам MacroSQL будут вызваны на таблицу:

А это одна из процедур, сгенерированная по макету "z_Proc_get_HistoryWithCloseDate":

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

Итак - обещанная к показу и уже почти наполовину разработанная система контроля версий РСУБД:
http://asc.rs-erc.ru/scv
логин: Guest пароль: Guest
Гостю доступен на просмотр проект ASC и подписанный на проект для синхронизации сервер SocPay_Dev. Изменения запрещены. Зайдите в проект ASC, далее в скрипты, там можно будет поиграться просмотром и фильтрацией скриптов по проекту и отслеживанию их выполнения на сервере SocPay_Dev (пока все скрипты тестовые и левые). Для администраторов проекта доступны добавления и измения скриптов через веб-формы или файлов. Как будет доделан веб-интерфейс, открою тестовый проект и сервер, для которого дам гостю администраторские права. Описание самой системы версий потом выложу в рутовый веб-сервис, пока он перенаправляет на список проектов.

Для того, чтобы иметь представление, как это писалось, даю ссылку на веб-интерфейс управления шаблонами MacroSQL:
http://asc.rs-erc.ru/scv/macrosql/list
Логин и пароль те же. Доступ только на чтение. По именам шаблонов понятно, какие странички системы контроля версий они реализовывают. С формы вполне можно выдрать сам html шаблон, загрузить в какой нибудь нормальный веб-редактор HTML и там посмотреть, что из себя представляет шаблон MacroSQL - полюбоваться на помесь HTML, WatcomSQL и JavaScript :) Описание MacroSQL так же потом выложу на рутовой страничке.

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

JagerОдна интересная странность - под IE все в порядке, под оперой (v8.5) - руччкие буквы не распознаются в принципе, все буквы выводятся квадратиками... С чего бы это...
Странно, у нас IE, Opera, Mozila прекрасно вроде все работают. Может быть нарвались, когда перекомпиляция макета была - или все время, даже сейчас Opera не определяет кодировку ?

sdkЭ, хм, как бы это помягче сказать...

Уважаю АСКРУСа как человека и модератора :), но в упор не понимаю, зачем он эту работу сделал, т.е. широкого практического коммерческого применения, к сожалению, не вижу. Хотя желаю удачи в продвижении проекта.

_______________________________________________
Человек ленив, и именно лень - двигатель прогресса.
Все для себя любимого :) Хочется поиметь систему контроля версий скриптов БД под собственные нужды :)

White Owl ASCRUSВсе для себя любимого :) Хочется поиметь систему контроля версий скриптов БД под собственные нужды :)
класть скрипты в CVS уже не прикольно? :)
Не прикольно :) В ситуации множества проектов, на множестве удаленных географически СУБД, с множеством удаленно разнесенных разработчиков, из которых есть ... очень даже не прикольно.

White Owl ASCRUSНе прикольно :) В ситуации множества проектов, на множестве удаленных географически СУБД, с множеством удаленно разнесенных разработчиков, из которых есть ... очень даже не прикольно.
Ну я все равно считаю что CVS хватает за глаза. Сколько бы разработчиков ни было, сколь далеко они друг от друга не находились бы, сколько бы проектов одновременно не шло бы :) Посмотри на любой проект на Sourceforge например.
А что, там так много разработчиков баз данных ? Меня лично устраивает скриптование скриптов изменения состояния БД (лог), чем хранение самих скриптов обьектов БД. Для алгоритмических языков это нормально, а для синхронизации структур БД не сказать, что все удобно. Под себя мне легче через веб-интерфейс хранилища и веб-сервисы собирать логи скриптов и управлять ими, которые автоматом будут накладываться утилитой на подписанные сервера с автоматическим отслеживанием процесса выполнения скриптов, отловом ошибок в ходе их выполнения, разрешением изменения версии скрипта под нужные сервера и прочее, то что я сейчас по любому так или иначе вынужден делать ручками.

Малость адреса поменялись, вынесли веб-сервисы на отдельный сервер ASA:
Система контроля версий:
http://asc.rs-erc.ru
Система управления прототипами MacroSQL:
http://asc.rs-erc.ru/macrosql/list

Так же в MacroSQL возникли идеи расширить язык - сделать более удобное описание параметров, переданных с браузера, контроль за передачей GET и POST и возможность обработки множества значений параметра как набор данных, то есть запросом (пример можно посмотреть на страничке скрипты проекта ASC, где есть возможность пометить любые нужные записи в таблице, проделать с ними групповые операции, причем во время перечитки страницы сохраняется статус помеченных записей в браузере).