Add SearchBuilder JSON serialization support

[Toflar]

Search UIs often need to preserve and share a complete search state: query text, filters, sorting, pagination, highlighting, distinct handling, and facets. Passing each part through separate request parameters makes controller and API code grow quickly, and it becomes harder to hand the same search state between pages, links, and clients.

This adds a JSON representation for SearchBuilder, so applications can pass the complete search state as one value, for example ?search=<json>.

The index remains internal and is intentionally not part of the serialized payload. Public endpoints can also provide a SearchBuilderValidation instance when reading external JSON, allowing them to expose only a safe subset of internally available filters, facets, sorting, and other search features.

See documentation on how this can be used 😎

[alexander-schranz]

Looks interesting, I understand the usecase, it goes into the same direction I had in mind with support for Galach / #462.

In my opinion Condition, Facet, .... class should be kept as they were before, they should know nothing about this whole mechanic same for the SearchBuilder. I totally aware of the disadvantage of that but want keep core things as small as possible. Own functionality should live in its own place, I even has already some parts in mind to be split out.

For me this is an own factory service which single responsibility is add filter, sortbys, ... by the given array and config:

Something like:

$jsonSearchBuilderFactory = new JsonSearchBuilderFactory($this->engine);

$searchBuilder = $jsonSearchBuilderFactory->build(
   'blog',
   $jsonSearchBuilderConfig,
   $array,
);

I really like the concept that every Builder has its SearchBuilderValidation, not sure about the name so I would go with JsonSearchBuilderConfig, but it should not be optional as it could else open unexpected security issues, specially with the extendability of Indexes SEAL provides.

Another question is it really should concentrate on json or better on array, which example the output of Symfony Forms or other similar libraries can produce.

So maybe ArraySearchBuilderFactory is the better name here,

I think the feature could be implemented the way it lives only in 2 classes and not have need change any other classes:

• ArraySearchBuilderFactory
• SearchBuilderFactoryConfig

inside a SearchBuilderFactory namespace. The SearchBuilderFactoryConfig is something which may can in future also be used to create a GalachSearchBuilderFactory or any other future query language translator can use.

[Toflar]

A bit more like this then? 😊

[alexander-schranz]

Did not do yet do a deep review but yes :) 👍