launchpad-dev team mailing list archive

[Maris Fogels <maris.fogels@xxxxxxxxxxxxx>]

On 09-11-18 02:06 PM, Francis J. Lacoste wrote:
> 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.

Salgado explained the case of adding a new team member.  So there is a bit of 
logic involved:

  1) If it is a person, update the members count and the members list
  2) If it is a team, just update the members count
  3) If the new member is inactive, update both the 'pending members' and 
'recent members' lists and counts.

He noted that all of these updates take place inside the same portlet.


> > 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'.

Ah, so I had the basic case wrong: you are talking about updating as a result of 
create operations, not plain old read operations.

And you are stating that the general case is updating within a single portlet or 
module.  So after an operation to update a module's contents, why not just 
return the whole module's representation, rather that getting a specific return 
value and then futzing around with the DOM using JS?

> > 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.

"the view will be found on the target object" -- finding said target object is 
the URL/WADL addressing mind-twist that I was speaking of.

So you are saying that looking for a fragment relative to the 'self_link' is 
also the common case?

As you said earlier, the common case is "create Foo, via the webservice". 
Therefore, to update an on-page object, you need to find a webservice address 
it.  So my argument that it is tedious finding webservice addresses for on-page 
objects has fallen: you must already look up the webservice addresses for 
on-page objects in order to create or update them.


> > 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 

Looks like your reply got cut off here?

I was suggesting that you add "?fragment=foo" to the current URL, then submit 
that to the current URL in order to return the fragment you want.  Aaron's 
solution simply adds "+fragments" or something similar to the current URL, in 
order to clean up the URL address space.

The only way +fragment URLs would work would be to treat each portlet or module 
as a sub-page with a valid URL.  For example, the subscribers portlet would have 
a valid URL like "/+bug/1234/subscribers/+fragment".  You would POST to the 
module +fragment URL to update it's contents, read the POST response, and 
replace the module's contents with whatever comes back.

The technique would perform the same operations as we do via the webservice, but 
using a different set of names and addresses.  It would be slightly easier for 
the developer because they do not have to understand the webservice's model to 
work with the page contents.  However, decoupling the webservice and the 
Launchpad pages leads to other problems.


Maris

Attachment: signature.asc
Description: OpenPGP digital signature