← Back to team overview

launchpad-dev team mailing list archive

Redesigning lazr.restful support for AJAX

 

Hi Leonard,

During last week lazr-js sprint, we come out with a lot of issues around the 
current way we return HTML fragments from the web service. Initially, we 
thought that we needed to support HTML representation from named operation 
(filed as https://bugs.edge.launchpad.net/lazr.restful/+bug/480192) but after 
consideration, it turns out that this isn't sufficient.

Here are the constraints that we need to solve to make lazr.restful really 
useful in an AJAX environment.

1) We want to be able to retrieve one or multiple page fragments after making 
a model change through the web service (either PATCH or named operation).

   (For example, subscribing a user means that maybe two or three parts of the 
page will need to be updated.)

2) We want to reuse the presentation logic already coded in the regular web UI 
views.

   (We already have views that know how to render the different parts that 
needs to be updated on the page.)

3) We want to provide a very productive API for front-end developers to use. 
(Minimize amount of web-service specific glue needed, minimize the amount of 
confusing asynchronous requests that needs to be done).

So one solution we found out was to basically drop the way HTML representation 
are currently implemented for something much simpler and much more powerful.

Instead of wiring server-side one-to-one individual web-service resources to 
an HTML representation, we should basically let the AJAX client decide what 
should be returned from the web service call.

The client would request that one or more views be rendered after the 
successful completion of the API call and their results returned to the 
client.

We could use the accept-extension to the Accept header to specify the list of 
views to return results.

Something like:

Accept: application/x-page-fragments;views="subscribers=+subscriber-portlets, 
count=+subscribers-count"

That should return a JSON dictionary containing two keys: subscribers 
containing the result of the +subscriber-porlets view and count containing the 
result of the +subscribers-count view.

That removes the wiring that has to be done now server side to map these 
existing views to the HTML representation of fields, removes the problematic 
limitation of having only HTML representation and allows us to retrieve 
efficiently all the fragments we need on the page.

Thoughs and comments welcome.

Cheers


-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part.


Follow ups