Changes between Version 2 and Version 3 of BluePrint/Search/Client


Ignore:
Timestamp:
11/08/12 01:08:32 (9 years ago)
Author:
Michael Howden
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrint/Search/Client

    v2 v3  
    2525
    2626=== 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.
     27* 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.
    3128* We're eliminating the need for duplication of Search code in both the Search and Report method
    3229
     
    55523. 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:
    5653
    57 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.
     544. !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.
    5855
    5956This requires a fair bit of framework client-side (somewhat a client-side pendant for S3Resource), but this is something we might need anyway.