launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

On November 18, 2009, Maris Fogels wrote:
> On 09-11-16 06:06 PM, Francis J. Lacoste wrote:
 >
> > 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.)
> 
> Does anyone have any other examples of when this would be useful?

Adding a team member inline requires updating three or four parts of the page. 
(Salgado and Bjorn have the details).

It's a pretty common pattern.

> 
> > 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.
> 
> I assume you are calling the webservice as you would normally, but you are
> adding your special Accept header?

Yes, the idea is that the client controls the result part.

> 
> If that is the case, then it still feels a bit strange.  You are taking the
>  API model and namespace, and mapping that onto a set of page fragment
>  names. However, this set of fragments actually represents the Launchpad
>  website URL model, not the API model.  You are telling the webservice "Get
>  me a bug comment, but using this magic word, return it to me as >  it would
>  appear on the page at /+bugs/1234/."

A fragment is a view.

The common use case is not 'Get me a bug comment', but 'Create a bug comment 
and give me the result formatted through '@@bug-comment-details'. 

Or 'Subscribe this user' and gave me back '@@+portlet-subscribers, 
@@subscribers-count'.


> 
> If you want a real loop, look at it this way:  you map the database model
>  to the webservice WADL addresses, and you map the database model to the
>  website URL addresses.  URLs are rendered by views.  OK.  We are
>  suggesting that views are also rendered by Fragment Names.  Also OK.  But
>  then we are say that to call the Fragment Name, you have to know the
>  correct address, and that address is an object picked out of the WADL? 
>  Why not use the address you already have, that being the URL of the page
>  you are currently visiting?
> 


I think that we should allow both absolute and relative URLs to be specified. 
In the common case, the view will be found on the target object, but 
something, the HTML you are interested is form a subobject or the parent. So 
we should support both relative and absolute paths.

> Instead of mapping one namespace onto the other, could we just call the
>  current page address to fetch the fragment? 
>  Y.io("?fragment=A&fragment=B").  I guess this is the +fragments solution
>  Aaron pointed to?  What exactly are the problems with it?

I don't understand what you are saying. This solution is exactly the same than 
what Aaron was suggesting, but using passing the views you want to 

-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

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