launchpad-dev team mailing list archive

[Edwin Grubbs <edwin.grubbs@xxxxxxxxxxxxx>]

On Wed, Nov 18, 2009 at 2:59 PM, Maris Fogels
<maris.fogels@xxxxxxxxxxxxx> wrote:
> 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


Leonard already mentioned HTTP Pipelining, but I didn't see any
explanation why we wouldn't want to use that instead of our own custom
header processing.

-Edwin