Joomla! 社区门户

下载
启动

分类扩展 - 设计规范和API

plugin_taxonomy

建议:

实际的用户交互在这里发生。因此，以下在设计和组织中非常重要。

  1. 需要收集哪些信息
  2. 简洁程度或详尽程度
  3. AJAX的使用
  4. 自动化
  5. 其他多个可用性因素

其次，这是Joomla!的一个关键点，因为目前的实现似乎不支持从统一的点（类似于Drupal中的CCK）向表单中注入额外的字段。然而，预计Joomla! 1.6核心将提供此功能，因此将予以考虑。

第三是能够从集中点提供表单字段。例如，组件X正在创建一个包含几个文本字段的表单。通过调用一个函数（getTaxonomyFields），它应该能够从我们的库中检索一组表单字段（可能是HTML形式），并在任何合适的位置注入到它们的表单中。在表单提交后，组件X提取相关字段并调用一个函数（replyTaxonomyFields）并返回变量。在Joomla!中，甚至演示和逻辑也被分离到"html.php"和".php"中，我很想知道我们如何在不违反Joomla!设计模式的情况下实现类似这样的功能。

区块

以下是通过通用方式将分类映射到项目的方法。

  1. 单个选择框 - 适用于类别（参考常见结构）且叶节点数量有限的情况
  2. 文本字段 - 这是自由标记背后的基础，其中叶节点是在术语在数据库中不存在时动态创建的。用户以逗号分隔的形式输入术语列表。
  3. 自动完成文本字段 - 适用于标记，但需要额外的工作，特别是在AJAX请求处理和查找匹配术语方面。在GSoC条款下是可选的，但非常有用。
  4. 层级选择框 - 适用于渠道，其中第一选择框中的第一级叶子的选择将带来第二选择框中的第二级叶子（例如：drupal.org/project/hierarchical_select）。然而，涉及的复杂性可能会推动其成为一个独立的项目，并且不予考虑。

交互点

首先，用户在创建/编辑对象时必须能够指定术语，例如内容项。但是，分类框架必须是灵活和简单的。例如，如果我们使用分类框架对用户进行分组，比如说使用名为 'tuser' 的树对 com_user 进行分组，我们必须能够在用户编辑表单中注入表单字段。当已经有这样的分组功能时，这看起来可能是不合逻辑的。因此，提供必要表单字段是组件的责任，当分类库位于核心时，这可以轻松执行。但是有两个警告。

  1. 已经存在的组件可能期望从分类框架中得到内置的解决方案，我们打算在此背景下支持 com_content。
  2. 在所有分类组件之间保持一致性。  这可以通过从中心位置（最好是通过分类库，参考上面的第三个建议）向块提供依赖于结构或确切地说树的属性来实现。表单字段将以数组形式传递，以便渲染组件可以决定其展示方式，例如选择框或文本字段的大小，以及格式化的 HTML 字符串，以便可以直接放入表单中。 

第二个交互点是项目显示的地方。例如，对于内容项，我们可能希望显示与内容关联的术语。如果分类框架在类别或关键词的结构下使用，非常重要的是它应该显示给用户。对于书籍结构，组件可能更愿意沿着面包屑或标题显示。因此，布置是组件的责任，有以下规定。

  1. 为现有模块提供支持，特别是 com_content（参考建议2）
  2. 其次，保持一致性。  例如，根据给每个叶子赋予的权重（参考数据库结构），它会下沉或浮动。在这个背景下，较轻的会首先列出。分类库将返回一个数组和格式化的 HTML 字符串（有两种选择，如前一个案例），可以用于此目的。

针对以下功能的其他插件的潜力（超出我们的范围）

  1. 自动化 - opencalais 集成
  2. 更好的用户交互 - 以一种特别的方式选择术语，WordPress 在某种程度上实现了这一点。

Com_taxonomy

 基于 MVC 的管理表单的后台组件。我打算遵循这个： https://docs.joomla.org/Developing_a_Model-View-Controller_Component_-_Part_1  和《Learning Joomla Extension Development》的第5章。因此我打算跳过关于 Joomla! 的实现细节。

后台表单

基于 MVC 的管理表单的后台组件。我打算遵循这个： https://docs.joomla.org/Developing_a_Model-View-Controller_Component_-_Part_1  和《Learning Joomla Extension Development》的第5章。因此跳过 Joomla! 基于的实现细节。

建议：由于这里发生了用户交互，我希望能得到您关于在这里使用 ACL 的建议或参考。

  1. tree_edit: 编辑/添加叶子及其属性
  2. leaf_Edit : 编辑/添加叶子及其属性

注意：受控分类法只能在这里添加/删除叶子。
注意：创建树是一个双向过程。一个在后台，您可以设置确定最终分类树结构的属性，完全是手动的；另一个在前台，部分自动。

  1. List_trees_overview : 树列表
  2. List_leaves_overview : 叶子列表
  3. 树状图概述：树与扩展之间的映射列表。该映射应在后台代码中完成，该列表仅作为参考，不应用于创建此类映射
  4. 叶映射概述：叶与扩展对象之间的映射列表，例如com_content的文章。
  5. 分类设置：页面用于编辑分类框架的全局设置

注意：它决定了从前端创建分类树和叶的能力，应暴露哪些属性以及隐藏属性的默认值。

前端表单

  1. tree_edit: 编辑/添加叶子及其属性
  2. leaf_Edit : 编辑/添加叶子及其属性
  3. List_trees_overview : 树列表
  4. List_leaves_overview : 叶子列表
  5. 给定叶的内容列表

分类组件的其他组件或扩展的潜在列表

  1. 来自编码URL的术语列表。例如，一个像(?option=com_component&leaves=+1,2,3,4,5-8,34,21)的URL可以用来创建包含/排除列表，我们可以显示一个可点击的叶列表，甚至是它们映射到的对象列表。

分类库

通过单例类公开的实用函数。

建议

  1. 你认为将Tree和Leaf分开成两个类，并在单独的类中提供相关函数是一个好主意吗？
  2. 我试图弄清楚Joomla!中的钩子是如何工作的。有特殊的模式吗？你能给我一个教程或示例钩子的链接吗？我习惯了通过调用extensionname_hookname()函数来实现钩子，如Drupal中的所有实现该函数的扩展都被调用。
  3. 最后，我认为这个抽象类没有实际用途，因为功能已经明确定义。如果你有任何要遵循的Joomla!特定模式，请告诉我。
  4. 有没有可以订阅以执行定时任务的事件？

API

请注意，实现组件有责任在“项目删除”和“更新”事件上调用删除或更新方法，分类库不会监听此类事件。另一方面，他们可以选择实现如hookLeaf之类的钩子来监听相关事件。

模块分类

模块可以扩展用户体验，这在之前的提案和其他文档中已有说明。（超出GSoC的范围）

潜在模块的示例列表

  • 通过比较匹配术语来列出类似项目。
  • 标签云
  • 分类菜单
  • 分面浏览
  • 展览
  • Cumulus
详情