【问题标题】:Neos CMS 2.0: Editing records in a pluginNeos CMS 2.0:在插件中编辑记录
【发布时间】:2015-12-11 16:11:19
【问题描述】:

场景:在 Neos 2.0 站点中,我需要显示内容项,包括对项进行排序、过滤和使用分页。这些项目都有相同的内容结构,包括标题、描述、开始日期、结束日期等。(它或多或少是一个事件数据库。)

解决方案思路: 我对 Neos 的经验很少,但从我目前所读到的内容来看,我认为将其作为一个遵循经典数据库后端方法的插件来实现是有意义的:在数据库中作为普通记录(不是 Neos 节点)持久化的模型对象。我已经创建了一个包和插件,并且显示项目到目前为止工作正常。

问题:我现在卡住的地方是编辑事件。 Neos 文档没有提到任何关于在后端编辑插件相关内容的内容。所以,用 MVC 术语来说,我只需要在后端添加、更新和删除这些事件的路由。

问题:在 Neos 中执行此操作的方法是什么?还是我错了,插件不是合适的方法?

【问题讨论】:

  • 同时我发现后端模块可能是更好的选择,但根据 08/2015 对讨论.neos.io 的评论,目前既没有记录也没有 API 被视为稳定……
  • 您为什么不想为您的内容使用节点?完成上述所有操作应该很容易:列表、排序、过滤、分页。我通常使用这个包来减少此类用例的样板代码github.com/Flowpack/Flowpack.Listable
  • 三个原因: 1) 最终会有数百个项目。我不希望在单个父节点下方有这么多节点的良好编辑体验。 2) 我想排序、过滤等主要是在 TypoScript 中完成的——只要我可以使用纯 PHP,我都会尽量避免。 3)有几个过滤器可以组合(由用户在浏览器中),一旦选择了一个过滤器,用户应该只能在有实际结果的地方添加那些过滤器。如果这个逻辑可以在 TypoScript 中实现,我会感到非常惊讶。
  • 我的回答不够完整吗?您还想了解更多详情吗?

标签: neoscms


【解决方案1】:

插件方式

因此,如果您下定决心,您当然可以使用自己的 Flow 插件来显示和编辑数据。要走的路是自定义后端模块。编写这些的 API 尚未公开,但您仍然可以尝试从 Neos 的核心模块中获取示例并自己编写代码。 API 的不稳定性不应该让你太害怕,因为你不需要太多它,因为你将自己实现大部分东西。

基本上,您将创建 Flow 插件,该插件将实现您的自定义 API 以列出和更新您的记录,然后为其构建编辑界面。你可以按照自己喜欢的方式实现自己的 API,从普通的 JSON 到 REST 甚至 GraphQL,无论如何,它与 Neos 甚至 Flow 都没有真正的关系。

这种方法有很多开销,因为 Neos 不会以任何方式帮助您编辑或存储内容,并且怀疑在大多数情况下它是否合理。

内容存储方式

我将尝试解决您对使用 Neos Content Repository 的假设,并希望表明它比表面上看起来更强大

1) 最终会有数百个项目。我不希望在单个父节点下方有这么多节点的良好编辑体验。

这是一个非常有道理的担忧。当前,当您在同一级别上拥有数百个节点时,用户体验并不是最佳的。使用此功能将大大改善这种情况:Handling of stream based nodes

目前有一个小设置可以极大地改善这种情况下的用户体验。将此配置添加到 Settings.yaml 文件将使树在加载时仅扩展至第一级:

TYPO3: Neos: userInterface: navigateComponent: nodeTree: loadingDepth: 1

然后,您可以通过网站本身的前端(分页、过滤等)浏览记录,并且在添加新节点时只需要树。但即使在这种情况下,即使在同一级别上有数百个节点,树也能非常可靠地工作。

2) 我想排序、过滤等主要在 TypoScript 中完成——只要我可以使用纯 PHP,我都会尽量避免。

我不知道您想避免使用 TypoScript 的原因是什么。 TypoScript 只是纯 PHP 代码的一个薄包装器,您可以在它的任何部分(自己的对象、EEL 帮助程序、FlowQuery 操作等)中使用 PHP。 如果您关心性能,您可以使用ElasticSearch adapter 列出记录,即使有数百万条记录,它也会为您提供出色的性能。

但即使使用普通的 TypoScript 和 FlowQuery,在多达数万个节点的情况下性能也基本可以,尤其是在缓存视图的情况下。

3) 有几个过滤器可以组合(由用户在浏览器中),一旦选择了一个过滤器,用户应该只能在有实际结果的地方添加这些过滤器。如果这个逻辑可以在 TypoScript 中实现,我会感到非常惊讶。

想给您一个惊喜,但是使用 FlowQuery 和 TypoScript 进行过滤与使用 jQuery 过滤 DOM 一样简单...可能只需一个 filter 操作就足以满足您的所有需求。

但是,如果您需要更自定义的内容,您可以随时write custom FlowQuery operations,再次使用纯 PHP。

总结

如果您不想自己实现所有内容,请使用 Content Repository 和 Neos 的本地处理方式,最好将剩余的时间/预算投入到改进您认为仍然没有的 Neos 用户界面的部分上。不符合你的任务。

编辑:自定义后端模块的创建现在记录在这里:http://neos.readthedocs.org/en/2.1/ExtendingNeos/CustomBackendModules.html

【讨论】:

  • 感谢您的详细解释。我会在一月份回到办公室时进行调查。至于我关于尽量避免 TypoScript 的想法:SO 不是讨论这个问题的合适场所——也许我会在 Discussion.neos.io 上发布一些内容。但底线是:我通常不愿意处理诸如 TS2 或 Eel 之类的专有东西,如果这是我的决定,出于这个原因,我不会为我最近从事的项目选择 Neos——尤其是因为它很可能是我将从事的唯一一个 Neos 项目。 (我知道其他有同样想法的开发人员。)
  • 我明白你的意思。如果您愿意,您也可以通过 PHP api 使用内容存储库和 flowquery。 Neos 不会强制你学习太多专有的东西,TS 就像我们的 PHP API 之上的薄包装器一样,使输出配置更具声明性。
  • 不过,如果您在这个问题上不再需要我的任何意见,您可以将此答案标记为已接受;)
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-06-23
  • 2015-07-03
  • 2015-11-26
  • 1970-01-01
  • 2018-07-31
  • 2023-03-23
相关资源
最近更新 更多