Буду в Минске.

Итак, примерно с 20 декабря по 3 января собираюсь посетить город-герой Минск. Родина ждет. Очень жаль что не успеваю посетить вот эту встречу BYJUG. Java меня мало занимает, а вот про Flex и RIA в целом с удовольствием бы пообщался.
Если у кого-то есть пожелания и предложения встретиться - пишите, звоните, приходите :)

Составная форма

Вот этот вопрос на sql.ru сподвиг написать пример составной формы. Сам пример можно заценить здесь.
Суть в том, чтобы отдельные части сложных форм писать отдельно, как независимые пэйджи. А потом с помощью htmldb_Get эти части аккумулировать в одном месте. Получается эдакий эффект фрэймов.
Более того, этот приём очень эффективен, если нужно ообновить только какую-то часть страницы, а не перегружаться полностью. Собственно ajax в действии.
Добавлю еще, что если у вас на такой аггрегированной странице какой-нибудь из встроенных PPR репортов использует pagination (переход по страницам отчета) или сортировку, то они не будут работать корректно. Чтобы исправить ситуацию нужно на главной странице переопределить javascript функцию $a_report.

function $a_report(G,D,F,C,A){
 lThis=$u_js_temp_drop();
 var B=$x("report_"+G+"_catch");
 B.id="report_"+G+"_catch_old";
 var E="p="+$v("pFlowId")+":"+СЮДА_НУЖНО_ПОДСТАВИТЬ_НОМЕР_ПЭЙДЖА+":"+$v("pInstance")+":FLOW_PPR_OUTPUT_R"+G+"_";
 if(!!A){
  E+=A+"::RP&fsp_region_id="+G}
 else{
  E+="pg_R_"+G+":NO&pg_max_rows="+F+"&pg_min_row="+D+"&pg_rows_fetched="+C}
 var H=new htmldb_Get(null,null,null,null,null,"f",E);
 var I=H.get();
 lThis.innerHTML=I;
 B.innerHTML=$x("report_"+G+"_catch").innerHTML;
 B.id="report_"+G+"_catch";
 lThis.innerHTML="";
 return
}

Обратите внимание в скрипте на "СЮДА_НУЖНО_ПОДСТАВИТЬ_НОМЕР_ПЭЙДЖА". Там должен быть номер страницы, которая содержит PPR отчет, в котором должен работать pagination. Естественно лучше туда этот номер подставить динамически, например функцией $s.

Напоминаю, PPR отчет - это отчет в котором рефреш страницы и сортировка происходят при помощи ajax, т.е. без полной перерисовки страницы.

Крэкс, фэкс, пэкс или архитектура приложений под Oracle

Хотел написать полноценную статью, но из-за загруженности решил, что лучше уж напишу заметку, чем вообще ничего. Итак...
Если у вас стоит задача написания нового приложения с использованием базы данных Oracle, то естественно возникает и вопрос: на чем его писать и, соответственно, какую архитектуру приложения выбрать.
Конечно, для некоторых команд этот вопрос может быть заведомо решен - пишем на Java, .Net, Forms... и так далее. Список огромный - каждый выбирает по вкусу, или точнее то, чем владеет. Относительно с недавних пор всё больше разработок ведется на Apex. Отличный инструмент, но и не лишен некоторых недостатков. Ну и совсем свежачок - Flex. Вот на счет последних двух и хотелось написать. Собственно, заклинание из заголовка статьи немного созвучно набору технологий Apex, Flex, Ajax.

Для начала Apex. Инструмент простой, но очень эффективный. В принципе, позволяет создавать web приложения любой сложности. При этом избавляет от значительной части рутинной работы. Архитектура Apex приложений по сути проста – база данных сама генерирует html контент. Т.е. никаких специфических средних звеньев не требуется, если не брать в расчет web сервер (встроенный либо нет). И само приложение всё хранится в таблицах базы данных. А дальше идут недостатки, обусловленные как раз такой архитектурой. Неудобство разработки внутри html приложения, отсутствие нормальной версионности файлов, сложность вклиниться во внутренние механизмы рендеринга страниц – особенно критично в случаях, когда вы строите приложение сильно отличающееся от стандартных шаблонов. Опять же рендеринг создаёт дополнительную нагрузку на базу, хотя я и не сталкивался пока с серьезными проблемами по этой части, но тем не менее.

А теперь Flex. Очень богатые интерфейсные возможности при минимуме усилий. Можно создавать полноценные десктоп приложения. Разработка ведется вполне классическим способом, с поддержкой всевозможных сопутствующих систем версионности и т.д. Короче, конфетка! Но есть и «но». Flex общается с базами данных посредством web или http сервисов. Еще вроде Adobe предлагает Data Services, middle tire компонент для взаимодействия с базами данных, но я этим вопросом вплотную не занимался, потому как мне не интересен вариант использования дополнительного звена между приложением и базой, да ещё и java based.

Но во Flex очень просто реализуется взаимодействие приложения с javascript страницы, в которую он встроен. Причем это взаимодействие работает в обе стороны: javascript может вызывать методы flex приложения, и flex может вызвать любую внешнюю javascript функцию. Собственно в этом вся и соль – встроить Flex приложение внутрь Apex. Сам Apex при этом выполняет функции доставки данных, контроля доступа, управления сессиями, а Flex в свою очередь выполняет функции клиентского приложения.

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

Чем не идеальная архитектура? И главное, ничего лишнего и всё бесплатно :)
Подумайте, может оно того стоит! Я кстати уже опробовал - мне понравилось.