The objective is to conceive a fluent, easy to use API to build location and content search queries. The keyword is fluent, as defined by Martin Fowler: the API methods should match the Domain Language as closely as possible. Chaining of methods is esthetic sugar, but required sugar if we want IDEs to provide contextual completion that always makes sense. Within a given context, the IDE should suggests valid elements, and valid elements should always be suggested.
How is field filtering handled ?
Each field will support its own type of filtering. This type has a semantical meaning: string, number, date...
The FieldType should be the one documenting this, by implementing an interface (StringSearchable, NumberSearchable ?). Can those belong to the API ? At the very least, it should be possible to implement extra services/interfaces that provide this "mapping".
How are they presented semantically speaking ? Facet ? Group ?
The term "facetting" is clearly part of the search domain, while "grouping" is from the SQL domain ?
Sounds like it works...
- IdCriterionBuilder
- DateCriterionBuilder
- TextCriterionBuilder
The kernel must contain a pre-generated QueryBuilder (possibly updated via generation ?)
Should the generated query builder extend the native one, or should it only extend the base one ? Should the generated query builder only add methods based on what is added to the system ? Or is the whole builder dynamic depending on the system ? e.g. are native criterion and fields unmutable, or can their behaviour be overridden ?
Does it belong in eZ/Publish/API ?
If eZ/Publish/API is only meant for the API repository, it could be moved to another namespace
However, it should still be a higher level API, part of a namespace explicitely documented as public and maintained. SiteAPI ? Don't like the name very much though.
It would mean that this API is public. Ideally, it would list
Written with StackEdit.