XOOPS 4.0 “Xoosphere” 开发路线图 v1

介绍

在过去几年中，很多人对网络有了不同的看法，并表现出使用更先进工具的意愿。因此，xoops.org的用户数量已经增加了X倍。随着XOOPS社区的壮大，它的多样性也有所增长。

去年，当我们意识到XOOPS项目无法组织这么多人的时候，我们也必须承认XOOPS核心架构无法像人们希望的那样演变。不久前，这个程序只是一个PHP门户网站系统，甚至不像今天这样部分面向对象，几乎是单神论的。对于用户来说，XOOPS到2中增加的增强功能相当积极，但对于开发者来说，这种遗产一直在拖累我们。对核心的贡献变得越来越困难，修复一些问题也变得越来越难，现在是时候重新开始。其他一些原因也使我们相信，如果必须发生这种情况，那就应该是现在：PHP5已经到来，具有许多独特功能，有一天我们将不得不决定利用它们并忘记PHP4。考虑到我们计划重新架构需要数月时间，最好我们现在就进行这种转换。我们不能要求开发者每年都改变他们的方法。

塑造 Xoosphere

多年来，XOOPS核心已经发展成为一个不仅仅是门户网站脚本的东西。然而，截至今天，它还不能被视为真正的内容管理系统，也不能被视为应用框架，同时它在某种程度上是这所有东西的结合。正是由于这个原因，人们已经无法定义什么是XOOPS，这是我们在尝试前进之前需要解决的第一个问题。

因此，我们首先尝试设计一个能够集成所有可想象组件的全球架构。这里的目的是不仅列出所有这些组件或详细说明它们的个别实现，而是为我们未来的系统提供一个总体无限制的结构，主要描述其组成部分将如何相互关联，赋予每个部分一个明确的位置。

一旦底层实现，从最底层开始，这个全球架构将得到增强和细化，逐步包含新的类和框架，直到我们达到最终目标：拥有一个平台，将允许我们以我们希望它们成为的方式运行和维护所有xoops.org网站（而实际上它们已经在很大程度上围绕XOOPS及其局限性建立）。

首先，Xoosphere项目关注的是一种方式，远多于关注特定的程序或功能。

• 我们将重视代码构建的方式，坚持设计原则，如简洁（不是易用性，这是另一回事）和模块化。我们将确保每个组件在全球前提下，在模块化架构中都有其精确的定位。我们将注意在需要之前不编码，并确保开发者拥有一致、易理解且文档化的平台。
• 我们将注意在适当的地方尊重和使用网络标准：XOOPS，就像PHP一样，必须作为许多更多软件之间的粘合剂，而标准的制定也是为了促进互操作性，而不仅仅是让程序员困惑。
• 我们将注意我们合作的方式，在实现之前就沟通事情，确保尽可能自然地加入核心开发的人员。
• 然后，如果一切顺利，我们将能够照顾到从xoops.org论坛和其他XOOPS项目团队中可见的想法和努力流中受益的方式。

适当的方法论应允许我们获得一个系统能够尽可能满足实际XOOPs用户在过去两年中表现出的各种期望。

• 开发者将有一个一致且可预期的平台进行构建，其中包括帮助他们构建各种类型基于Web的程序的库，而不仅仅是“XOOPS模块”。
• 专业用户将有一个灵活的系统，能够很好地集成到他们现有的信息架构中。
• 最终用户将得到一个非常强大且可定制的网络构建工具，由专业且易于理解的独立程序组成，具有他们已经熟悉和理解的隐喻界面来进行文档管理和页面/站点构建应用。

操作/基础层

Exxos

Exxos将是一个对象实例化和运行时配置框架，旨在帮助构建高效、可配置且灵活的PHP应用程序。它将允许每个对象在几个“执行模式”之间切换，从而使程序员能够灵活、可配置和自适应地上传他们的组件版本，同时提供最优化和更具可扩展性的版本。

Exxos本身将利用这种能力，提供一个强大的运行时配置层，允许人们配置系统的各个方面。在开发模式下，其工厂将根据用户的偏好创建和配置对象，生成可以直接在生成模式下实例化的预配置扩展类。

此框架还将提供标准文本编码服务，这些服务本地可用（文本编码是高级国际化的关键）以最小化现有后端（如iconv或mbstring扩展）之间的差异，以及实现观察者的标准化方式（或事件处理器）。

XOOPS内核

内核将是我们的Exxos实现，提供一个全局的工厂，负责 instantiation 本系统中所有对象，并负责全局引导和关闭序列。它将带来以下范例和特性

• 用户身份的概念，使我们能够制作感知用户的应用。
• 然后提供本地化应用的可能性，新增的语言服务可处理字符串集合的管理和翻译（通常支持gettext以及提供一个作为其翻译引擎的php类）。
• 路径处理器，使开发者和用户能够独立于其实际位置访问对象或模块文件和资源（从而诞生了xoops://虚拟文件系统）。
• 网站或主机身份的概念。就像某些Web服务器可以配置为支持多个网站或vhosts一样，相同的XOOPS内核也将能够操作多个网站（使用请求URI区分）。此功能将考虑在内核工厂中，以便使首选项管理系统能够指定全局设置以及特定于站点的设置。
• 本平台使用UTF-8作为原生编码（尽管仍然可以配置使用任何其他内部编码，对于那些不需要Unicode好处的人来说）。
• 应用程序（或模块）的概念。内核将在其引导序列结束时实例化当前模块对象，并验证当前用户是否有权访问请求的脚本。
• 安装附加的“启动项”的可能性，这将在每个系统启动时实例化，在默认服务的初始化之后。
• 一个全局的输入过滤设施，开发人员可以利用它在使用用户提供的请求变量之前清理它们。这将保护他们免受SQL注入或跨站脚本攻击，并帮助他们构建早在其开发初期就安全的应用程序。

架构服务

操作层的最后部分将由架构服务组成。此层将包含提供标准化API给外部服务或系统的各种低级框架。由于大部分类将被定期使用并在每个页面请求中使用（其中许多是由高级组件使用的工具），它们将被设计得简单和优化，以及更多地带来标准化和模块化，而不是功能。

XoopsDb

XoopsDb框架将从PDO在PHP 5.1中最终带来的标准化中受益。我们框架的新版本将模仿PDO接口，确保如果可用，可以直接使用此扩展（预先提供对所有支持PDO平台的支持：Ms-SQL、MySQL、Firebird、Oracle、PostgreSQL和SQLite），但我们还将提供一个备用的MySQL驱动器（并希望如果有人愿意，也能提供MySQLi驱动器）。

此版本的XoopsDb也将是编码感知的，并能自动处理文本编码转换（如果可用，使用原生驱动器支持，否则使用Exxos提供的引擎）。

XoopsHttp

XoopsHttp框架将包含一些Http特定的组件，如会话处理器。在这里的一个重要观点是我们将确保XOOPS 4根据Http协议构建，而不是与之对抗。在全部开发过程中，我们将确保XOOPS始终是一个使用最明显标准的Web构建平台，如这个协议尽可能妥善地使用。这不仅允许我们将XOOPS想象成更大平台或系统的一部分，也将是我们一些架构选择背后的原因，例如，XOOPS 4将内部操作标准、易读的URI，如果可能，将保持这种状态，或者在最坏的情况下转换为臭名昭著的xxx.php（与后来使用“短URL函数”转换脚本位置的程序相反）。

XoopsTemplate

Smarty将是首先在XoopsTemplate框架中实现的动力引擎（尽管与XOOPS2不同，并且添加了默认引擎的自定义扩展），但根据情况，我们可能会在这里添加我们的自定义模板引擎，使用类似于Smarty的编译器（但是没有它很少使用的功能，以保持简单和可扩展性）。

核心服务

核心服务层将提供在较低级别架构组件之上构建的初级服务，并作为应用层MVC导向组件之间的中间人。

XoopsAuth

认证框架将提供两项服务：认证服务（处理整个认证过程）将与认证驱动器分离（负责检查凭证有效性），这个最后一个是可配置的。将提供几个默认驱动器（LDAP、XoopsDb...），但人们将能够设计定制的驱动器以扩展这个框架的可能性。

XoopsUi

XoopsUi将在稍后提供基础工具，用于构建高级XOOPS4应用程序的用户界面。其中关键元素之一将是用户界面文件，开发者可以使用它来创建/描述用户界面（一种超级模板，可以实例化对象并提供不同显示技术的多个版本，例如HTML，但也包括XUL等）。根据XML，用户界面文件将以与Smarty模板相同的方式进行编译，以确保在生产网站上快速访问。

XoopsTheme

XoopsTheme将封装页面构建服务的功能，它将模块输出包装成具有主题的页面。通过增加一个中间应用级别模板和允许对象操作页面级别元数据（因此，插入到页面中的小部件可以确保所需的样式表和脚本文件从页面标题中获取），页面构建将得到增强。同时，主题作为资源容器，也将获得更多功能：现在人们可以使用主题定制构建输出使用到的任何资源（无论是模板、样式表、脚本文件还是图像）。当请求访问主题资源时，XoopsTheme会自动检查主题中是否存在自定义版本，并修改资源URI。这些最后功能的访问将通过自定义Smarty编译器函数来实现，以确保它不会成为可伸缩性的致命杀手。

我们也正在考虑将此新框架的一些功能提供给2.1/2.2分支。

XoopsData

XoopsData将设计来处理文档基于Web应用程序中一些最重要的功能领域：对象图管理和持久性。它将提供的类将帮助模块开发者不必关注从持久存储中检索或保存对象属性，或在保存之前验证这些属性值。其关键功能包括

• 完全采用模型（如MVC）导向的设计：XoopsData应用程序不会操作存储在数据库中的数据，也不是通过数据访问对象进行访问，而是采用相反的方法，操作将保存到持久对象存储中的文档和内容实体。
• 它将透明地支持分布式数据存储（因此，应用程序获取的项可以来自不同的存储，而不会注意到这一点）。
• 它将提供XoopsDb存储驱动程序，但也将基于文件系统的XML存储驱动程序（将文档作为XML文件持久保存到服务器文件系统），并允许开发自定义第三方驱动程序。
• 其数据存储将是语言感知的（因此，人们可以将同一文档的多个翻译存储起来）。
• 每个存储都将从自己分层组织系统受益，允许通过最易于理解的路径隐喻访问内容。
• 通过自定义元数据集，数据存储将可扩展，以支持将评级或下载计数添加到内容实体中。

应用程序服务

应用服务层将包含基于MVC模式的多个框架，以尽可能快速、简便地构建面向文档（模型）的应用。ApplicationKit将提供基于XoopsData的对象控制器，用于创建、查看或编辑受管理的文档。WidgetsKit将提供若干默认控件，用户可以使用它们构建强大的用户界面（工具栏、增强表单控件）。尽管我们认为Xoops不应该提供完整的控件库，但至少我们将提供几个默认组件以及一些标准化，以便第三方开发者可以创建自己的XoopsUi控件。

核心模块

新平台提供的模块将分为几类

• 系统模块将提供运行和管理Xoops站点所需的几个应用程序，如用户登录模块提供系统登录窗口或新的模块化管理控制台。
• 内容管理模块使用户能够浏览其文档集合：内容探索器允许在已知数据存储中进行导航，默认文档查看器/编辑器则允许编辑不由特定应用程序管理的资源和文档。
• 新的Xoops开发工具旨在为开发者提供完全集成的开发环境：他们将有应用程序可以直观地编辑类或新文档类型，并允许他们将注意力集中在真正的功能上，而不是将一半的时间花在重复性工作上。在这个真正早期的开发阶段，我们想象这些应用程序具有XUL用户界面（这取决于XoopsUi类提供的可能性以及可以参与此点的志愿者）。
• 开发者工具提供的一些功能将被重新用于允许最终用户在不需手动编码的情况下扩展其站点的功能（如创建新的模型类以添加自定义文档类型），但我们是否将直接提供这些应用程序给用户，或者将在其他地方提供他们的一些功能，需要定义。
• 最后，旧的Xoops2核心将被重新实现为Xoops4应用程序。这将使我们能够提供最大化的兼容性，因为Xoops2模块将使用的一些类将实际上是旧的2.x版本（而大多数底层类将进行桥接，以使旧模块透明地访问X4的一些新功能）。

OOO（开源，开放设计，开放开发）

在我们开发此版本的过程中，主要目标是使Xoops成为一个真正的开源项目，并且高度集体化。从我最近看到的一些论坛帖子上看到的情况，我猜想大多数当前的Xoops用户可能没有意识到这种变化的这种重要性：这从来不是以前的情况，这种情况最严重的后果就是Xoops2架构无法轻松地增强，这本来可以允许我们通过更集体的努力继续其开发。

这一目标将给传统的Xoops开发方法论带来很多变化。这意味着每个人都可以忘记之前核心开发团队采用的“私下编码，完成后发布”的方式，可以说“你好”早期的alpha核心版本，或者长期期待的技术文档。更确切地说，这些都是你会在下周看到的事情。

• 将定期发布，采用更加“先发布，早发布”的方式。我们预计大约每两周或三周就会发布一个新版本。
• 第一个alpha版本将很快发布。这将标志着该项目成为一项集体工作。如果程序员没有东西可以工作，他们就无法一起工作。我们将在之后立即有东西。
• 在项目开发初期阶段将使用Sourceforge工具。当然，CVS、论坛、我们发现必要的任何工具。从六月初的第一个周末开始，现有的机制或预期提升将在Sourceforge上描述和解释，即使实际从事核心工作的人数不超过一两个。成功贡献的关键是让人们了解如何贡献，并从一开始就为此付出大量努力。
• Catalysis发布后，核心开发者将着手建立一个新核心开发站，该站点将提供更多定制化或更符合我们需求的工具，比Sourceforge的工具更加灵活。从这一点起，人们的需求将成为推动核心添加的动力。
• 随后，在新核心开放后，将逐步越来越多地满足人的需求。每个为XOOPS项目做出贡献的人，队与队，都将被纳入考虑，成为XOOPS无协议空间的一部分：联络、文档、模块仓库、公共关系。在这一部分，XOOPS将演变成人们需要用于协作和沟通的工具。这将在Xoosphere项目的最后阶段，完全重建所有的xoops.org网站。
• XOOPS4nAPI将完全进行文档编制。每个类或组件（可能除了一些真正早期和实验性的之外）都将至少附有phpdoc注释。接口冻结状态也将明确指出，以便开发者了解可能被修改的内容。
• 将并行编写一个真正的“XOOPS核心技术参考库”，与核心开发同步（不是“API参考”，而是真正的文档，供人类阅读：包括文本、解释、示例...不是可以用来编写代码的属性列表，而是一种人们可以阅读的内容，以便他们能理解）。