As the FE will not contain the entire SiteMap any more, we need to reimplement searching.

The BE will return the filtered SiteMap tree and the FE only needs to display that

SEARCH (FILTERING) : search on 'foo'

Criteria: search via backend, minimum 3 chars, only send after 1 sec no typing or enter

/
  + child2
      + subchild1
          + foo
  + child5
      + subchild1
          + foo

dhachok can you provide the desired API call for this?

I'd expect the BE API call to be:

_rp/{sitemapUUID}./sitemap?fq={input}

Response 200. The structure of the response should be similar to the structure we already have for other API calls of page tree, like:

"data":{ 
  "id":"/", 
  "name":"home", 
  "pageTitle":null, 
  "pathInfo":"/", 
  "renderPathInfo":"/site/v1/channels/brxsaas", 
  "experiencePage":false, 
  "children":[{ 
    "id":"about",
    "name":"about", 
    "pageTitle":"About", 
    "pathInfo":"about", 
    "renderPathInfo":"/site/v1/channels/brxsaas/about", 
    "experiencePage":true, 
    "expandable":false 
  }]
}

We should be able to filter by name, pageTitle and pathInfo (check if possible to check for "contains" rather than just the begging of the property).

Implementation Details Backend

(team-quasar-qa FYI)

As since ENT-5847 the backend only serves that part of the sitemap tree
which is requested by the FE, the FE does not contain the entire
sitemap tree any more.

Hence new 'resty' endpoint

_rp/{sitemapUUID}./search

has been added which takes query param 'fq' to contai the 'filter
query'. We call it fq as it is more a filter than a a search and we
use similar terms like
https://solr.apache.org/guide/6_6/common-query-parameters.html

An example URL is

_rp/{sitemapUUID}./search?fq=floor-lamps

returning all sitemap items including the first line ancestry of
the matching item.

The matching item can be a search hit in a hst sitemap (routes) OR in
an XPage document. This is particularly complex in case the resulting
sitemap item is a combination of an hst sitemap route and it also has
potentially descending XPage docs. Will the sitemap item have the flag
'expandable' or not is particularly complex.

For example when there is searched on 'news' and the HST sitemap (routes)
is something like

+ hst:sitemap
   + news
       + _any_

Obviously 'news' matches, but is it expandable or not? In the result from
the backend, we do not include the direct children, only if the result is
expandable or not. It will be expandable in the above example if and only
if there is at least 1 XPage document with a pathInfo (URL) starting with
'news/' and which is readable for the current CMS user. This is the complex
part of the implementation

If the fq input is shorter than 3 chars, the backend returns a 400
BAD_REQUEST with error code

INVALID_FILTER_QUERY