form开发笔记（一）

 

1、开篇

    我在项目上的首个form开发是杂项费用定义界面的开发。下面是我的开发笔记。

2、开发步骤

    项目上有关于form的标准模板，这个模板是整合了所有与具体开发无关的项，比如添加folder函数库，对象组，以及folder特有的item等等，省却了我们很多的麻烦，而这些在黄老的folder开发指南中有详细的步骤，不详述。

总体的开发步骤如下：

1）根据基表写视图，注意命名，视图里用的是不带all的同义词，视图具有MOAC安全性。 

2）给form命名、修改form的PRE-FORM、WHEN-NEW-FORM-INSTANCE 触发器            

3）基于视图建立block；建立对应的prompt块                                            

4）建立画布、把第三步生成的item发到画布上                                 

5）修改PROMPT 名，拖拽生成                                                 

6）生成视图增删改 package cux_0_plsql_autocreate.form_view_iud          

7）编写lov、block trigger代码。                                           

  其中，block级trigger是对主从块添加四个on- 开头的trigger，要建立以块命令的private包，trigger调用包中的过程，实现视图的增删查改

 

3、预备役基础知识

    在我们做form开发的时候，需要弄明白的一点就是：基表，视图以及form三者的关系，要明白它们三者之间是如何进行联系的：数据库基表的数据是如何显示到前台界面，我们在form中录入的数据又是如何存储到后台数据库中的。

3.1、基表，视图和form的关系——从后台基表到form前台界面；

   

    首先，每一个form界面都必然对应一个相应的后台基表，这个基表是储存所有前台显示数据相关的字段，它储存的是对应的id和code。

    这些id和code如何展现到前台呢？

通过视图；我们新建的各个block块很多都是基于视图的；

Form是客户化的，后台存储的id和code可能开发人员都不清楚每一个具体代表什么意思，因此在创建视图的时候会根据这些字段关联到其他的表，从这些表中取出id、code相对应的中文名称。视图是做什么用的？实际开发中我们基于视图view创建数据块，我理解为：视图只是专门用来在form前台呈现数据给用户看的，没有其他的作用。我们在前台所做的增删查改四种操作，只有查会用到视图，静态的视图，其他三种会引起数据库数据改变的动态操作是通过调用private包内的过程实现的，和视图没有任何的关系。没做form之前我还以为前台数据会通过视图进行反编译出对应的后台字段，我果然太天真了~~~现在明白：视图只是单纯的显示数据用~

    而我们在前台录入的数据，在点击保存的时候，是通过调用我们写的对应的private包(后面详述)实现的对数据的增删改~

3.2、lov列和list的区别

    Lov列和List都可以实现指定数据的范围进行选择。

它们的共同点：

a.都可以供用户选择指定范围的数据；

    b.Lov和list对数据的修改都是在form层中进行修改，对view是没有影响的，只有在点击保存的时候，会触发触发器调用private的包，对基表进行DML操作，从而将我们所做的修改保存到基本表中；

 

它们的区别：

区别一：

lov只是在用户修改数据的时候会用到，比如要修改一个物料编码，我点开lov，选择一个进行修改；在不进行修改操作的情况下，只是查询数据，那么lov本身是不起任何作用的； 而且我们在lov中显示的值一般都会在视图中查找出来；

而list在显示数据的时候，一直在生效；可以把form界面分为form层的前台和后台，前台显示数据，后台存放对应的值；同样的一个值列表：

 中文名：“按通知单行”对应基表中存储的字段： MEMOLINE

 

如果使用lov值列表实现，那么前台我们见到的数据项只有一个，但是后台却需要两个数据项来储存数据；  我们需要在form中建立两个item，其中一个存放中文名：用来在前台显示数据；另一个存放对应的code值：在增改操作的时候写入数据库时用到；

 

如果使用list值列表，那么我们前台见到的数据项只有一个，后台需要的数据项也只要一个；list本身相当于是在前台和后台中间建立了一个转换器，我们在后台存储的code值经过list转换器会自动转换成对应的中文名，显示到前台界面；也就是说form后台存储的是code值，但是我们在前台看到的却是对应的中文；

 

可以参照list定义值的结构进行理解：

它就是一个翻译软件~

因此在建立视图的时候，我们没有必要把去关联N多张表，把code对应的中文名取出来，而是可以直接在form层使用list值列表定义其对应的中文名；

一般在快速编码中会用到这种方法；见知识点XX

注意，如果某个item属性是list，它的列表值是快速编码中的值，需要调用一个函数，难点：函数的作用就是将我们编写的类似lov的sql语句的records值指定给list列表值，同时，我们要给这个list指定一个初始值，不然编译时会报错。这时候，我们点击下拉列表，列表值就是我们定义的初始值和records值；

 

区别二：lov列表值可以指定返回多个item，而list列表值只能返回值给当前的item；

 

3.3  moac安全性控制与按ou屏蔽

 

我对moac还没有怎么深入的研究过：目前我对moac的理解是，在form中，会启用moac进行安全性控制；

我们所打开的form，都是定义在某一个具体的职责之下的，但并不是每一个职责都可以访问到所有的后台数据；比如，一个大公司，它在北京，上海都有分公司，它们共用一个ebs系统，数据库中储存了北京公司和上海公司的业务数据；

现在，系统中定义了两个职责：北京分公司办事处和上海分公司办事处；

 

进入北京分公司办事处的操作人员在对数据库中的数据进行修改时，是不允许对上海分公司的数据进行任何操作的，严格上来说，北京分公司的人在查询数据的时候，上海分公司的数据都不应该显示出来；那么，这个是如何实现的呢？

通过定义安全性配置文件，实现moac安全性控制；

Moac安全性配置文件中会定义该职责能够访问哪些ou，在我们进行查询数据的时候，从数据库中查询出来的数据，会经过配置文件的过滤，过滤掉所有没有定义的ou的数据，只把该职责下允许访问的数据显示出来；

按Ou屏蔽不是指在语句的条件中进行所谓的指定org_id=块.org_id，这等价于moac初始化；

举个例子：在多ou的情况下，比如：订单超级用户下有两个ou：江苏和浙江，后台表中江苏的ou下定义了费用类型，有四个值；而浙江下没有定义费用类型；

此时，在form中，即使你选定的ou是浙江，在点击lov值列表选择费用类型的时候，即使浙江并没有定义，但是依然可以选出四个费用类型；可以理解为，这个费用类型是该职责下所有的ou所公用的；唯一的区别是：要在配置文件中定义好该ou是否可以访问其他的ou；默认的是当前的ou只能访问当前ou的数据；

 

所谓的跨ou的业务：是指在同一个订单类型定义界面，在选择订单类型的时候，我可以选择多个不同的ou数据，就是说同一个页面，有多个ou的记录，当然，保存到数据库中的时候可以根据org_id进行指定； 就像下面的数据，多ou；

像我一开始的时候，指定lov值列表是使用的:

Where org_id=fnd_profile.value('org_id');

这样取的是当前的ou职责下，form级的默认org_id，对于多ou的情况下，那么该lov值只能选择到当前form级org_id对应的ou下表中定义的数据，当我们的行选择的是另一个ou的时候，因为form级的默认ou是不变的，块级的ou只对当前块的当前记录有效，所以如果上面那样指定的话，lov返回的是上一行的相同的结果；这样，就无法实现多ou的智能判断取值，应该使用：块名.org_id，这样取的就是数据块的值了；

 

一般一个职责下有多个ou，我们在进入和ou有关的form的时候，会弹出一个值列表，让我们选择是在哪个ou下，我们进入后，当前的form级org_id就是该org_id，如果当前form支持多ou，那么在选择ou的时候，我们可以选择其他的org_id，也就是块级的org_id；form级一般有一个默认的org_id，在配置文件中进行定义；

 

3.4、安全性配置文件的定义和分配

分配安全性配置文件

路径：系统管理员—配置文件—系统：指定责任、MO%配置文件，可进行分配，定义默认的业务实体；

如何查看、定义moac对应的配置文件内容？  B02_CB000_华润啤酒

职责：%HR%超级用户%--安全性—配置文件   可查看和定义配置文件中定义的ou

我所在项目上职责划分很清晰，基本是的单OU；

 

4、开发步骤详解

4.1、根据基表写视图

 

视图必须具有moac安全性，也就是说对基表的引用必须使用同义词，moac对ou数据的访问控制可以理解为：在form界面中我们使用Ctrl+F11，从all表中查询出所有数据后，因为moac安全性配置文件，会将所有不在配置文件中的ou的数据全部自动过滤掉，只留下符合条件的ou下的数据；

建表：

我们所做的form开发，首先判断是否需要新建数据库表？如果需要建表，判断是否有org_id字段，需要ou屏蔽？一般如果表中具有org_id即业务实体字段，都是受moac安全性控制，建表的时候需要建一个带_ALL的表(CUX_2_PX_MIXFEES_TYPES_ALL)和一个不带_ALL的同义词(CUX_2_PX_MIXFEES_TYPES)，建立同义词的sql语句：

 

CREATESYNONYMAPPS.CUX_2_PX_MIXFEES_TYPES FORCUX.CUX_2_PX_MIXFEES_TYPES_ALL;

BEGIN

 dbms_rls.add_policy(object_name    => 'CUX_2_PX_MIXFEES_TYPES',

                      policy_name     => 'ORG_SEC',

                      policy_function => 'MO_GLOBAL.ORG_SECURITY',

                      policy_type     => dbms_rls.shared_context_sensitive);

END;

 

建视图：

当我们建好或找到我们所需要的基表以后，可以开始写视图了。

视图中所需要包含的字段，包括：

 

Rowid字段+基表中的所有原始字段+form前台显示字段

 

其中，如果需要ou屏蔽，基表需要使用同义词，从表不用；

所谓的moac安全性会在查询数据的时候自动过滤掉所有不在配置文件中定义的ou数据，只保留定义了的ou的视图数据；

 

注意：正式的视图中不能包含中文，否则程序迁移的时候会出现问题。如果需要有中文作为参考，可考虑使用两个版本

4.2、给form命名、修改form的PRE-FORM、WHEN-NEW-FORM-INSTANCE触发器

指定触发器中的form为我们自己编写的form文件名，其中：

在对某个form进行修改的时候，修改完成以后最好在PRE-FORM触发器中修改日期为当前日期，