Changes between Initial Version and Version 1 of BluePrint/Search/Client

11/08/12 01:06:02 (9 years ago)
Michael Howden



  • BluePrint/Search/Client

    v1 v1  
     1= !BluePrint: Client Processed Search Form =
     4== Introduction ==
     5Currently we're processing the entire search form server-side as a POST, have
     6the SearchWidget instances parse its variables into a S3ResourceQuery, then
     7perform a filtered CRUD/select and return the resulting datatable to the
     8client. For pagination of this datatable, we store the record IDs of the
     9result in the session to be able to run the datatable Ajax request against it.
     11Apart from all the implications for GUI design - from a REST perspective this
     12is totally wrong. It should definitely not be a POST - but a GET, and it must
     13not change state of the REST-API (i.e. must not store the IDs as filter
     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)
     20== Benefits ==
     21=== Functionality ===
     22* Improved performance through:
     23 * Asynchronous loading of the search forms
     24 * Asynchronous loading of the search results
     26=== Design ===
     27* We're replacing the current heavy S3Search module with a set of light-weight
     28widgets utilizing the (already existing) filter capabilities of the REST API -
     29a way less redundant and more RESTful, consistent, flexible, elegant and
     30scalable way to provide the same functionality.
     31* We're eliminating the need for duplication of Search code in both the Search and Report method
     33== Requirements ==
     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?)
     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?
     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?)
     50== Design ==
     511. Have the search widgets self-processing *client-side* into [wiki:S3XRC/RESTfulAPI/URLFormat URL filters].
     52No server-side search form processing at all, the server would always only
     53parse URL filters.
     552. Submission of the search-form collects these URL filters (client-side) and
     56then sends them with a GET-request to the REST-API, either as Ajax or as full
     57page request ( This request does not go to the /search method,
     58but instead to the respective representation method (e.g. /report, /list, /map), without need for those method
     59handlers to process the filters: they can simply assume that they get a pre-
     60filtered resource.
     623. The REST-API would then pre-filter the resource, and then hand it over to
     63the requested method handler - map, list, report or whatever and in whatever
     64data format (=RESTful request as usual). Whether this is Ajax or not depends
     65entirely on the client-side implementation - it could be either. It could even
     66be neither, but instead a web service request (e.g. from mobile clients, or
     67from an external site) - which leads directly to point 4:
     694. SearchWidgets/-forms can be requested directly from the REST-API (from the
     70re-defined /search method) - so that they can be embedded everywhere - and get loaded
     71asynchronously. Since they are processed client-side, there's no need to keep any formkeys or
     72session variables. This GET /search method can also include loading of saved
     73searches, and the POST /search method would then only serve for save
     74search/subscription (which actually makes sense from the REST perspective),
     75but not for processing the search.
     77I know that this requires a fair bit of framework client-side (somewhat a
     78client-side pendant for S3Resource), but this is something we might need
     812) Search-forms can be requested from the REST API using the GET /search
     82method. That way, they can be embedded in every page - and get loaded
     83asynchronously. Since search forms would never get submitted to the server,
     84there is no need to store anything server-side anymore.
     86== Implementation ==
     87''Coming soon...''
     90* BluePrints
     91* BluePrintSearch