Oracle删除当前用户下的所有表、视图、序列、函数、存储过程、包 Oracle删除当前用户下的所有表、视图、序列、函数、存储过程、包
创建一个pageLayout区域时,应该特别注意下面的属性:
每个item类型都有自己的一套属性,不可能每个都介绍,这里介绍一些通常的公共属性。
对于所选的属性,OA Framework支持使用SPEL表达式快速的将属性绑定到下层数据源提供的属性值上。比如,你可以将按钮的Rendered属性绑定到一个视图对象的属性上以检查是否需要显示或隐藏。属性中使用的SPEL语法如下:
技巧: SPEL是一个业界标准的表达式语言,它包含于JSTL中。
可以按下面的步骤创建共享的region。
可以从任何区域的单个item继承,尽管我们推荐将准备重用的item放到一个重用region中。共享容器region将确保不会任意的修改item而不明确这样修改将影响使用这个item的页面。
通过设置item的Extends属性设置共享。
属性集是一个命名了的可重用的属性集合,可以用于任何OA组件,包括regions,items和其它属性集。它被设计为可以在整个Oracle Application中可以重用的组件,它有效的节约了Oracle和其客户的开销。
通常,attributes sets被组织到OA组件包中(独立的XML包文件中),这个包与数据训表对应,一个包对应一个表:
在下面的情况下使用属性集:
在item上使用属性集:
可以在控制器中访问属性集。比如,下面代码显示了如何保留通用的Create控制属性集的prompt属性。
当在页面定义中指定URL参数时,可以直接指定字符串值或使用token-substituted值,在渲染时它保留了从相关的视图对象的属性(item与视图对象绑定的情况下)。这是很常见的,比如,在表格的列中传递主键到明细页面以便于查询。
任何为请求指定的参数必须遵循HTTP语法规则。比如,不能在URL参数值传递空格;当访问的URL中包含:buyerName=John Doe时将产生运行时错误。
为修正这个错误,我们将对这些值进行编码,编码将替换有问题的字符,将值变为:byerName=John%20Doe。
技巧: 如果手工设置URL参数不包含非法字符(比如,“value=Y”)则不需要担心编码的问题。
加密处理将混淆参数值。由于URL请求参数可能是对用户可见的(用户查找HTML页面源码时也可以看到隐藏域的值),总是应该对存储于URL参数或隐藏域的数据进行加密。
所有添中到页面的的region和大多数的item都会自动设置风格。
技巧: OA Framework新手通常犯的错误是试图修改CSS style来修改组件“原生“的外观。如果发现这样做出了问题(比较困难因为样式设置不会在运行时起作用:
OA Framework自动将custom.xss设置为了主样式。任何自定义设置可以添加到这个样式表。
oa.xss用于包含任何对于BLAF样式的修改。你不应该创建自己的样式表。
OA Framework应用是无障碍的,可以由盲人、弱视、色盲或聋人使用。
OA Framework应用被设计为完全本地化。国际化相关的章节讨论了关于语言、时区、日期的数字的国际化。
在指定好数据源绑定后,OA Framework自动从模型中读取数据以便视图显示,并自动将用户输入视图中的数据回写到模型。不需要编写代码(除了为下层的实体编写校验)。
注意: 实体对象的属性值实际不是存储于视图对象中的。它们“生存”于实体对象,可以被需要的视图对象访问。“计算(Calculated)”或“临时(Transient)”类型的视图属性是存储在SuppliersVORowImpl对象中的。
不论何时,浏览器发出POST请求,OA Framework将自动把用户输入表单的数据写入下层的视图对象,它再依次更新对应的实体。
注意: 下面的步骤假设数据库行所对应的实体对象已经被实例化和初始化(比如在进入Create页面时已经调用了视图对象的create方法创建实体对象)。
如上所述,OA Framework在每次form提交时写入模型数据,这意味着所有属性和实体级的校验都被执行。有几个机会让你“短路(short-circuit)“这些错误以防在不方便的时候报告给用户。
当使用“Create”页面创建新行时,可以在3个地方指定默认值:
下面的例子显示了创建新行的典型代码:
createRow()方法调用各个ViewRowImpl的create()方法。在调用create()过程中,OA Framework调用需要指定了缺省值的每个UI组件的setter方法,如果需要这些值将被应用(译:根据下文,应该是指应用到视图对象)。这确保了 视图行的校验和相关的实体对象属性的校验。然后OA Framework将视图行对象的状态重置为STATUS_INITIALIZED,以便它不被BC4J组件修改。这确保了用户导航到其它页面时将持有默 认值而不会产生丢失工作的警告。在缺省值的处理过程中检查到的任何异常通常都将显示出来。
技巧: 在视图行被创建后默认值只会被应用一次。如果你有一个多页面流带有多个区域,这个区域绑定到相同的下层视图对象——每个区域都对一个视图属性指定了一个不 同的Initial Value——只有第一个区域渲染时设置的缺省值会被关联。其它的将被忽略。同样,如果在Page A创建了一个新行,然后导航到Page B,在这里设置了一个属性的Initial Value,缺省值不会被应用,因为行对象是在Page B渲染前创建的。
对于下面的三种情况,OA Framework遵守下面的优先级:
如果需要确保默认值总是被设置而不管值有可能在设计器中指定,你可以覆盖视图对象的insertRow()方法:
在OA Framework应用中,页面中的菜单是用tab模型来实现的。
菜单结构提供了两个明显的用途:
导航功能表示出应用中的各个页面;每个页面与一个预先定义的功能关联。或许最重要的是,这个功能包含了页面的Web HTML Call。比如,在ToolBox Tutorial 应用中,当用户选择Lesson 3菜单项时,Purchase Order Search页被显示出来。我们为这个页面建立了一个功能,并设置它的Web HTML Call指向我们需要显示的XML页面:
注意: 单个页面可以被多个功能调用(每个可能通过URL传递不同的参数),它可以用于多个不同的菜单。
导航菜单是一组可重用的功能和子菜单的集合,它最终创建了上面所描述的tab结构。每个OA Framework菜单项都关联到某个Type,这决定了它应该如何被渲染。比如,在上面图表中的Lesson 2 tab的Type为“HTML Tab“。
导航菜单包含了所有可以显示于应用中的功能。你可以有选择的为导航菜单中的单个功能授权。这将在应用安全一节中详细描述。
应用安全包含的范围很广泛,在这个章节中我们将涉及一些关键的概念,以便对于它支持的内容及它与菜单定义的关系有个基本的概念。
Oracle应用中的责任是任务的集合,它被授给一个或多个用户。比如,你可能创建一个Benefits Manager和一个普通的Employee责任,两个都在HR应用中使用。你将把这些责任授给单个用户,以便用户快速访问这些模块。
所有的责任都与应用中单个顶级导航菜单相关联。导航菜单最终将包含你的应用支持的所有tab。
之前,责任是将用户按角色分组的主要机制。你可以将菜单分配给责任,并通过从你的责任中排除个别的菜单项来创建安全规则。在运行时,当前责任,组织机构和安全组一起包含了安全环境(secutiry context)。
在R12中,责任的概念被扩展为更广泛的角色(role)。用户可以属于一个或多个角色。所有用户被指定给一个特殊的责任时也被指定给也相应的角色 (role)。安全规则是基于许可发放(permission grants)机制,而不是功能排除规则。在运行时,这些许可的发放是在当前安全环境(security context)中被评估(evaluated)的,现在,责任,组织机构和安全组(secutiry group)中了也包含了角色(也被称为接受人(grantee))。
创建导航功能时,必须为页面创建授权功能(Authorization Fuctions也被称为“permissions”)。然后将这些许可(permission)分组到一个平坦(flat)的菜单结构中(也被你为许可 集合(permission set)),以允许用户访问相关的页面。
介绍许可集合(permission set)最简单的办法就是通过一个简单的用例。比如,假设你有一个非常简单的Benefits应用,它包含下面四个页面:
页面 描述 Benefits(利益)经理访问? 员工访问?
查看、修改、审核、取消审核benefits |
查看当前选择的benefit,并可将新选择的benefit设为自己的 |
如上面所说的,你需要为每个页面创建导航功能(Navigation Functions)并将它们组织到导航菜单中。为确保用户可以访问正确的页面,你需要按下面的过程处理:
与导航功能类似,许可是FND表单函数,但在这个环境中,它们只被用于应用安全。
在我们的例子中,我们可以使用为每个页面创建导航功能作为许可。不需要创建额外的许可功能。
接受人可以是一个用户(FND_USER)或用户组(被称为role)或“global”。用户(User)(译注:泛指系统用户,可以是人或组 织)在FND_USERS中被创建,应该被与单个的具体的人或组织一一对应。角色(Roles)在WF_ROLES中被定义,可以在客户的LDAP系统中 被映射到用户组。尽管成员没有被显式的增加,仍然有一个全局(Global)组包含有“所有人(everyone)”
在上面的例子中需要两个用户角色:一个用于将所有管理员(managers)分到管理员角色,另一个用户将包含所有的员工(employees)。由于员工包含了所有人,因此也可以使用全局(Global)角色。
另外,你也可以创建一个责任并把它赋给所有管理员,用这种方式设置授权(grant)。
我们将在第四步创建授权(grants)时将讨论这两种方法。
许可集合 被作为菜单来实现,但它们只是简单的将许可分组为平面的列表中以便获取许可。概念上,应该将根据角色需要将许可集合分组为一个或多个许可集。
上面的例子需要两个许可集:
Grant 定义了安全规则,公允许系统中的某些用户访问你的应用中指定的功能或页面。一次 授权(grant) 使 接受人(grantee) 可以访问上面描述的许可集。简单来说,授权将接受人和许可集连接起来。
也可以通过其它安全环境因素约束指定接受者(grantee)的授权(grant)。这些因素包括当前用户责任、组织机构、安全组。比如,为了将对管理员的授权(grant)限制在特定组织机构中,可以将组织机构信息与授权(grant)相关联。
可以将管理员许可集合授予管理员角色,也可以将它授予全局接受者(global grantee)。可以将带有安全环境信息的责任与那些允许访问的管理员关联,以限制哪些管理员可以访问。但是,OA Framework推荐使用基于角色的授权替代责任。
从上面的例子中,我们注意到可以将页面与许可链接来限制访问。这是使用许可来保护页面渲染的情况。
其它需要使用许可保护页面渲染的情况,包括匿名登录页面,页面需要自动责任设置或切换,且为共享/重用页面。
技巧一:把基础表与视图脱离开来。 一般来说,视图都是在基础表的上面建立起来的。也就是说,要先有基础表,而后有视图。但是,在大型数据库的设计过程中,出于项目时间的考虑,往往基础表与视图的设计是同时进行的。如一些人负责基础表的建立,另一些人则负责视图的设计与建立等等。
在这个过程中,往往基础表不存在的时候,就需要建立一些视图,以加快项目的进度。 为了使得基础表的创建和修改与视图的创建于修改没有必然的联系,以便于员工之间工作的同步,提高工作效率,所以,在Oracle数据库中提出了一个“强制创建视图”的概念。
也就是说,正常情况下,如果基本表不存在,则创建视图就会失败。但是,我们可以在创建视图的过程中,加入一个参数,只要创建视图的语法没有错误的话,即使基础表不存在,仍然可以建立这张表格。这个有用的参数就是force选项。如我们建立视图时,CREATE FORCE VIEW TEXT,只需要在关键字VIEW之前加入FORCE参数即可。
如此的话,系统在编译视图的时候,就不会去考虑基础表是否存在。 不过这里要注意一点,若基础表不存在的话,则编译后该视图的状态为“无效”,不能再这个视图的基础上执行一些操作,如查询操作等等。当下次访问这个视图的时候,则数据库会对这个视图进行重新编译,若此时基础表存在了,则该基础表就会变为有效;若基础表不存在,则这视图就会失效。
Oracle数据库之所以如此设置,主要是出于在数据库设计过程中协同办公的需要。有了这个功能之后,则在数据库建立的过程中,只要把数据库基础表与视图设计好之后,大家就可以分工合作,在数据库中建立相关的对象。不然的话,要等基础表建立好之后再建立视图,如此就会明显的影响数据库建立的进度。
所以,在数据库建立的过程中,特别是中大型的数据库系统,这是一个很实用的功能。 技巧二:创建视图的理想步骤。 无论是简单视图,还是比较复杂的视图,笔者觉得数据库管理员在创建视图的时候,最好能够遵循一定的步骤。这一方面是因为视图的更改相对来说,是一件比较麻烦的工作,所以,我们在建立视图的时候,要确保视图的准确性。
另一方面,视图是基础表的一个体现形式,若不按步骤来做的话,有可能就不能够达到我们预计的需求。 当然这个步骤没有官方的版本,完全是数据库管理员根据实际的经验总结出来的。这个步骤不仅对Oracle数据库有效,对于其他数据库来说,也是类似的道理。
一般来说,视图创建可以分为五步走, 第一步:先考虑Select语句的编写。我们知道,视图其实就是一个Select语句的集合。所以,我们建立视图的第一步,就是考虑这个Select语句该如何编写。这个Select语句编写的是否合理、执行效率的高低直接影响着这个视图的性能。
另外,在Select语句中,可能还会有格式的控制、内容的编排等等。如在Select语句中,可以把一些字段合并成一个字段;也可以把相关的内容进行倒置等等。这些功能都是Select语句完成的。所以可以这么说,Select语句的编写是视图建立的基础。
第二步:对这个Select语句进行测试。当我们编写好Select语句之后,就需要在数据库中执行这条语句,看其能否查询到我们想要的值。在对Select语句进行测试的时候,需要注意一个问题,有时候Select查询语句可以查到准确的数据,但是在以这条语句建立视图的时候,可能就会通不过。
如在一些表之间的连接查询的时候,如果两个表中有个字段名相同,是可以的。因为他们除了字段名字之外,还有表名一起来定义这个字段。如A。name与B。name。这是不算重名的。但是,若在建立视图的时候,这就会被认为是重复的列明,需要对其中的一个列名进行重定义。
这一点在数据库视图建立的时候,要特别的注意。 第三步:考虑查询结果的准确性。通过查询语句把我们想要的结果查询出来后,我们就需要看看这个结果是否满足我们的需要。在这个过程中,我们主要注意两点。一是形式字段是否齐全。在一些应用系统中,若数据库的视图要能够被前台的应用程序调用的话,则必须包含一些形式字段。
如笔者以前在设计一个ERP系统的时候,若前台系统要调用数据库中的视图的时候,必须包含记录更新时间、更新者、记录创建时间、创建者等相关信息。若缺乏这些信息的话,则前台调用这张视图的时候,就会出现错误。故在考虑查询结果准确性的问题的时候,就要考虑到前台应用程序的需要,看看这些形式字段是否齐全。
二是实体内容的完整性。我们到底需要显示表中的哪些字段呢,这个我们在这里要确认清楚。若显示内容太多的话,则会影响视图的执行效率,而且也会降低视图的安全性作用;但是,若字段内容显示不足的话,则以后要添加字段的话,会比较麻烦,有一定的工作量。所以在这个检验的时候,需要根据视图的实际功用,确定视图需要显示的内容。
第四步:视图的修饰。有时候,为了阅读的方便,我们需要对查询结果进行一些修饰。如现在有两张表,一张是员工基本信息表,这表中有员工姓名、员工职位编号等等;另一张表是职位基本信息表,在这表中有职位编号、职位名称。我们希望在视图中能够如下显示:“职位:员工名字”,如数据库工程师:Victor。
也就是说,把两个字段合并起来,并且在中间加入一个冒号。这些格式性的内容都是在查询的时候实现的。所以,我们确认查询的结果没有错误之后,接下来就要确认格式问题。若能够在视图中规范这些格式问题,则前台的程序设计就会相对来说比较简单。 第五步:建立视图。
等到上面四步都确认无误后,我们就要根据上面的查询语句来建立视图了。不过在这一步过程中,也有一些问题需要注意。一是视图名字的命名规格。我们除了遵循数据库的强制命名格式之外,如不能以数字开头等等,还需要遵循一些软规则。如视图最好能够以V开头,跟基础表进行隔开;另外在视图命名中,能够根据应用模块的不同,来进行分类,并体现在视图的名字中。
这对于我们后续视图的查找都具有非常现实的意义。二是虽然可以在视图中直接更新基础表,不过,为了安全与数据统一的考虑,我们这些过来人一般都不建议通过视图来直接更新基础表中的数据。虽然数据库提供了类似的功能。若要更改相关数据的话,则直接去更改基础表的内容为好。
在建立视图的时候,默认情况下是不能够通过视图直接更新基础表。