There is 1 comment.
 
 
Cristal / cid:jira-generated-image-avatar-5dda4ee8-a873-4c24-8f2a-3c21ad8cf3ad CRISTAL-67 Open

Cristal provides a search interface

 
View issue   ยท   Add comment
 

1 comment

 
cid:jira-generated-image-avatar-909c323c-edfc-4d49-807b-09fcfcfa6a10 Marius Dumitru Florea on 25/Nov/24 11:51
 

I'm getting closer to have something working, but I have some points to discuss:

  • at the UI level:
    • I'm not sure what route / URL to use to expose the main search UI (e.g. after you press Enter on the search input on the left column), that is unless we show the main search UI in a modal, but the mock-ups Thiago Krieck made are not using a modal. The "difficulty" is that the search UI doesn't have a wiki page behind (like in the case of XWiki where the search UI is implemented in a wiki page).
    • the search UI mockups use the classic index-based pagination, but in my implementation I've started using "More..." / cursor-based pagination (in Solr implementation) to load more search results, because I don't see the benefit of jumping to a specific page in the search results. Thiago Krieck WDYT?
  • at the API level: the search API I have is currently returning a generic SearchResult, because I didn't want to limit the search results to wiki pages or attachments (and we currently don't have a base "Entity" class AFAIK). I'm planning to have a "search result displayer" component with implementation for page and attachment (for now the implementation is hard-coded)
  • at the backend level: I'm using the XWiki.SuggestSolrService page to get the results, but I had to modify it to give me also the facet values and other metadata like supported sort fields. I'm wondering if I should push these change in XS (even if they are not used / needed there) or move them in the Cristal extension. I prefer the first option.