Add the possibility to search by ContentId or LocationId in the searc…

[ghost]

Add the possibility to search by ContentId or LocationId in the search tab of the browse feature in Universal Discovery Module.
In the UDM, we have the need to find content directly by contentId or locationId. With a lot of contents, browsing is often not an option and search results are sometimes a bit weird. It becomes difficult to find the content we look for.
This PR improves the ViewInput filter by reading the search query and searching something like "content:123" or "location:456". If such a pattern is found, replace the current FullTextCriterion with a LocationIdCriterion or ContentIdCriterion. Else keep the FullTextCriterion

[andrerom]

This is interesting, could build upon this kind of things with more expressions ala what was added to fulltext.

/cc @SylvainGuittard

[SylvainGuittard]

Thanks @NonoKaliop for the contribution. I think it's a interesting idea.
If we had this new possibility to search, it should be implemented everywhere: UDW and the search page in ezplatform-admin-ui. If not, the user might be frustrated to have it only on one interface.
This is my recommendation for adding this to the product.

Side question: does it make sense to also add remoteID? I don't have a use case, just asking.

[andrerom]

Side question: does it make sense to also add remoteID? I don't have a use case, just asking.

It's should at least be possible to add it.

Two people that might have interesting things to add here is:

1. @bdunogier He worked on a query language to Query object mapper, it can be worth it to resurrect this as it was more or less done, and it can potentially be what you are asking for here, a common layer for all UI's to use, assuming the query language isn't to technical for editors for plain full text use.
2. Possibly also @pspanja who worked on query parser for Full Text, as he might also have given queries beyond Fulltext a thought.

[pspanja]

@andrerom Query Translator would fit well here, you can cover these cases using the domain feature. And you can also customize the syntax and implement a generator that would convert AST to search criteria.

Implementing a language supporting basic subset of search API has been on my to do list for some time now.

[andrerom]

So maybe Query translator on top of @bdunogier's https://github.com/ezsystems/QueryBuilderBundle or something like it could be a possible approach then to expose a EZQL in search interfaces* :)

* And later allow those searches to be saved and used for views and filters across the system ✨

[pspanja]

Well, depends :) Query Translator would be perfect for handling user input, but handling some more complex criteria like Field or MapLocationDistance could be a bit awkward. On the other hand if you want to have a text field for input, you probably also don't care for supporting stuff like that anyway.

But if you want to have some kind of query builder UI you might also want to go for a different language, one that would be formal and strict. It should not be too hard to implement since you would not need to worry about handling errors and Query is basically already an AST. So something that would more or less translate directly from the Query, like:

LogicalAnd(LogicalOr(ContentId(42), Field(title, eq, CMS)), MapLocationDistance(location, between, [25, 32], 42, 17))

That is still readable, but I think not too friendly for user input.

[andrerom]

Good input! 😃

Maybe there is enough initial info here to get PM team to aim to specify something soon on this, sounds like a plan @SylvainGuittard ?

[SylvainGuittard]

Happy to see that we are making some progress here. I will sync with @bdunogier for some specifications.

[sunpietro]

@SylvainGuittard @andrerom @bdunogier what is the status here?