Openbiz Cubi 开发向导
在Cubi快速入门章节中提供了一个关于创建新模块的简单的范例,本章节将带领应用开发人员更加深入广泛的了解Cubi内部是如何工作的。理解Cubi内部的工作原理将有助与您在应用程序开发中充分展现出Cubi的强大力量。本章节将讨论下列主题:
- Cubi命令行工具
- Cubi访问控制
- Cubi 命名和代码转换
- Cubi URL重写规范
- 如何编写一个模块
- 如何编写一个主题
- 客户端浏览器脚本 openbiz.js
- Cubi内建元数据编辑器 (CIME)
- Cubi 多语言支持
- 生成Cubi应用程序
- 会话管理
Cubi 命令行工具
Cubi为开发人员更有效的管理Cubi应用程序提供了一组命令行工具,这些脚本可以在如下目录中找到/cubi/bin/tools/
Module Loader
这个脚本用于将一个模块装载入Cubi系统,当您准备好新的模块时(mod.xml 或其它文件被修改时),您需要重新通过本工具将它装载到应用程序中。
模块装载脚本执行如下工作
- 检查模块在<Dependency>中定义的依赖关系,如果一个模块依赖于一个没有被装载的模块,那么它会发出警告信息;
- 在第一次装载模块的时候,执行 mod.install.sql 文件中的SQL语句;
- 读取<Module>标签中定义的模块属性;
- 读取 <ACL>标签中定义的资源和行为;
- 读取<Menu>标签中定义的菜单元素;
- 读取元数据对象 (dataobj, form, view);
- 为管理员赋予该模块的所有行为权限;
如何使用:
# php load_module.php module_name [-i]
'-i' 参数标识安装模块时是否强行装载SQL语句用来刷新已安装的数据。
Metadata Generator
Cubi Metadata Generator 帮助开发人员快速的创建出一个新的模块
如何使用这个工具
# php gen_meta.php dbname table
例如:您有一个数据表叫做”abc”,首先您在Cubi的数据库中创建表abc,然后进入cubi/bin/tools/这个文件夹执行命令
# php gen_meta.php Default abc
当脚本被执行后,下列文件将自动被生成。
/modules/abc/mod.xml
/modules/abc/do/AbcDO.xml
/modules/abc/form/AbcListForm.xml
/modules/abc/form/AbcDetailForm.xml
/modules/abc/form/AbcEditForm.xml
/modules/abc/form/AbcNewForm.xml
/modules/abc/form/AbcCopyForm.xml
/modules/abc/view/AbcListView.xml
Cubi theme generator
此工具将帮助UI开发人员基于Cubi默认主题快速生成一个新的样式主题
如何使用这个脚本
# php gen_theme.php new_theme_name
当脚本执行完成后,虾类文件将被自动生成
cubi/theme/new_theme/...
Cubi module upgrader
此工具帮助用户将模块升级为更高版本
升级准备工作
为了升级一个模块,您需要复制新版本的模块文件夹到如下目录中
cubi/upgrade/module/mod_name/.
在mod.xml文件中,确认版本号设置正确,必须高于当前正在使用的版本号。
创建或修改 cubi/upgrade/module/mod_name/upgrade.xml. 在 <UpgradeSql> 标签中为目标版本添加适当的SQL语句,例如
<?xml version="1.0" standalone="no"?>
<Upgrade>
<Version Name="0.1">
</Version>
<Version Name="0.1.1">
<UpgradeSql><![CDATA[
ALTER TABLE `help` ADD `add1` varchar(255) default NULL AFTER `content`;
ALTER TABLE `help` ADD `add2` int(10) default NULL AFTER `add1`;
]]></UpgradeSql>
</Version>
<Version Name="0.1.2">
<UpgradeSql><![CDATA[
ALTER TABLE `help` ADD `add3` varchar(255) default NULL AFTER `add2`;
ALTER TABLE `help` ADD `add4` int(10) default NULL AFTER `add3`;
]]></UpgradeSql>
</Version>
</Upgrade>
如何使用这个脚本
# php upgrade.php module_name
该脚本将执行那些操作
- 校验在升级文件夹中的模块版本是否高于当前版本
- 备份当前模块到cubi/backup/modules/mod_name文件夹中
- 从升级文件夹中将文件复制到当前模块中
- 执行在upgrade.xml文件中描述的升级SQL语句。
- 重新载入模块
范例:升级help模块从0.1 到 0.1.2
# php upgrade.php help
Start upgrading help module ...
--------------------------------------------------------
Upgrade 'help' module from version 0.1 to 0.1.2. Please backup data first.
Press enter to continue ...
Backup source files to C:\xampp\htdocs\ob24\cubi/backup/modules/help/0.1 ...
Copy source files from C:\xampp\htdocs\ob24\cubi/upgrade/modules/help to C:\xampp\htdocs\ob24\cubi\modules/help...
Execute upgrade sql files ...
Upgrade from version 0.1 to 0.1.1 ...
Execute ALTER TABLE `help` ADD `add1` varchar(255) default NULL AFTER `content`
Execute ALTER TABLE `help` ADD `add2` int(10) default NULL AFTER `add1`
Upgrade from version 0.1 to 0.1.2 ...
Execute ALTER TABLE `help` ADD `add3` varchar(255) default NULL AFTER `add2`
Execute ALTER TABLE `help` ADD `add4` int(10) default NULL AFTER `add3`
Reload module ...
[2011-01-11T00:15:53-08:00] Install Module.
[2011-01-11T00:15:53-08:00] Install Module ACL.
[2011-01-11T00:15:53-08:00] Install Module Menu.
[2011-01-11T00:15:53-08:00] help is loaded.
Give admin to access all actions of module 'help'
--------------------------------------------------------
End loading help module
Cubi 访问控制
Cubi 在应用程序中提供了一系列约束用户对资源的访问控制。
用户身份验证
Cubi使用身份验证服务(modules/service/authService.php)来根据用户提供的用户名和密码校验用户身份。
当前身份额验证服务按Cubi的用户表来完整用户身份验证,同样的逻辑还可以被修改以使用用户的特殊环境,例如用户可以在这个服务中通过LDAP服务器用来验证身份。
通用页面 (视图) 访问控制
访问服务可以被用来对简单页面进行访问控制,访问控制服务有一个配置文件(accessService.xml)该文件定义了从用户资料服务中获取的核心角色的视图访问权限,请看如下范例:
<?xml version="1.0" standalone="no"?>
<PluginService Name="accessService" Class="accessService">
<access-constraint>
<view-collection>
<view name="shared.CalendarView">
<role name="admin"/>
<role name="member"/>
</view>
<view name="demo*"> <!-- regular expression in the view name -->
<role name="admin"/>
<role name="member"/>
</view>
</view-collection>
</access-constraint>
</PluginService>
XML配置文件非常简单,因此也许客户还需要在accessService.xml.文件中增加自己的逻辑
基于角色的访问控制 (RBAC)
Cubi基于角色访问控制的原始目的在于定义一个用户角色对应用程序资源具有什么样的操作权限,当定义一个RBAC模型时候,下列管理将会非常有用。
- User –通常是一个人或者自动代理程序,一个用户可以同时拥有多种角色
- Role – 通常是职能或头衔,它的皈依了一个验证级别,一个角色可以分配给多个用户,一个角色可以拥有多个权限设置。
- Resource –通常是一个应用程序中拥有某种逻辑的一个对象
- Action – 通常是一种可以改变资源状态的操作
- Permissions – 通常是是否具有访问一个资源的许可权限,他定义了一个角色可以如何对资源进行操作行为,一个权限可以被分配给多个角色
定义资源和它自己的操作行为
每一个模块在模块的根目录中都有一个mod.xml文件,在mod.xml文件中,有一个ACL章节用来定义多组资源,每组资源可以有一个或多个操作行为,例如:
<ACL>
<Resource Name="User">
<Action Name="Administer_Users" Description="Administration of users"/>
连接资源的访问行为到对象
在每一个Openbiz项目中,开发人员可以设置访问属性给几个资源行为,例如:
<EasyView Name="UserListView"... Access="User.Administer_User">
允许拥有Administer_User资源行为权限的用户才能访问system.view.UserListView视图。
分配角色权限给资源行为
在角色管理视图中,用户可以选择“Allow”或“Deny”给所有可用的资源行为。例如:我们给角色“member”设置“Deny”权限到“User.Administer_User”。那么当一个具有“member”角色的用户尝试访问RoleListView视图时,用户将只能看到一个访问拒绝的页面。
访问属性可以设置给视图,表单,表单元素,数据对象和菜单条目
基于组的数据可视性控制
角色是用来控制一个资源上的操作行为是否可以被用户所调用,当有许多应用程序希望不同的用户看到不通的数据范围的时候,例如:销售数据应该不仅对销售人员可见,同时对于财务或市场人员也应该具有可见性,这样的功能系统称为“数据可视性”。
显性分组
Cubi使用“用户组”来控制数据可视性,为了在某些数据上增加数据可视性控制,您需要在相对应的数据对象上增加“group_id”字段,然后自定义的访问逻辑可以在数据对象的AccessRule中进行设置。
例如:
- 如果要设置数据可视性为只允许本组成员可见,您可以进行如下设置:
<BizDataObj Name="SalesDO" AccessRule="{tx}@vis:group(group_id){/tx}" …>
- 如果设置数据可视性为只有创建者可见,您可以进行如下设置
<BizDataObj Name="MailDO" AccessRule="{tx}@vis:group(owner_id){/tx}" …>
@vis是数据可视性服务的别名。
所有系统服务别名都可以在app_init.php的$g_ServiceAlias数组变量中定义,当服务别名被定义后,Openbiz的简单表达式引擎就可以调用在表达式中定义的相应的服务和方法。
基于用户的数据可视性控制
有时候,我们希望增加一个更加细致的数据可视性控制,例如精确到每一个用户可以访问哪些数据记录,在这种情况下,我们推荐使用一个交叉表(中间表)通过多对多映射(M-M)的方式来连接用户与数据记录的关系。比如,如果你想让多个用户访问某些重要的报表,你可以创建一个交叉表叫“report_user”。该表存储了report_id和user_id。这个表将被用来限制哪个用户可以访问哪些报表。
这些多对多关系中和相应的用户界面在许多Cubi模块中都有所实现(例如:用户与角色,用户与分组的关系),参考现有的Cubi实现方法将会对您的开发很有帮助。
Cubi 命名规则与代码转换
元数据命名转换
在发布Cubi之前,Openbiz开发人员通常是按自己习惯的方式来对元数据进行命名,例如一个用户列表表单可能会被命名为如下名字:
- FM_UserList.xml
- f_userlist.xml
在Cubi中,元数据文件的命名遵循"NameType"语法,例如用户列表表单,Cubi将使用如下名字:
- UserListForm.xml
Cubi建议每一个模块包含如下子文件夹:
- do. 用来存储数据对象的元数据文件与可实现类文件。
- form. 用来存储表单对象的元数据文件与可实现类文件
- view. 用来存储视图对象的元数据文件与可实现类文件
- template. 用来存储视图与表单的模板文件。
- widget. 用来存储表单元素和菜单的源数据文件与实现类。
- lib. 用来存储具有公用性的脚本文件。
元数据文件命名范例,以Cubsi/modules/system目录为例:
对于数据对象元数据
/do/UserDO.xml
/do/RoleDO.xml
对于表单对象元数据
/form/UserListForm.xml
/form/UserEditForm.xml
/form/UserNewForm.xml
对于视图对象元数据
/view/UserListView.xml
/view/UserEditView.xml
/view/UserNewView.xml
一个模块还可以包含子模块文件夹,每一个子模块也应当遵循同样的模块目录结构。
(通常子模块的视图对象和模板文件,是存放在父模块的文件夹中的)
代码转换
Openbiz与Cubi 推荐的代码编写标准参考如下.
Cubi URL重写规则
Cubi应用程序默认都使用简洁URL模式来访问视图,配合一些在Web服务器上的配置设置,最终URL甚至可以变得更加简短。
基本的 Cubi URL 格式
在早期Openbiz的Baseapp,一个典型的访问视图的URL类似如下:
http://host/baseapp/bin/controller.php?view=a.b.viewname.
我们称之为原始Openbiz URL
Cubi将通过index.php与cubi安装目录下的.htaccess文件配合的方式为系统映射更加简洁的URL格式。
视图映射语法:
简洁URL | 原始URL |
/cubi/index.php/module/xaa 对应: /cubi/index.php/system/userList | /cubi/bin/controller.php?view=module.view.XView 对应: /cubi/bin/controller.php?view=system.view.UserListView |
/cubi/index.php/module/xaa_ybb 对应: /cubi/index.php/system/user_list | /cubi/bin/controller.php?view=module.view.XaaYbbView 对应: /cubi/bin/controller.php?view=system.view.UserListView |
/cubi/index.php/module/xaa/number 对应: /cubi/index.php/system/user_detail/5 | /cubi/bin/controller.php?view=module.view.XaaView&fld:Id=number 对应: /cubi/bin/controller.php?view=system.view.UserDetailView&fld:Id=5 |
/cubi/index.php/module/xaa/word_number 对应: /cubi/index.php/system/user_detail/Id_5 | /cubi/bin/controller.php?view=module.view.XaaView&fld:word=number 对应: /cubi/bin/controller.php?view=system.view.UserDetailView&fld:Id=5 |
/cubi/index.php/module/xaa/a=x&b=y 对应: /cubi/index.php/user/reset_password/token=4c0417d23dad6&abc=xyz | /cubi/bin/controller.php?view=module.view.XaaView&a=x 对应: /cubi/bin/controller.php?view=user.view.ResetPasswordView&token=4c0417d23dad&abc=xyz |
如果index.php被设置为服务器的默认页面文件,在URL中您可以使用“?”来代替“index.php”,例如/cubi/?/system/userList
基于 url_rewrite实现的高级URL格式
如果你的Cubi运行于Apache网页服务器下,并且服务器支持通过.htaccess文件的方式配置url_rewrite模块的转发规则。Cubi将可以实现高级的简洁URL格式
在你的apache conf 文件中,增加类似如下配置:
Alias /cubi "D:\Apache2\htdocs\cubidev\cubi"
<Directory "D:\Apache2\htdocs\cubidev\cubi">
AllowOverride All
</Directory>
打开 /cubi02/cubi/bin/app_init.php文件,进行如下修改
/* APP_URL is /a/b in case of http://host/a/b/index.php?... */
define('APP_URL',"/cubi");
/* APP_INDEX is /a/b/index.php in case of http://host/a/b/index.php?... */
$indexScript = ""; // or "", or "/?"
define('APP_INDEX',APP_URL.$indexScript);
进行完上述设置后,您可以在URL去掉”index.php”字符,例如
http://host/cubi/system/user_list 就完全可以代替http://host/cubi/index.php/system/user_list.实现更加精简的URL。
如何编写一个模块
在“Cubi快速入门”章节中我们介绍了如果通过”gen_mod”工具创建一个模块,本章节将涵盖更多关于编写Cubi模块的知识。
手工创建一个模块
您可以遵循下列步骤来手工创建一个模块。
- 定义模块名并在modules/文件夹下面创建一个目录,在下列步骤中,我们以模块名为ABC为例。
- 编写模块描述文件modules/abc/mod.xml.一个最精简的 mod.xml 文件内容如下
<Module Name="abc" Description="abc is a new module" Version="0.1" Author="your name" OpenbizVersion="2.4">
</Module>
- 创建子文件夹
- do. 这个文件夹将包含数据对象的元数据文件和PHP类文件。
- form. 这个文件夹将包含表单对象的元数据文件和PHP类文件。
- view. 这个文件夹将包含视图对象的元数据文件和PHP类文件。
- template. 这个文件夹将包含本模块中的视图和表单对象所关联的模板文件。
- lib. 这个文件夹包含通用的PHP类文件。
- 在相应的子文件夹中编写元数据和PHP文件。
- 首先复制创建好的子目录到现存的模块目录下/modules/abc/
- 进入abc/do/目录,重命名数据对象XML文件为AbcDO.xml并修改它的 ("Name", "Title", "Table") 属性和"BizField" 元素的映射
- 进入 abc/form目录, 重命名表单对象的XML文件为Abc...Form.xml 并修改它的 ("Name", "Title", "BizDataObj") 属性和 "Element" 元素
- 进入abc/view目录,重命名视图对象的XML文件为 Abc...View.xml并修改它的("Name", "Title")属性和"Reference" 元素
- 测试视图的访问效果,通过这样的URL http://host/cubi/index.php/abc/abc_list.
- 增加 ACL, Menu, Dependency 元素到 mod.xml文件中。
<Module Name="abc" Description="abc is a new module" Version="0.1" Author="your name" OpenbizVersion="2.4">
<ACL>
<Resource Name="Abc">
<Action Name="Administer_Abc" Description="Can Abc data"/>
</Resource>
</ACL>
<Menu>
<MenuItem Name="Abc" Title="Manage Abc" URL="{@home:url}/abc/abc_list" Parent="System" Order="60"/>
</Menu>
<Dependency>
<Module Name="system"/>
</Dependency>
</Module>
通过metadata generator来创建模块
这一部分内容我们在Cubi快速入门章节中已经详细讲述了。
SQL 脚本的安装
一个典型的模块通常有对数据库的改变,(例如:增加一些相应的数据表),与数据库相关的操作语句需要被复制到/cubi/modules/mod_name/mod.install.sql文件中,此文件可以包含”create table”语句用来创建模块所需的数据表和”insert into”语句来实现数据的初始化。
如何编写一个主题样式
Cubi发布版本中包含了一个默认的主题样式,创建一个自定义的主题样式是一件非常简单的事情,请遵循如下步骤:
- 在/themes目录下创建一个子目录。
- 从/themes/default目录中复制所有文件到新创建的子目录中。
- css – 目录包含 stylesheet 样式文件
- images – 用于存放图片文件
- js – 用于存放与样式显示相关的JS脚本文件
- template – 包含共享模板文件。(每一个模块还可以在modules/modname/template/目录中创建自己模块特有的模板文件)
- 修改上述4个文件夹中的文件,来创建您自定义的主题样式风格,
主题样式还可以通过命令行工具或主题管理界面来自动创建,这两部分内容分别在Cubi命令行工具和Cubi核心模块章节中分别进行介绍。
当新的模块被创建好以后,他就可以在主题样式管理界面中被设置为默认主题或者成为在我的账户的自定义使用偏好设置中供用户进行选择的自定义主题。
客户端浏览器脚本
Cubi客户端与服务器的通讯默认是按AJAX的方式进行的,它相应的实现类文件是/cubi/js/openbiz.js。
Openbiz javascript 类库概览
openbiz.js 包含了如下两类定义:
- Openbiz – 主Openbiz命名空间,它管理表单对象和提供Openbiz Ajax调用的接口。
- Openbiz.ActionType. 它定义了Openbiz Ajax调用的行为类型。
- Openbiz.Form. 每一个Openbiz表单对象实例都将同时初始化一个javascript的Openbiz.Form实例用于完成客户端的交互操作。
- Openbiz.TableForm. 这是用于列表或数据表格(Gird)的专属的Openbiz From js实例。
- Openbiz.Net. 提供了网络相关的函数,例如Ajax调用。
- Openbiz.Window. 用来管理弹出窗口(层)和对话框逻辑
- Openbiz.Util. 它包含一些工具性函数
- Openbiz.Menu. 它用来实现显示和隐藏表单的右键菜单逻辑
- Openbiz.CKEditor. 用来实现对CKEditor的集成和Ajax方法调用逻辑。
- Openbiz.AutoSuggest. 用来初始化搜索自动建议的表单控件
- Openbiz.Validator. 提供了一系列用于在客户端对用户输入数据进行有效性校验的函数。
扩展客户端(浏览器)类库
如果你希望在客户端浏览器上实现一些特殊逻辑,你可以编写你自定义的类来继承于Openbiz.Form或Openbiz.TableForm类,然后在表单对象的元数据中指定jsClass="YourFormName"属性
范例: 创建一个MyInputForm 类用来实现你自定义的输入表单,在/cubi/js目录中创建一个”MyInputForm.js”文件。
/**
* MyInputForm class
*/
MyInputForm = Class.create(Openbiz.Form,
{
initialize: function($super, name, subForms)
{
$super(name, subForms);
// your own init code here
},
myfun: function(...)
{
// your code here
}
});
Cubi 内建元数据编辑器 (CIME)
为了帮助开发人员更加直观的编辑元数据,Cubi通过tool模块提供了内建的元数据编辑器。
在Cubi中开/关CIME
如果cubi/bin/app_init.php中,常量'APPBUILDER'被设置为1,那么CIME将会在应用程序的页面中启用,在CIME模式下,每一个视图或表单的右上角将会出现一个小图标,点击该图标就可以启动一个新的窗口来激活CIME元数据编辑器。
使用元数据编辑器的基础须知
编辑节点属性
如果需要编辑一个节点的属性,点击左侧树节点可在右侧区域内展示该节点的可编辑属性。
添加或删除节点
如需要添加一个节点,在父节点上单击鼠标右键,选择“Create”菜单,然后输入一个新的子节点的名字即可完成创建。
如需要删除一个节点,在想要删除的节点上单击鼠标右键,并选择“Delete”菜单,然后在弹出的确认菜单中点击“OK”按钮,即可完成节点的删除。
移动一个节点
如需要移动一个节点,通过鼠标拖拽的方式将一个节点移动到其他的父节点下即可。
编辑表单元数据
在元数据编辑器的第一页,如果表单对象定义了DataObject 属性,您将会在左侧最下面看到一个编辑数据对象元数据的连接。
编辑表单属性
编辑表单元素属性
编辑数据对象元数据
如果是通过表单对象上的连接跳转到数据对象编辑视图,点击数据对象编辑器上的“Back to”连接还可以返回刚才的表单对象编辑器界面。
编辑数据对象属性
编辑数据对象字段属性
编辑视图对象元数据
视图对象编辑器的首屏。
编辑视图对象属性
编辑表单引用属性
Cubi 的多语言支持
Cubi为开发人员制作语言包提供了一组专用工具。下列步骤将描述如何为Cubi应用程序添加一个新的语言包。
- 用英语来开发您的应用模块.
- 那么请手工创建该文件夹和land_code.xml文件,当然您可以通过Cubi多语言管理界面中进行自动创建这些文件。
- 使用语言生成工具来生成一个新的语言包并尝试自动翻译
- 编辑新的语言包文件
- 测试新的语言包文件
语言包生成工具
语言包生成工具相对应的脚本文件是/cubi/bin/tools/gen_lang.php.
usage: php gen_lang.php [module] [locale] [translate]
范例:生成简体中文语言包
# php gen_lang.php user zh_CN -t
其中“user”是模块的名字,”zh_CN”是中文的语言代码,“-t”参数是用于启用基于”Google Translator”的自动翻译功能
语言包生成工具将完成如下工作:
- 在如下类型文件中,搜索并提取出所有可翻译的字符串:
- 元数据文件. 例如表单对象的 "Title"属性, 或表单元素对象的"Label"属性等 ...
- 模板文件. 在模板中通过{t}...{/t} 标签定义的可翻译字符串
- 消息文件.
- 将所有可翻译字符串存入/cubi/languages/lang_code/mod.module_name.ini文件中,改文件包含如下3个章节
- [METADATA]
- [MESSAGE]
- [TEMPLATES]
- 如果 "-t" 参数在命令行中被指定,那么将通过Google Translate API来尝试对字符串进行逐一自动翻译。
语言包管理模块
语言包管理模块可以帮助用户完成如下工作:
- 创建一个新的语言包包括文件夹和语言包描述文件
- 编辑翻译文字
管理语言包
创建一个新的语言包
管理语言包的翻译
编辑语言包的翻译
打包 Cubi 应用程序
Cubi的build 工具是用来实现轻松构建基于Cubi的应用程序而设计的,Cubi Builder实际上是一个基于Phing ()之上的包裹性的脚本,Phing是一个类似Ant的项目打包工系统。
在进行打包之前,需要在cubi/build目录中准备好下列文件:
- app_name.xml. 应用程序包的主XML描述文件.
- app_name.properties. 应用程序打包的属性文件
- app_name.license.txt. 应用程序的许可证文件
打包程序的命令:
# cd cubi/build
# build app_name [target]
范例: 打包干净的Cubi应用程序
# build cubi tar
在运行玩打包命令之后,一个”gz”后缀的文件将会被生成到/cubi/build/dist/app_name/目录中,具体文件名是根据在打包属性文件中的设置来命名的,属性文件还定义了如下内容
- build.summary.
- build.version.
- build.release.
生成出的文件名应该是app_name-version-release.gz。例如:build.version是0.3并且build.release是1,那么生成出的文件名就是app_name-0.3-1.gz.
关于build.xml的文件语法,请参考如下网址:
会话管理
Cubi 允许开发人员选择下来集中逻辑来存储用户会话数据
- 存储在文件系统中
- 存储在数据库中
- 存储在 memcache缓存中(用于多服务器共享会话)
如果需要指定会话处理器,你可以修改app_init.php的会话管理部分app.inc
/* define session save handler */
// save session in DATABASE
//define("SESSION_HANDLER", MODULE_PATH."/system/lib/SessionDBHandler");
// save session in MEMCACHE
//define("SESSION_HANDLER", MODULE_PATH."/system/lib/SessionMCHandler");
// for default FILE type session handler
define("SESSION_PATH", APP_HOME.DIRECTORY_SEPARATOR."session");
在文件系统中存储用户会话
如果在app_init.php文件中没有指定常量SESSION_HANDLER,默认情况下,Cubi会将用户会话数据保存在安装目录的sessions子目录中,该目录是默认在app_init.php文件中通过SESSION_PATH常量指定的,这里建议通过一个计划任务来定期清理该会话文件夹,以至于它不会变得过度臃肿。
使用文件系统类保存会话是一件非常容易的事情,不过弊端是不能够实现跨服务器的共向用户会话,如果有这样的需要您也许可以考虑这样来部署。
- 通过均衡负载器来将用户的请求分配到相对固定的web服务器上并附上相应的SessionID
- 将会话存储文件夹设定为 NFS.文件系统中。
在数据库中存储用户会话
如果在app_init.php中的 SESSION_HANDLER 常量设置为SessionDBHandler, Cubi 将会保存会话数据在”Session”数据库中的session表中。
”Session”数据库的连接方式可以在系统根目录的Config.xml文件中进行的定义,默认情况下,session表就位于Cubi的安装数据库中,Cubi的会话表被配置为”MEMORY”类型的数据表结构,这样做是为了最大化提升它的读写性能。
在MemCache服务器中存数用户会话
如果在app_init.php中的 SESSION_HANDLER 常量设置为 SessionMCHandler, Cubi 将会存储用户会话数据在MemCache服务器中。
memcache 是一个快速的集中的会话共享解决方案,在Unix/Linux环境中,MemCache非常容易安装部署,对于Windows服务器来说请参考如下文档了解如何进行安装部署。
http://www.leonardaustin.com/technical/how-to-install-memcached-on-xampp-on-windows-7 for
设置您自定义的会话处理方式
如您所见,通过在app_init.php中设置SESSION_HANDLER常量,您可以制定装载您自己的会话逻辑。
比如
// use custom logic to save session data//define("SESSION_HANDLER", MODULE_PATH."/abc/MySessionHandler");