场景：在 Neos 2.0 站点中，我需要显示内容项，包括对项进行排序、过滤和使用分页。这些项目都有相同的内容结构，包括标题、描述、开始日期、结束日期等。（它或多或少是一个事件数据库。）
解决方案想法：我对 Neos 的经验很少，但从我目前所读到的内容来看，我认为将其作为一个遵循经典数据库后端方法的插件来实现是有意义的：作为普通记录持久化的模型对象（不是Neos 节点）在数据库中。我已经创建了一个包和插件，并且显示项目到目前为止工作。
问题：我现在卡住的地方是编辑事件。Neos 文档没有提到任何关于在后端编辑插件相关内容的内容。所以，用 MVC 术语来说，我只需要在后端添加、更新和删除这些事件的路由。
问题：在 Neos 中执行此操作的方法是什么？还是我错了，插件不是合适的方法？
因此，如果您下定决心，您当然可以使用自己的 Flow 插件来显示和编辑数据。要走的路是自定义后端模块。编写这些 API 的 API 尚未公开，但您仍然可以尝试从 Neos 的核心模块中获取示例并自己编写代码。API 的不稳定性不应该让你害怕太多，因为你不需要太多它，因为你将自己实现大部分东西。
基本上，您将创建 Flow 插件，该插件将实现您的自定义 API 以列出和更新您的记录，然后为其构建编辑界面。您可以按照自己喜欢的方式实现自己的 API，从普通的 JSON 到 REST 甚至 GraphQL，无论如何，它与 Neos 甚至 Flow 都没有真正的关系。
这种方法有很多开销，因为 Neos 不会以任何方式帮助您编辑或存储内容，并且怀疑它在大多数情况下是否合理。
我将尝试解决您对使用 Neos Content Repository 的假设，并希望表明它比表面上看起来更强大
1）最终，将有数百个项目。我不希望在单个父节点下方有这么多节点的良好编辑体验。
这是一个非常有道理的担忧。当前，当您在同一级别上拥有数百个节点时，用户体验并不是最佳的。使用此功能将大大改善这种情况：处理基于流的节点
现在有一个小设置可以极大地改善这种情况下的用户体验。将此配置添加到 Settings.yaml 文件将使树在加载时仅扩展至第一级：
TYPO3:
Neos:
userInterface:
navigateComponent:
nodeTree:
loadingDepth: 1
然后，您可以通过站点本身的前端（分页、过滤等）浏览记录，并且在添加新节点时只需要树。但即使在这种情况下，即使在同一级别上有数百个节点，树也能非常可靠地工作。
2) 我想排序、过滤等主要是在 TypoScript 中完成的——只要我可以使用纯 PHP，我都会尽量避免。
我不知道您想避免使用 TypoScript 的原因是什么。TypoScript 只是纯 PHP 代码的一个薄包装器，您可以在它的任何部分（自己的对象、EEL 帮助程序、FlowQuery 操作等）中使用 PHP。如果您关心性能，您可以使用ElasticSearch 适配器列出记录，即使有数百万条记录，它也会为您提供出色的性能。
但是即使使用普通的 TypoScript 和 FlowQuery，在多达数万个节点的情况下性能也基本可以，尤其是在视图被缓存的情况下。
3）有几个过滤器可以组合（由用户在浏览器中），一旦选择了一个过滤器，用户应该只能在有实际结果的地方添加那些过滤器。如果这个逻辑可以在 TypoScript 中实现，我会感到非常惊讶。
想给您一个惊喜，但是使用 FlowQuery 和 TypoScript 进行过滤就像使用 jQuery 过滤 DOM 一样简单……可能只需一个过滤器操作就足以满足您的所有需求。
但是，如果您需要更自定义的东西，您总是可以再次用纯 PHP编写自定义 FlowQuery 操作。
如果您不想自己实现所有内容，请使用 Content Repository 和 Neos 的本地处理方式，最好将剩余的时间/预算投入到改进您认为仍然不符合您的 Neos 用户界面的部分任务。
编辑：自定义后端模块的创建现在记录在这里： http: //neos.readthedocs.org/en/2.1/ExtendingNeos/CustomBackendModules.html