BluePrint: Client Processed Search Form

Introduction

Currently we're processing the entire search form server-side as a POST, have the SearchWidget instances parse its variables into a S3ResourceQuery, then perform a filtered CRUD/select and return the resulting datatable to the client. For pagination of this datatable, we store the record IDs of the result in the session to be able to run the datatable Ajax request against it.

Apart from all the implications for GUI design - from a REST perspective this is totally wrong. It should definitely not be a POST - but a GET, and it must not change state of the REST-API (i.e. must not store the IDs as filter server-side).

Benefits

Functionality

• Improved performance through:
  • Asynchronous loading of the search forms
  • Asynchronous loading of the search results

Design

• We're replacing the current heavy S3Search module with a set of light-weight widgets utilizing the (already existing) filter capabilities of the REST API - a way less redundant and more RESTful, consistent, flexible, elegant and scalable way to provide the same functionality.
• We're eliminating the need for duplication of Search code in both the Search and Report method

Use-Cases

Current

• Switching between representation methods (report/map/list) retaining the same filter
• Enable the user to open a new representation method of a search in a new window
• Asynchronous load the Simple Search Form and the Advanced Search Form separately
• Review Saving & Loading of Searches. Ensure that when a search is loaded, the widgets are populated with the search criteria.
• No changes to the current Search UI (are any needed?)
• easy integration of filters in any representation method (report/map/list)
• The simple and advanced Search forms should be merged into a single form. The advanced form will simply be a number of additional fields which can be displayed / hidden.
• We should have the option to hide/display the options for each search field.

Possible Current

• Would we be able to cache search forms? Either by permissions (maybe hard - unless not OrgAdmin?) or user (maybe easier?)
• 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.
• 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? Perhaps provide an var option to disable to load of the search forms?

Possible Future

• Async Load the Report results
• Display multiple Data Representations method for a single search form on a one page (dashboard style?)

Design

1. Have the search widgets self-processing *client-side* into URL filters. No server-side search form processing at all, the server would always only parse URL filters.

2. Submission of the search-form collects these URL filters (client-side) and then sends them with a GET-request to the REST-API, either as Ajax or as full page request (=window.open). This request does not go to the /search method, but instead to the respective representation method (e.g. /report, /list, /map), without need for those method handlers to process the filters: they can simply assume that they get a pre-filtered resource.

3. The REST-API would then pre-filter the resource, and then hand it over to the requested method handler - map, list, report or whatever and in whatever data format (=RESTful request as usual). Whether this is Ajax or not depends entirely on the client-side implementation - it could be either. It could even be neither, but instead a web service request (e.g. from mobile clients, or from an external site) - which leads directly to point 4:

4. SearchWidgets/-forms can be requested directly from the REST-API (from the re-defined /search method) - so that they can be embedded everywhere - and get loaded asynchronously. Since they are processed client-side, there's no need to keep any formkeys or session variables. This GET /search method can also include loading of saved searches, and the POST /search method would then only serve for save search/subscription (which actually makes sense from the REST perspective), but not for processing the search.

This requires a fair bit of framework client-side (somewhat a client-side pendant for S3Resource), but this is something we might need anyway.

Implementation

Coming soon...

---

• BluePrints
• BluePrintSearch