简体   繁体   中英

Neos CMS 2.0: Editing records in a plugin

Scenario: In a Neos 2.0 site, I need to display content items, including sorting the items, filtering and use pagination. The items all have the same content structure, consisting of title, description, start date, end date etc. (It is more or less a database of events.)

Solution idea: I only have little experience with Neos, but from what I read so far, I thought it would make sense to implement this as a plugin which follows a classic database-backend approach: model objects which are persisted as normal records (not Neos nodes) in the database. I've created a package and plugin, and displaying items works so far.

Problem: Where I'm stuck at the moment is editing the events. The Neos documentation does not mention anything regarding editing plugin-related content in the backend. So, speaking in MVC terms, I'd simply need routes for adding, updating and deleting these events in the backend.

Question: What is the approach to do that in Neos? Or am I wrong and a plugin is not an appropriate approach?

The Plugin way

So if you made up your mind, you certainly can use your own Flow plugin to display and edit data. The way to go would be the custom backend module. The API for writing those is not yet public, but you can still try to take example from Neos' core modules and do code something yourself. The instability of API shouldn't scare you too much, as you won't need a lot of it and it, as you will be implementing most of things yourself.

Basically you would create the Flow plugin that would be implementing your custom API for listing and updating your records, and then build the editing interface for it. You can implement your own API the way you like, starting from plain JSON to REST or even GraphQL, anyways, it's not really related to Neos or even Flow.

This approach has a lot of overhead, as Neos won't help you here in any way with editing or storing content, and doubt it can be justified in most of the cases.

The Content Repository way

I will try to address your assumptions about working with Neos Content Repository, and hopefully show that it's a lot more powerful than from what it looks on the surface

1) In the end, there will be hundreds of items. I don't expect a nice editing experience with that number of nodes below a single parent node.

This is a very valid concern. Currently when you have hundreds of nodes on the same level, user experience is not optimal. The situation would be greatly improved with this feature: Handling of stream based nodes

For now there's one little setting that greatly improves the user experience in this situation. Adding this configuration to Settings.yaml file would make the tree expanded only up to first level on load:

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

Then you can do browsing of records via the frontend of the site itself (paginated, filtered etc), and you would only need the tree when adding new nodes. But even in this situation, the tree works quite reliably even with hundreds of nodes on the same level.

2) I suppose the sorting, filtering etc. would mainly be done in TypoScript – which I try to avoid whenever I could use plain PHP.

I don't know what is the reason you want to avoid using TypoScript. TypoScript is just a thin wrapper around pure PHP code, you can use PHP in about any part of it (own objects, EEL helpers, FlowQuery operations etc). If your concern is performance, you can list records with ElasticSearch adapter , it would give you great performance even with millions of records.

But even with plain TypoScript and FlowQuery, the performance would be mostly fine with up to tens of thousands of nodes, especially if the view would be cached.

3) There are several filters which can be combined (by users in the browsers), and once a filter is selected, users should only be able to add those filters where there are actually results. I would be really surprised if the logic for this could be implemented in TypoScript.

Would like to surprise you, but filtering with FlowQuery and TypoScript is about as easy as filtering DOM try with jQuery... Probably just one filter operation would be enough to cover all your needs.

However if you would needed something even more custom, you can always write custom FlowQuery operations , in pure PHP again.

Summary

If you don't want to implement everything yourself, go with Content Repository and Neos' native ways of working with it, much better to invest the spared time/budget in improving parts of Neos' UI that you think still don't match your task.

edit : creation of custom backend modules is now documented here: http://neos.readthedocs.org/en/2.1/ExtendingNeos/CustomBackendModules.html

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM