简介《Oracle APEX深入浅出》面向希望快速上手 Oracle APEX 并构建企业级 Web 应用的开发者也可供已接触 APEX、需要系统梳理开发流程与常见控件用法的人员参考。压缩包内共 1 个 doc 文档约 8.11MB内容以开发指南形式组织便于按章节查阅。文档覆盖 APEX 系统探究、环境搭建、账户与权限管理、开发概要、页面布局与美化、常用控件、Report 增删改、文件上传下载、CSS 与 JS 应用、图表报表、插件及部署等主题并延伸到调试技巧、常用 API 与 EBS 集成场景。已有 1593 人学习适合用来建立 APEX 知识框架、对照实践查漏补缺并积累企业应用开发中的实现思路。1. 反直觉的起点APEX 页面根本不存在于文件系统里做 Oracle APEX 深入开发绕不开一个反常识的事实你在浏览器里看到的每一个页面服务器上都没有对应的文件。没有 .jsp没有模板目录整个应用——页面、区域、按钮、校验、授权规则——全部以行记录的形式存放在数据库的表里。浏览器发来的那个很长的f?p...URL会被解析成一次 PL/SQL 调用数据库跑完这段代码用htp.p把拼好的 HTML 直接返回给浏览器。搞懂这条调用链后面许多看似难解的现象也就有了原因为什么升级 APEX 只需要跑几个脚本、为什么改一个按钮属性不需要重新编译、为什么同一个页面第二次打开会「丢失」上次填的值。这些都不是平台特有的怪癖而是「应用即数据」这个选择的必然结果。2. 请求怎么走完一轮从浏览器 URL 到 htp.p 输出 HTML2.1 三层结构里中间那层没有业务逻辑APEX 的部署形态只有三层浏览器、Web 监听程序、数据库。监听程序这一层可以是 Oracle 11g 自带的嵌入式 PL/SQL 网关EPG也可以是 Apache 上的 mod_plsql或者独立的 APEX Listener。三者的差别只在「谁负责把 HTTP 报文翻译成一次数据库调用」翻译完就没它们什么事了。这跟常见的 Java 应用完全不同。Java 那边中间件是重资产连接池、线程池、会话复制、类加载器每一块都要调。APEX 把中间件做成了几乎空壳真正的执行体全在数据库进程里。好处很直接——不用部署 WAR 包不用管 JVM 堆内存不用纠结版本兼容升级就是把一组 PL/SQL 对象重新编译一遍。代价同样直接所有压力都压在数据库上。一个渲染慢的页面占用的是 shared pool 的游标缓存和 PGA 的排序区跟业务 SQL 抢的是同一份资源。所以在 APEX 项目里经常能看到「加个索引页面就快了」这种反直觉的调优方式——不是页面需要索引是页面背后那条查询需要。注意10g 时代 EPG 的能力有限必须额外挂 mod_plsql 或监听器11g R1/R2 的嵌入式网关配置简单拿来搭开发和验证环境足够生产环境仍然建议独立监听器把 HTTP 层和数据库层分开。2.2 异步会话状态管理APEX 为什么敢不用传统 Session传统 Web 应用的会话是「服务端内存里的一块对象 客户端一个 Cookie 指向它」。APEX 反过来页项目Page Item的值不常驻在任何进程的内存里而是序列化后写进数据库表靠会话 ID 关联。会话 ID 出现在 URL 里比如f?p100:2:0::NO第三段的0表示这是一个新会话引擎会分配一个真正的 ID 再重定向。这种被官方称为异步会话状态管理的机制带来几个不太明显但很关键的后果。第一会话可以被随时清理。数据库重启、管理员点了「清除会话」都不会让应用崩掉最多是用户填了一半的表单值没了。这是「可丢弃」设计换来的稳定性。第二多节点天然共享。因为状态在表里不在内存里前面挂几个监听器、后面几个实例都不需要做会话复制。第三也是新手最容易出问题的地方页项目的值有生命周期。渲染页面时引擎从表里把值读出来填进:P2_X_TEXT提交时再写回去。如果某个 Process 执行时机排在「页面渲染」之后它读到的:P2_X_TEXT就不是你以为的那个值了。APEX 里 Process 的执行时机Execution Point选项多本质就是在让你声明「我要在状态读出来之前还是之后跑」。2.3 一次页面渲染的完整时序把引擎拆开看一次请求大致经过五步解析 URL 得到应用号、页面号、会话号和请求名认证服务确认你是谁授权服务确认你能不能访问这个页面/区域/按钮页面流控制跑提交阶段的 Process 和分支最后页面渲染和处理逐个 Region 取元数据拼 HTML。原文把引擎组件列为六项——异步会话状态管理、认证服务、授权服务、页面流控制、验证处理、页面渲染和处理——基本就是这条链路的切分方式。用一段骨架代码把这五步串起来比看十页文档直观-- 高度简化的渲染骨架用来理解 APEX 引擎在数据库里到底做了什么 -- 真实实现分散在 wwv_flow_* 系列包里这里只保留主干 declare l_app number : 100; -- 应用编号URL 第一段 l_page number : 2; -- 页面编号URL 第二段 l_sess number : 0; -- 0 表示新会话需要分配真实 ID l_req varchar2(30) : SEARCH2_BTN; -- 请求名通常就是触发的按钮名 begin -- 1. 会话0 就新建把会话 ID 与页项目值落到表里 wwv_flow_session.create_session(l_app, l_sess); -- 2. 认证管理员页走 APEX 账户业务页可切到 HTTP Header 变量 wwv_flow_security.check_authentication(l_app); -- 3. 授权页面、区域、按钮三级任意一级不通过就跳过渲染 wwv_flow_security.check_authorization(l_app, l_page); -- 4. 页面流控制先跑提交阶段的 Process再决定分支 wwv_flow_process.run_on_submit(l_app, l_page, l_req); -- 5. 渲染按显示序列逐个 Region 取模板拼成 HTML 片段 for r in (select region_id, template from wwv_flow_regions where flow_id l_app and page_id l_page order by display_sequence) loop htp.p(wwv_flow_render.region(r.region_id)); end loop; -- 6. 落盘把最终状态写回会话表便于下次请求续上 wwv_flow_session.save_state(l_sess); end;这段代码不是官方源码是把官方文档描述的管线压缩成可读形式。l_req那个参数值得单独说APEX 里按钮的名字会作为请求名提交上来Process 上配的「When Button Pressed」就是拿它做字符串比对。所以两个页面上的按钮重名或者按钮改名后没同步改 Process都会导致 Process 静默不执行——不报错只是数据没动这是排查时最难抓的一类。wwv_flow_render.region这一步也解释了为什么「改一个 Region 属性立刻生效」模板和属性都是表里的数据下次请求读到新值就用新值渲染没有编译产物需要重建。声明式开发省掉的不是代码量是构建流程。3. 声明式属性怎么变成 HTMLGrid Layout 与 Page 0 的语义3.1 Body 区域是 TABLEPosition 区域是 DIV一个主题选定之后页面的骨架其实就固定了外层是 DIV CSS 的容器中间把几个常用位置开放给开发者使用——Body1、Body2、Body3 和 Position1 到 Position4。区别在于Body 区域在 HTML 里是用TABLE渲染的Position 区域是用DIV渲染的。这个区别决定了它们的用法。TABLE 是有行列语义的放进去的东西会自动对齐成网格适合表单类的规整排版DIV 脱离了表格流可以自由定位适合悬浮层、侧边栏、需要绝对定位的装饰块。很多人抱怨「APEX 排版死板」基本都是把需要自由布局的东西塞进了 Body 区域。理解这一点之后Grid Layout 那一堆属性就不再像玄学了!-- Body 区域渲染成一个 TABLEPosition 区域渲染成独立的 DIV -- table classt_Region tr td!-- Body 1 -- div idP2_SEARCH1_CONTAINER文本框 P2_X_TEXT/div /td td!-- Body 2 -- 按钮 SEARCH2_BTN /td /tr tr td colspan2!-- Body 3 -- 日期选择 DATA /td /tr /table div idP2_POSITION1 !-- Position 1不参与表格布局可以自由定位 -- /div上面这段 HTML 是渲染结果不是手写的。它对应的就是三个 Body 区域在 Grid Layout 里配的那三组开关。3.2 Start New Grid / Start New Row / Column 三个开关的真实语义APEX 的 Grid Layout 属性不多但每个都直指 HTML 的表格模型Start New Grid为 Yes 时当前对象另起一个TABLE不沿用上一个表格的列结构。所以它决定了「列数能不能重定义」。Start New Row为 Yes 时当前对象换行落下TR。Column当前对象落在这一行的第几列也就是第几个TD。拿原文那个例子对照就很清楚。Search1、Search2、Search3 三个区域属于同一个 TABLEColumn 依次是 1、2、2Start New Grid 依次是 Yes、No、NoStart New Row 依次是 Yes、No、Yes。翻译成人话Search1 开新表、新行、第一列Search2 不换表不换行挤在第二列Search3 不换表但换行落在第二行的第二列。New Search1、New Search2、New Search3 那组则是 Column 依次 1、2、3Start New Row 依次 Yes、No、No——一行三列排开。两组配置的区别只在 Start New Row 的第二个值上一个 Yes 一个 No最后呈现的布局完全不同。这也是为什么 APEX 的布局调整经常要试几遍才调对力的作用点太集中改一个开关整块的相对位置都变。一个经验先把想要的 HTML 表格结构在纸上画出来标好哪几行、每行几列再倒推这三个属性比在界面上反复点快得多。反过来看到别人的页面布局乱了也先去看它的 Start New Grid / Row 组合基本能立刻定位到是哪一层多开了表或者少换了行。3.3 Page 0 不是母版页它是全局状态的落脚点Page 0 经常被误解。它看起来像母版页实际语义是「这个 Application 的全局页」——某些全局变量、全局常量在这里定义为了整齐可以按类型分几个区域放这些区域在界面上不可见类似 HTML 里的 HIDDEN。它和母版页的关键差别在于母版页关心的是「外观长什么样」Page 0 关心的是「值从哪儿来」。放在 Page 0 上的计算Computation和默认值逻辑上是应用级的每个页面都能用上。这里有个很容易踩的时序问题Page 0 上定义的计算和其他页面上的计算执行顺序是分开的。如果你在 Page 0 里给某个全局项赋了默认值又在具体页面上用了它得确认 Page 0 的计算确实在依赖它的那个 Process 之前跑完。APEX 里计算和 Process 都有执行时机选项配错了顺序就会出现「有时拿到值有时拿到空」的间歇性故障而且因为不报错查起来很费劲。3.4 声明式属性的求值顺序控件的属性很多但真正会互相影响的就那么几个Value Required是否必填、Condition Type满足条件才显示、Read Only Condition Type满足条件才只读、Default value、Format Mask。它们不是平行生效的大致遵循「条件判断 → 默认值 → 只读/可编辑 → 必填校验 → 格式掩码」的层次。搞清这个顺序的实际价值在于排查。比如一个字段「明明配了必填提交却没拦住」常见原因是它同时配了 Condition Type而条件不满足时整个控件都没渲染出来——没渲染的控件不参与校验。又比如「配了默认值但页面上是空的」往往是 Default value 只在新建时生效而当前会话里这个页项目已经有历史值了。Dynamic Action 这一层也是同样道理。它渲染时会被编译成一段绑定脚本输出到页面而不是每次请求都跑一遍// 页面上配的 Dynamic Action 最终会输出成一段绑定代码形态大致如下 apex.jQuery(#P2_X_TEXT).on(change, function () { var v apex.item(P2_X_TEXT).getValue(); if (v ! ) { apex.jQuery(#P2_NEW_SEARCH2).hide(); // True Actions 分支 } else { apex.jQuery(#P2_NEW_SEARCH2).show(); // False Actions 分支 } });这段代码说明了 Dynamic Action 里「执行 PL/SQL」那个动作的性质它是异步请求走的是同一套f?pURL只是把请求名换成了动态动作的名字。所以它同样受认证和授权的约束——有时候点了按钮没反应不是 JavaScript 挂了是那次异步请求被 302 重定向到登录页了。打开浏览器网络面板看一眼状态码比在页面上点十遍有用来得快。4. Tabular Form多行增删改为什么不跳页也能生效4.1 为什么建议基于视图开发APEX 处理单条记录的增删改标准做法是「点链接跳到新页面改」。而 Tabular Form 是另一条路一屏展示多行改完直接提交不跳页。原文提到这种开发方式类似于 EBS 里的 Form 开发而且建议基于视图来做这两点是有内在关联的。基于视图的好处是脱离了「一表一表单」的限制。多张表 join 出来的字段可以放在同一行里编辑用户看到的一行就是一次业务操作而不是三个物理表的拼接。代价是视图本身不可更新得靠 Process 手工落库。所以 Tabular Form 的真实结构是视图负责读Process 负责写。读和写之间没有 ORM 帮忙搭桥全靠你写的 PL/SQL 对上号。这也是它比普通 Form 更难写、但更灵活的原因。4.2 从提交到落库的顺序一次 Tabular Form 的提交顺序大致是行级校验Validation可以配「When Button Pressed」指定由哪个按钮触发→ 页面级计算 → Process 执行 → 分支跳转。原文里那个例子的需求很典型改login_name时校验class_name在另一张表里存在不存在报错存在则把勾选的记录插到第三张表。把它写成代码就是-- 执行时机On Submit - After Computations and Validations -- 作用遍历 Tabular Form 的每一行做跨表校验并写入明细表 declare l_cnt number; begin -- apex_application.g_fNN 与 Tabular Form 的列一一对应按视图 SELECT 顺序编号 -- 例g_f01user_id g_f03登录名 g_f04班级名 for i in 1 .. nvl(apex_application.g_f01.count, 0) loop -- 只处理实际提交上来的行未勾选的行不会进数组 if apex_application.g_f01(i) is not null then -- 跨表校验班级名必须已存在于主表 select count(*) into l_cnt from demo_class where class_name apex_application.g_f04(i); if l_cnt 0 then raise_application_error(-20001, 班级不存在: || apex_application.g_f04(i)); end if; -- 校验通过写入明细表 insert into demo_user_class (user_id, login_name, class_name) values (apex_application.g_f01(i), apex_application.g_f03(i), apex_application.g_f04(i)); end if; end loop; end;几个参数和细节值得说明。apex_application.g_f01到g_f50这五十个数组分别对应 Tabular Form 的前五十列顺序严格按视图里 SELECT 的列顺序来。视图改一次列顺序所有引用了g_fNN的代码全部错位而且不报语法错只会把数据写到错误的字段里——这是血泪经验里最贵的一课。数组的「行号对齐」也很关键。g_f01(3)和g_f04(3)指的是同一行的不同列所以能这样按下标交叉取值。但只有提交上来的行会进数组页面上因为分页或者条件隐藏掉的行不在里面因此不能假设「数组的第 i 个元素就是页面上的第 i 行」。raise_application_error这一句会被 APEX 捕获转成页面上的错误提示条。用自定义错误号-20000到-20999区间而不是-20001以外的系统错误号可以避免把内部报错暴露给最终用户。最后这段代码放在「After Computations and Validations」这个时机意味着校验已经跑完、计算已经算完读到的是本次提交的最终值。如果放到「Before Computations」拿到的是上一次的状态——数据看着像改了重新打开又是旧值很容易让人怀疑是浏览器缓存。4.3 客户化逻辑该写在哪一层写多行表单的时候业务逻辑放哪儿是个设计题。粗粒度分三处Validation只做「不满足就拦住」不产生副作用。适合必填、格式、存在性校验。Process做真正的写操作可以做多表联动但要保证可重复执行不出脏数据。Dynamic Action只做界面反馈不承担业务正确性。用户看到的即时提示是它最终判定还得靠 Validation 和 Process。三者的边界一旦弄混就会出问题。比如把「班级存在性校验」只写在 Dynamic Action 里用户关掉 JavaScript 或者网络慢一点脏数据照样能进库。前端提示是体验后端校验才是底线。5. 避坑与排查安装、控件、提交三个阶段的典型故障5.1 安装与登录阶段现象一管理员页面打得开但 ADMIN 账号死活登录不进去反复改密码没用。原因往往不在密码。11g 数据库自带 APEX 3.0如果新版本装上去之前没有彻底清理旧版本的对象系统里会残留一批 3.0 时代的用户和元数据认证走的分支还是老的那条。原文记录的排查路径很典型改了密码、重启数据库、确认APEX_040200用户存在且正常全都无效最后跑 SQL 一查发现旧版本的用户还在。解决方式是安装前把旧版本的用户全部 drop 干净安装后再确认新版本用户是唯一的一套。这里有个附加的坑清理的时候手一抖把APEX_040200也 drop 了就只能整个重装。所以清理脚本建议先select出待删列表确认无误再执行删除别直接drop user ... cascade一把梭。现象二访问管理页面返回 HTTP 404数据库和服务都在跑。这是嵌入式 PL/SQL 网关没起来。11g 的 EPG 不是默认常驻的需要通过dbms_xdb相关配置开启或者用alter system register让监听器识别到 8888 端口。判断方法很直接在数据库里查 EPG 的端口配置和 HTTP 监听状态再在服务器本地curl一下那个地址。本地通、远端不通就往防火墙方向查本地都不通就是网关本身没起。另外别忘了APEX_PUBLIC_USER和ANONYMOUS的解锁。安装脚本不会替你解得手工ALTER USER ... ACCOUNT UNLOCK锁着的时候报的错和密码错误几乎一样很容易误判。5.2 控件与动态动作阶段现象三Dynamic Action 里配了 Set ValueSQL 语句是对的但页面上的字段一直是空的。按概率排先看「Affected Elements」里选的 Item 是不是当前页面的、名字有没有拼错。APEX 的页项目名是全局唯一的P2_X_TEXT和P2_X_TEXT1差一个字符就是两个东西而配置界面是下拉选的手误改成新建项也不会报错。再看执行时机。Page Load 型的 Dynamic Action 在页面加载时跑一次如果那个 Item 本身声明在某个条件区域里、加载时还没渲染出来Set Value 就找不到目标。这类问题的特征是「刷新几次偶尔对一次」因为渲染顺序有微小差异。最后才怀疑apex.server.process那一条异步请求被认证拦了。判断方法前面说过看网络面板的状态码。现象四控件配了必填却没拦住或者配了只读却能改。必填失效八成是这个控件同时配了 Condition Type本次渲染时条件不满足控件压根没输出到页面上。没渲染就没校验这是符合逻辑的只是不符合直觉。只读失效则通常是属性配在控件上、而按钮触发的 Process 里又显式给这个项赋了值——Process 赋值不受界面只读约束。排查顺序建议固定成先看控件有没有渲染出来看源码里有没有那个 id再看条件属性的判断结果最后看 Process 里有没有覆盖。5.3 提交与部署阶段现象五Tabular Form 点了「Apply Change」页面提示成功但数据没变。三个高频原因。一是视图不可更新且没有对应的 ProcessAPEX 不会替你猜怎么写。二是g_fNN的列序号和视图的 SELECT 顺序对不上值写到了别的字段里。三是 Process 配了「When Button Pressed」但按钮名改过Process 静默不执行。验证方法在 Process 第一行加一句把数组长度和第一个值写进调试日志跑一次看有没有进。进不来就是按钮名或执行时机的问题进来了但数据不对就是列序号的问题。现象六开发环境一切正常导到测试环境后功能大面积失效。APEX 的应用导出只带走元数据不带走数据库对象。表、视图、序列、触发器和授权全得单独准备。原文在部署那一章把这件事拆成「导出应用 准备 schema 对象 重新配置环境相关项」三步顺序不能反。还有一个隐蔽点应用导出文件里的 schema 是硬编码的。开发环境用 A schema测试环境是 B schema导入后所有 SQL 和 Process 都会因为对象找不到而失败而报错信息往往只说「表或视图不存在」不看导出文件根本想不到是 schema 的问题。习惯上导入前后各跑一次对象依赖检查比事后一个个功能试要省时间。6. 设计取舍把应用存进数据库的代价与边界「应用即数据」这个选择把 APEX 和绝大多数 Web 框架分到了两个阵营。它换来的东西很实在维度应用即数据APEX应用即文件典型 Web 框架部署动作导出一份元数据、导入即可构建产物、发布、重启服务升级方式跑脚本重编 PL/SQL 包换依赖版本、重新打包状态存放数据库表可清理可共享应用内存或外部缓存扩展瓶颈数据库资源应用服务器资源调试入口数据库会话与调试日志应用日志与 APM这张表也说明了它的边界。数据库能扛住的量APEX 扛得住而且比应用服务器扛得更稳因为事务、锁、一致性这些事它本来就在做。但一旦瓶颈落在「页面渲染的 CPU 开销」而不是「SQL 执行」加机器就只能加数据库而数据库加节点远比加应用服务器贵。所以我的判断标准一直是内部管理类应用、表单密集、并发在千人以内、数据一致性要求高——这类场景 APEX 的收益压倒性。面向公网的高并发展示型页面交给别的技术栈更合适。强行用一把钥匙开所有锁最后难受的是维护的人。验证一个 APEX 应用做得好不好我看三件事Process 里有没有显式声明执行时机、Tabular Form 的列序号有没有注释、导出文件的 schema 是不是可配置的。这三点齐全说明作者真的理解引擎是怎么跑的而不是照着拖拽教程拼出来的。早年接手一个跨模块的系统时就是因为没检查第三点把一个写着固定 schema 的导出文件直接导进了另一套环境跑起来报了三十多个对象不存在一个个改配置文件改到半夜。从那以后我每次导出应用都强制先看一眼文件里的 schema 是不是已经参数化了再决定要不要导入。希望帮到你。本文还有配套的精品资源点击获取
