We talked about the differences between using proxied and inline content within a gadget in Chapter 3 in the section Inline Versus Proxy Content. Depending on the architecture and needs of their application development environment, many developers may prefer the proxied content approach for its ease of use.
If the markup for the
sections of your gadget is defined with a proxied data source, the way
you make container data sources available to that file is very similar
to the methods we have used in earlier sections:
<Content type="url" view="canvas" href="http://www.mysite.com/canvas.php"> <os:PeopleRequest key="ownerFriends" userId="@owner" groupId="@friends" startIndex="10" count="20" fields="name,nickname,gender,birthday" /> </Content>
The full code for this sample is available at https://github.com/jcleblanc/programming-social-applications/blob/master/chapter_7/data_request_proxied.xml.
We define our
with our proxied content being loaded through the file specified in
Normally, when using proxied content, we would have a self-closing
Content node, but to add the
container data we instead embed the data source that we are looking
for—in this case, a subset of the application owner’s friends.
Once the proxied content source is fetched, all of the data
sources requested will be passed to the file as POSTed JSON objects. If
the container cannot also send the
opensocial_owner parameter (which contains ...