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

Timestamp:

11/08/12 01:08:32 (12 years ago)

Author:

Michael Howden

Comment:

--

BluePrint/Search/Client

@@ -25 +25 @@
 
 === 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 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
 
@@ -55 +52 @@
 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.
+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.