kasikесли айтем нужно присвоить на уровне сервера то больше никак.

APEX_PLUGIN_UTIL.get_data + текст запроса из определения поля для динамического LOV. Или парсить строку статического LOV из того же определения, сравнивая ключи со значением поля.

Чуть сложнее, но можно и на стороне сервера.

Irhenнельзя просто прописать, что мол значение этого item равно текущему значению select list ???

Проблема в том, что текущее значение списка -- это value, а не text выбранного option. Тот самый код, а не отображаемое значение.

Irhenну ок. я согласен на value.

0. Чтобы на странице сразу поменять значение поля, на событие Change списка повесьте DA, которое будет устанавливать выбранное значение в нужном поле.
1. Чтобы сделать это при сабмите, можете использовать вычисления (Computations) либо настройки в Branches.

Gustly,

описание DA, как и всего остального, хранится в словаре APEX. При отрисовке страницы их инициализация выводится в скрипт, как и инициализация деревьев, дэйтпикеров и прочего. Инициализация вызывает API, навешивающий обработчики соответствующих событий с вызовами уже реализованных функций, которые добавятся на страницу независимо от того, есть у Вас на ней DA или нет.

Поэтому Ваша обычная функция — это дополнительный код на странице и намеренный отказ от имеющегося API в пользу своего велосипеда. И тут уже я спрошу: есть ли выигрыш в производительности и возможностях у Вашего велосипеда и перевешивает ли он декларативность и наглядность DA?

Gustlyв DA выполняется тот же самый JS, который я мог бы просто повесить на эвэнт ченжа.
На страницу выводится тот самый HTML, который Вы можете сами вывести через HTP. А в БД есть встроенные функции вроде NVL и UPPER, которые Вы можете реализовать сами на C и подключить их как внешние процедуры.

Надеюсь, аналогия понятна.

GustlyНе очень. Все таки DA является лишним посредником между кнопкой и JS кодом.

DA -- это и есть JS-код со стандартами его использования и типовыми действиями.

До версии 4.0 разработчики, использующие APEX, в начале проекта шли предложенным Вами путём: воткнуть в атрибут элемента вызов функции JavaScript, проблема решена; закинуть куда-нибудь на страницу код в теге script, и ладненько. Потом приложение росло, и на скорую руку прилепленные обработчики и код начинали конфликтовать, их становилось сложно найти, они использовали повторяющиеся куски (тот же AJAX), которые приходилось править все разом в случае ошибки или изменений API... Разработчики писали собственные библиотеки, вырабатывали стандарты использования JS-кода в приложениях APEX и требовали нововведений, которые позволят решать типовые задачи "в два клика".

Патрик Вульф, создавая расширения для APEX, предложил модель обработки событий и добавления JS-кода и скриптов. Войдя в APEX Team, он её реализовал, частью этой реализации стали DA -- выполнение типовых действий по событиям, набор которых можно расширять, используемых декларативно. Этот функционал был признан одним из двух главных улучшений в APEX 4.0.

Вы считаете, что DA влияют на производительность настолько, что это необходимо принимать во внимание и жертвовать готовыми стандартами использования JS при обработке событий. Докажите это.

Gustlyс DA на кнопке вообще стоит onclick="void(0);", как оно работает я не понимаю.

Почитайте apex/images/libraries/dynamic_actions[_core].js. Почитайте JS-код, который APEX создаёт при отрисовке страницы. И поймёте.