| | 1 | = !BluePrint: Client Processed Search Form = |
| | 2 | [[TOC]] |
| | 3 | |
| | 4 | == Introduction == |
| | 5 | Currently we're processing the entire search form server-side as a POST, have |
| | 6 | the SearchWidget instances parse its variables into a S3ResourceQuery, then |
| | 7 | perform a filtered CRUD/select and return the resulting datatable to the |
| | 8 | client. For pagination of this datatable, we store the record IDs of the |
| | 9 | result in the session to be able to run the datatable Ajax request against it. |
| | 10 | |
| | 11 | Apart from all the implications for GUI design - from a REST perspective this |
| | 12 | is totally wrong. It should definitely not be a POST - but a GET, and it must |
| | 13 | not change state of the REST-API (i.e. must not store the IDs as filter |
| | 14 | server-side). |
| | 15 | |
| | 16 | == Use-Cases == |
| | 17 | * switching between representation methods (report/map/list) retaining the same filter |
| | 18 | * easy integration of filters in any representation method (report/map/list) |
| | 19 | |
| | 20 | == Benefits == |
| | 21 | === Functionality === |
| | 22 | * Improved performance through: |
| | 23 | * Asynchronous loading of the search forms |
| | 24 | * Asynchronous loading of the search results |
| | 25 | |
| | 26 | === Design === |
| | 27 | * We're replacing the current heavy S3Search module with a set of light-weight |
| | 28 | widgets utilizing the (already existing) filter capabilities of the REST API - |
| | 29 | a way less redundant and more RESTful, consistent, flexible, elegant and |
| | 30 | scalable way to provide the same functionality. |
| | 31 | * We're eliminating the need for duplication of Search code in both the Search and Report method |
| | 32 | |
| | 33 | == Requirements == |
| | 34 | |
| | 35 | === Current === |
| | 36 | * Enable the user to open a new representation method of a search in a new window |
| | 37 | * Asynchronous load the Simple Search Form and the Advanced Search Form separately |
| | 38 | * Review Saving & Loading of Searches. Ensure that when a search is loaded, the widgets are populated with the search criteria. |
| | 39 | * No changes to the current Search UI (are any needed?) |
| | 40 | |
| | 41 | === Possible Current === |
| | 42 | * Would we be able to cache search forms? Either by permissions (maybe hard - unless not OrgAdmin?) or user (maybe easier?) |
| | 43 | * Would it be possible to initiate the search when the widgets are changed and remove the search/submit button? If this is the case, can we replace the datatable quick search? This would be a MASSIVE win. |
| | 44 | * Would it be possible to integrate the search form into the list page - and therefore remove the need for a search method & different search page? |
| | 45 | |
| | 46 | === Possible Future Extensions === |
| | 47 | * Async Load the Report results |
| | 48 | * Display multiple Data Representations method for a single search form on a one page (dashboard style?) |
| | 49 | |
| | 50 | == Design == |
| | 51 | 1. Have the search widgets self-processing *client-side* into [wiki:S3XRC/RESTfulAPI/URLFormat URL filters]. |
| | 52 | No server-side search form processing at all, the server would always only |
| | 53 | parse URL filters. |
| | 54 | |
| | 55 | 2. Submission of the search-form collects these URL filters (client-side) and |
| | 56 | then sends them with a GET-request to the REST-API, either as Ajax or as full |
| | 57 | page request (=window.open). This request does not go to the /search method, |
| | 58 | but instead to the respective representation method (e.g. /report, /list, /map), without need for those method |
| | 59 | handlers to process the filters: they can simply assume that they get a pre- |
| | 60 | filtered resource. |
| | 61 | |
| | 62 | 3. The REST-API would then pre-filter the resource, and then hand it over to |
| | 63 | the requested method handler - map, list, report or whatever and in whatever |
| | 64 | data format (=RESTful request as usual). Whether this is Ajax or not depends |
| | 65 | entirely on the client-side implementation - it could be either. It could even |
| | 66 | be neither, but instead a web service request (e.g. from mobile clients, or |
| | 67 | from an external site) - which leads directly to point 4: |
| | 68 | |
| | 69 | 4. SearchWidgets/-forms can be requested directly from the REST-API (from the |
| | 70 | re-defined /search method) - so that they can be embedded everywhere - and get loaded |
| | 71 | asynchronously. Since they are processed client-side, there's no need to keep any formkeys or |
| | 72 | session variables. This GET /search method can also include loading of saved |
| | 73 | searches, and the POST /search method would then only serve for save |
| | 74 | search/subscription (which actually makes sense from the REST perspective), |
| | 75 | but not for processing the search. |
| | 76 | |
| | 77 | I know that this requires a fair bit of framework client-side (somewhat a |
| | 78 | client-side pendant for S3Resource), but this is something we might need |
| | 79 | anyway. |
| | 80 | |
| | 81 | 2) Search-forms can be requested from the REST API using the GET /search |
| | 82 | method. That way, they can be embedded in every page - and get loaded |
| | 83 | asynchronously. Since search forms would never get submitted to the server, |
| | 84 | there is no need to store anything server-side anymore. |
| | 85 | |
| | 86 | == Implementation == |
| | 87 | ''Coming soon...'' |
| | 88 | |
| | 89 | ---- |
| | 90 | * BluePrints |
| | 91 | * BluePrintSearch |
