Openbiz Cubi 快速应用开发向导

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

该脚本将执行那些操做

1. 校验在升级文件夹中的模块版本是否高于当前版本
2. 备份当前模块到cubi/backup/modules/mod_name文件夹中
3. 从升级文件夹中将文件复制到当前模块中
4. 执行在upgrade.xml文件中描述的升级SQL语句。
5. 从新载入模块

范例：升级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 推荐的代码编写标准参考以下http://pear.php.net/manual/en/standards.php.

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模块的知识。

手工建立一个模块

您能够遵循下列步骤来手工建立一个模块。

1. 定义模块名并在modules/文件夹下面建立一个目录，在下列步骤中，咱们以模块名为ABC为例。
2. 编写模块描述文件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>

1. 建立子文件夹
   1. do. 这个文件夹将包含数据对象的元数据文件和PHP类文件。
   2. form. 这个文件夹将包含表单对象的元数据文件和PHP类文件。
   3. view. 这个文件夹将包含视图对象的元数据文件和PHP类文件。
   4. template. 这个文件夹将包含本模块中的视图和表单对象所关联的模板文件。
   5. lib.  这个文件夹包含通用的PHP类文件。
2. 在相应的子文件夹中编写元数据和PHP文件。
   1. 首先复制建立好的子目录到现存的模块目录下/modules/abc/
   2. 进入abc/do/目录，重命名数据对象XML文件为AbcDO.xml并修改它的 ("Name", "Title", "Table") 属性和"BizField" 元素的映射
   3. 进入 abc/form目录, 重命名表单对象的XML文件为Abc...Form.xml 并修改它的 ("Name", "Title", "BizDataObj") 属性和 "Element" 元素
   4. 进入abc/view目录，重命名视图对象的XML文件为 Abc...View.xml并修改它的("Name", "Title")属性和"Reference" 元素
3. 测试视图的访问效果，经过这样的URL http://host/cubi/index.php/abc/abc_list.
4. 增长 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发布版本中包含了一个默认的主题样式，建立一个自定义的主题样式是一件很是简单的事情，请遵循以下步骤：

1. 在/themes目录下建立一个子目录。
2. 从/themes/default目录中复制全部文件到新建立的子目录中。
   • css – 目录包含 stylesheet 样式文件
   • images – 用于存放图片文件
   • js – 用于存放与样式显示相关的JS脚本文件
   • template – 包含共享模板文件。（每个模块还能够在modules/modname/template/目录中建立本身模块特有的模板文件）
3. 修改上述4个文件夹中的文件，来建立您自定义的主题样式风格，

主题样式还能够经过命令行工具或主题管理界面来自动建立，这两部份内容分别在Cubi命令行工具和Cubi核心模块章节中分别进行介绍。

当新的模块被建立好之后，他就能够在主题样式管理界面中被设置为默认主题或者成为在个人帐户的自定义使用偏好设置中供用户进行选择的自定义主题。

客户端浏览器脚本

Cubi客户端与服务器的通信默认是按AJAX的方式进行的，它相应的实现类文件是/cubi/js/openbiz.js。

Openbiz javascript 类库概览

openbiz.js 包含了以下两类定义:

1. Openbiz – 主Openbiz命名空间，它管理表单对象和提供Openbiz Ajax调用的接口。
2. Openbiz.ActionType. 它定义了Openbiz Ajax调用的行为类型。
3. Openbiz.Form. 每个Openbiz表单对象实例都将同时初始化一个javascript的Openbiz.Form实例用于完成客户端的交互操做。
4. Openbiz.TableForm. 这是用于列表或数据表格(Gird)的专属的Openbiz From js实例。
5. Openbiz.Net. 提供了网络相关的函数，例如Ajax调用。
6. Openbiz.Window. 用来管理弹出窗口（层）和对话框逻辑
7. Openbiz.Util. 它包含一些工具性函数
8. Openbiz.Menu. 它用来实现显示和隐藏表单的右键菜单逻辑
9. Openbiz.CKEditor. 用来实现对CKEditor的集成和Ajax方法调用逻辑。
10. Openbiz.AutoSuggest. 用来初始化搜索自动建议的表单控件
11. 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应用程序添加一个新的语言包。

1. 用英语来开发您的应用模块.
2. 那么请手工建立该文件夹和land_code.xml文件，固然您能够经过Cubi多语言管理界面中进行自动建立这些文件。
3. 使用语言生成工具来生成一个新的语言包并尝试自动翻译
4. 编辑新的语言包文件
5. 测试新的语言包文件

语言包生成工具

语言包生成工具相对应的脚本文件是/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 (http://phing.info/trac/)之上的包裹性的脚本，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的文件语法，请参考以下网址：
http://phing.info/trac/
http://ant.apache.org/manual/index.html

会话管理

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");