-
-
Notifications
You must be signed in to change notification settings - Fork 221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP FEATURE: Configurable node search service #5134
base: 8.4
Are you sure you want to change the base?
Conversation
@bwaidelich this is the idea I mentioned regarding a configurable resolver based node search service. I understand that the API might need to be different if we want something like that for the future. |
Disclaimer: I might misunderstand the purpose of such an API (maybe it would help if we clearly formulated the scope and goals). It's a really hard task to come up with a general API because there's a high risk that it's either too specific to the implementation or too abstract. And it can only provide the common denominator of features that all implementations support (e.g. elasticsearch provides aggregation features, but other implementations might not). With Neos 9, we'll already have a quite capable search built into the core model ( So personally I would not be happy about a new core concept for 8.4 that will most probably not survive with 9.0. Why not provide a 3rd party package that you can install if you want to re-use that specific interface? |
e14b5b0
to
c7254d9
Compare
I would do that if that package would survive 9.0 without too many changes 😉 Meaning, there would be a service I can override. There are already a few package overriding the current service, so it would make sense if they follow a common interface so they can enhance each other. Resulting in a "find a node in any way you might want" way. F.e. I implemented a resolver here that can resolve uris to nodes with the help of the router. The CR search wouldn't help me in this case (I think). But depending on the project the uri resolver has to have a custom implementation or require a second resolver, as in my case the Neos Uris and the actual frontend Uris for visitors are not the same. As long as we have several ways of identifying a node in the frontend, error messages and wherever else, IMO it's useful to offer the capability of finding those nodes via a common endpoint. I can't imagine that our CR search can give the same performance and quality of results as a fulltext search configured for a project. On the other hand its confusing that the reference selector uses the same search in 8.3 as its searching for content and documents, and most searches are optimised for documents as aggregates. Probably better if we have a call 😉 |
A common interface that doesn't have a clear API nor behavior does more harm that it helps in my opinion.
That's a good example and I think it makes sense to support URL-Lookups in the default Backend search vor example.
No, it won't be able to replace a proper search engine in all cases. But I'm confident that it will be pretty fast for the general use cases. And for the others I don't think that the solution is a common interface, but rather a different entry point for this scenario. If we were to introduce a central API, we should define input and output more precisely IMO otherwise it won't be much better than the current
Yes, anytime! :) |
Just a WIP idea to make the NodeSearchService fully configurable, so it doesn't need to be fully replaced by a plugin, but instead calls a list of resolvers which can accept a term and return results.
Its unclear whether this service will still exist in 9.0, but having a concept for a configurable service might still be good in the future.
This one helps me right now a lot in a real project.
Checklist
FEATURE|TASK|BUGFIX
!!!
and have upgrade-instructions