Не знаю, насколько в тему топика.
Просто к сведению - может кому пригодится.
Конструкция в скрипте APEX-а


Эквивалентна


Поскольку функция update_cache_with_write ругается на несуществующие ITEM,
рекомендую использовать собственную процедуру в схеме текущего приложения
- с игнорированием exception

ПодсказчыкZhV,

Если ругается, значит правильно делает, нельзя в коде обращаться к не созданным items, нефиг лишнюю черточку в название ставить. Следующим шагом, я так подозреваю, будет все запросы оборачивать в exception when others then null; типа а вдруг нету такой таблицы? Идея бредовая.

Это нужно для унификации/типизации ввода в анонимных блок-скриптах на различных PAGE
Вместо того чтобы на каждой из похожих страниц писать десятки строк вида



Написать в 4 строки абсолютно одинаковые конструкции для всех страниц ввода данных


А для проверки существования item можно ( и иногда нужно) делать в отдельном блоке пре-валидации.
Так чтобы ошибки валидации можно было бы положить в лог и, главное - юзер увидел бы нормальное оформленное
сообщение об ошибке в region #GLOBAL_NOTIFICATION# , а не страндартное окно типа "полный крэш" с непонятным ему текстом.
Два-три таких крэш-окна за один сенас работы - и у юзера будет полное основание сказать что ваше приложение полное г.

Petro123ZhVВместо того чтобы на каждой из похожих страниц писать десятки строк вида
сначала разберитесь, почему у вас "похожие страницы".
Тогда и велосипеды возможно не пригодятся.
Видите ли... Если бы я ответил так своему заказчику....
Есть общее понятие и соответственно "PAGE" "Договоры".
Но есть куча вариаций - поставка, аренда, подряд, субподряд ...
Почти половина реквизитов одинаковы - как правило контрагент.
Но есть куча специфических реквизитов по каждому виду - и поэтому естественно - отдельная страница для просмотра и ввода.

Попробуйте мне предложить вариант - обойтись одной страницей - внимательно выслушаю.

SvDevZhV,

Для установки значений динамически см. apex_util.set_session_state.
Для красивых сообщений об ошибках см. error handler function.
Для проверки существования см. apex_application_page_items и apex_application_items.

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


- лучше один раз найти такие ошибки и исправить, чем стрелять себе в ногу. имхо.

Ну что ж, про apex_util.set_session_state - я не знал.
Может быть потому что этот пакет реально лежит в схеме SYS и называется htmldb_util.
В любом случае - спасибо. Век живи...

Я просто потратил время на исследование пакета wwv_flow в схеме APEX-а - там в принципе много чего интересного.
Попробовал - вроде бы работает одинаково. Если будет время - попробовать все-таки найти различия.
ИМХО, в схеме APEX0000 все таки есть привязка к версии - это может быть существенно.

Но что ж вы раньше то молчали - а то народ уже JavaScript юзает.

Проверки существование - это сообщите коллеге "Подсказчык"

Насчет логов... В данном случае я рассуждал в рамках конкретного проекта.
90% логики приложения сделано в пакетах, которые вообще не знают про сущестование APEX.
Просто потому что до недавних пор приложение существовало только в виде Delfi/Desktop приложения.
Постепенно часть функционала переносится в APEX. Надеюсь, когда-нибудь все перенесем.

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

Petro123не будьте максималистом. Никто про одну страницу не говорит.
Вариант:
- общий список - журнал - ОДНА страница с колонкой Тип документа
- все остальные страницы как Карточка товара\Карточка аренды и т.д. разумеется индивидуальны.
А вы как хотели?
ООП в апексе делать?

Вы сами себе противоречите ? полчаса назад
Petro123 "сначала разберитесь, почему у вас "похожие страницы".

Это не я максималист - а заказчик. Вы когда-нибудь видели договоры аренды и субподряда в бумажном виде?
Общее там только - "подвал" с реквизитами договаривающихся сторон.

Насчет ООП... Why not?
При остутствии константных привязок к переменным страницы типа (:P12_ID := ...)
простое копирование страницы на 80% корректно переносит функционал отображения данных.
- под каждый вид договора существует собственная view - в пре-поцессорном PL/SQL блоке
задается другое имя view
- добавляются нужные поля, удаляются ненужные
- все это визуально компонуется на region-ах
- немного меняется код на Submit-е
- ну еще иногда менются списки операций на sidebar-е

Вот чем и замечателен APEX. Я неважно знаком с JavaScript-ми заморочками - но почти все что нужно, я делаю
в пакетах или анонимных блоках - то есть не выходя из PL/SQL. Ну кое-какие нюансы вносит Java-спец - я учусь у него.

Petro123При наличии БЛ уже готовой будет 1 страничка в день.
Итого что вас там испугало? Это обычная работа программиста.
...
Удачи!
Ну дык я об чем.
Во только я программист Oracle а не front-end разработчик.
И моя основная работа - после Submit не просто commit как в учебных примерах,
а должна быть вызвана правильная процедура из правильного пакета, которая
правильно проанализирует и обработает внесенные данные или их изменение -
все распишет по нужным таблицам и запишет в логи нужные сообщения.
И вот тут бывает 1 дня не хватает.

Уж не обессудьте насчет высказывания
Petro123 не туда пошёл.
Я уж как нибудь сам решу - куда идти.

SvDevZhV,
В пакетах можно не все apex ошибки обработать и не всегда это удобно...

В моем случае я очень хорошего мнения о предшественниках-делфистах, которые лет 15 назад
заложились на размещение бизнес-логики в базе (80-90%), а не на своих формах.
И я намерен продолжить этот тренд - все что можно перенести в обработки Oraclе (как правило пакеты, реже - анонимные хранимые блоки PL/SQL) - надо туда пененосить.

После APEX-а может быть что-то еще... А Oracle вечен.

Petro123У меня тоже хранимки(. Приходится вносить в них 20 параметров от 20 ITEMS....


Совет с моей стороны - осваивайте XML как универсальный способ внутри- и меж- системного обмена любыми обьектами.
Сможете начать работать с такими полезными и востребованными вещами как SOAP, REST... даже СМЭВ и сервисы ФНС :)
По аналогии с предыдущим моим примером


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

Простейшая операция - XMLType(input_xml) - и вы получите и название VIEW/TABLE и вид операции, и все введенные поля-параметры, сколько бы их ни было. Кстати, когда то один коллега наступил на грабли - Oracle 9 терпел не более 256 параметров. Счас не знаю - мне никогда бы не хватили фантазии на больше пары десятков.
Если не хватит 2000 символов - сделайте копию TODO2 с входным CLOB параметром.
Но помните, что вызов с использованием CLOB не будет работать по dblink.
А дальше Main_pkg уже вызовет профильный пакет для окончательной обработки в рамках бизнес-логики.

В XML очень удобно находить различие между введенными значениями и текущими. XML-курсор по динамическому Select-у с заданным id и по входному XML - пишется только один раз и используется для любых таблиц. Позиция конкретного поля (1-я в диалоге и 10-я в таблице или view) - абсолютно неважно, но принципиально важна одноименность .
И естественно - именно изменения пишутся в лог.
Еще удобство - при каких-то тяжких и неуловимых багах - включить режим fullscale-log на входные параметры - кидать входные XML в большой CLOB-лог. Можно подловить - на каких входных данных проходят баги.

На всякий случай - при работе с dblink или другими внешними системами - нужно следить за кодировками XML.
Если что - нужен заголовок XML с явным указанием encoding.

В последнее время пристрастился юзать анонимные блоки PL/SQL.
Особенно если речь идет о "траспорте наружу" или "отчетниках" - параметры как таковые не используются внутри пакета, а просто ретранслируются на внешние обработчики. При этом PL/SQL блок можно править "на ходу" в любое время
- инвалидирования пакетов (и вопли юзеров - "все сломалось") из-за изменения количества параметров и каких-то простейших дополнений в код не будет.

На этом все, наверное. До связи :)

Petro123,

У меня есть опыт в back-end для .Net/ASP приложений - там без XML вообще никак.
Когда как следует врубишься в XML - какая разница, на какой платформе его юзать.
Тем более в Oracle очень много средств под него.

Вообще, выскажу может быть крамольную мысль для данного форума.
APEX - это конструктор web-приложений для PL/SQL программистов.
Все мои знакомые "реальные" java-программисты либо не знают либо очень спокойны к APEX - он им не нужен совсем.
APEX не конкурент огромному зверинцу java фрэймворков и платформ. Даже чисто визуально по-юзерски - странички на JBOSS например рендерятся заметно резвее APEX . Ну а среда разработки APEX - хоть и красиво местами, но тормоз страшный. А писать код в черно-белых диалоговых html-окошках - вообще удовольствие небольшое.

Когда-то я интенсивно рубился на Powebuilder - немного знакомился с совсем редкой нишевой web-платформой от Sybase - Appeon. Интересные идеи, но кому они нужны при гегемонии java.