|
1 .. _searchbar: |
|
2 |
|
3 RQL search bar |
|
4 -------------- |
|
5 |
|
6 The RQL search bar is a visual component, hidden by default, the tiny *search* |
|
7 input being enough for common use cases. |
|
8 |
|
9 An autocompletion helper is provided to help you type valid queries, both |
|
10 in terms of syntax and in terms of schema validity. |
|
11 |
|
12 .. autoclass:: cubicweb.web.views.magicsearch.RQLSuggestionsBuilder |
|
13 |
|
14 |
|
15 How search is performed |
|
16 +++++++++++++++++++++++ |
|
17 |
|
18 You can use the *rql search bar* to either type RQL queries, plain text queries |
|
19 or standard shortcuts such as *<EntityType>* or *<EntityType> <attrname> <value>*. |
|
20 |
|
21 Ultimately, all queries are translated to rql since it's the only |
|
22 language understood on the server (data) side. To transform the user |
|
23 query into RQL, CubicWeb uses the so-called *magicsearch component*, |
|
24 defined in :mod:`cubicweb.web.views.magicsearch`, which in turn |
|
25 delegates to a number of query preprocessor that are responsible of |
|
26 interpreting the user query and generating corresponding RQL. |
|
27 |
|
28 The code of the main processor loop is easy to understand: |
|
29 |
|
30 .. sourcecode:: python |
|
31 |
|
32 for proc in self.processors: |
|
33 try: |
|
34 return proc.process_query(uquery, req) |
|
35 except (RQLSyntaxError, BadRQLQuery): |
|
36 pass |
|
37 |
|
38 The idea is simple: for each query processor, try to translate the |
|
39 query. If it fails, try with the next processor, if it succeeds, |
|
40 we're done and the RQL query will be executed. |
|
41 |