On Wed, Nov 18, 2009 at 2:59 PM, Maris Fogels <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
