Gallery:嵌入:整合面面观
来自站长百科
两个或以上Web应用程序整合[ ]
当将一个web应用程序整合到另一个中时牵涉到各方面。此份资料档将描述这些方方面面，可能存在的问题及它们的解决办法。这些发现是基于Gallery2的制作过程，PHP为基础的相册管理软件，并与其他web应用程序具有互用性。
请参看有关Gallery2嵌入的概览。
原则[ ]
- 无派生：所有应用程序都可使用自己的升级路径。无（开发者）资源被浪费。Glue代码和API则被用于应用程序的粘合
- 无缝整合：使得结果解决办法看起来并且行为上像一个单独的应用程序
- 数据完整性：在任何时候保持应用程序的同步。周期任务（cron，scheduler等）就没有必要了
- 使得整合编写者的工作越简单越好：某特定整合所需的代码编写量越大，所花的编写时间就越多，需要维护的代码量就越大
主-仆关系和交流[ ]
- 基础应用程序为主
- “被嵌入的”应用程序为仆
- 选择：双工
- 多于两个的应用程序：多个主-仆关系
- 所有方面的主-仆关系
- 两应用程序间的交流：PHP和同web服务器上的。或由XMLRPC作为一个更强大的选择
用户和组的管理[ ]
- 紧密整合vs.疏松整合：紧密（tight）= 俩应用程序共享相同的数据库用户表格，疏松（loose） = 俩应用程序使用各自的用户管理，但它们是松耦合的并永不会超出同步。为紧密整合标准化用户管理看似不可能。我们做过双方向的探索并最终决定了使用疏松整合。
- 基于事件的同步
- 直接用户作为低技术回退的解决办法
- 周期同步作为低技术回退的解决办法（更新，删除用户）
- 初始用户和组同步（导入/导出）
- 非重要组，可能的阻碍
- 单个新用户注册解决办法（基于事件的同步或低技术回退）
- 未处理的：为另一应用程序添加注册用户数据字段。可由更多挂钩来完成
对话管理[ ]
- 一个标准化的对话界面/API是很好的。
- 由于缺少这样的标准化，而且并非所有的应用程序都允许对话数据的添加，平行对话管理则被作为选择（主-仆），这实际意味着俩应用程序使用各自的对话管理
- 关于cookies的妙趣（参见有关G2中cookie管理的资料，一般是正确cookie路径或域的信息）
- 对话超时：应用程序的对话超时必须根据对方进行调整
验证[ ]
- 主进行验证，仆则信任主
- 在仆中载入对应用户无解决办法（额外数据库查询…无必要）
- Clear-text或Hash密码仅当直接访问两应用程序时才需要考虑
- 单点登录（SSO)解决方案
- 仆将其登录链接重新导向主的登录系统或一并移除。
- 对注册来说也一样
URL 生成[ ]
- 被嵌入的应用程序的URL
- 必要的参量
- 短URL/mod_rewrite/…
可视化整合[ ]
- 中心模板系统不现实
- 仆逐个返回生成好了的HTML，CSS，JS，title，<head>内容
- 主必须有向页面输出添加外部CSS/JS <head>内容的可能性，也是设定页面标题的一种方法
- 主必须有选项以供仆直接向浏览器输出或为特殊事例做HTTP重新导向，比如，通过PHP，rss源输出进行文件下载等
- 移除特定的菜单项目，比如注册或登录链接等
- 选择：：标准化的模板或以窗件为基础的输出
权限管理[ ]
- 未整合。权限系统大相径庭，而用一个中心GUI来管理所有的权限似乎有点小题大作。有待研究。
- 两应用程序各司其权限，但它们仍然是相联接的，因为两个应用程序都对同样的用户或组赋予权限。
- 主应用程序可以限制对被嵌入的应用程序的访问，而被嵌入的应用程序则管理详细的特权
控制访问
- 俩应用程序仍可被直接访问，或仅其一可被访问
- 有例外（G2：GR，DownloadItem等）
搜索功能和其他API的暴露[ ]
- 组织搜索函数，API为必须
配置设定[ ]
- 站点范围的默认语言和其他设定应当进行同步
命名空间和代码碰撞[ ]
- 为你的分类名称使用前缀（PHP不会支持命名空间）
- 为你的数据库表格/栏目使用前缀
- 使用全局变量的最小值并确保它们的名称具有前缀或是唯一
- 在常数中使用前缀
- 当使用类似adodb和smarty的第三方库时，请确保使用的是最新的版本，并包含多次后仍能正常工作。
- 请同时确保在所有include中都使用了绝对文件系统路径。这通常是一个好办法且比互用性重要得多
环境[ ]
- 字符编码。所有UTF-8或应用程序对输出（自浏览器，其他应用程序）/输入（HTML）字符编码要灵活
- PHP环境：register_globals，错误报告，PHP版本等
安装程序[ ]
- 为管理者提供一个简洁简便的安装程序来配置整合参量