Your XML is fine. Looks like this is a NekoHtml bug in their namespace support - os:DataRequest works with the Shindig XML parsing (pipelining for proxied rendering) and breaks in HTML (pipelining for templating).
On Wed, Jun 3, 2009 at 4:27 PM, Cassie<[email protected]> wrote: > I thought I was following the spec correctly: > > <script xmlns:os="http://ns.opensocial.org/2008/markup"; > type="text/os-data"> > // First rpc call > <os:ViewerRequest key="viewer"/> > <os:PeopleRequest key="ownerFriends" userId="@owner" > groupId="@friends" count="24" filterBy="PUBLICLY_VISIBLE"/> //Count for > default members gadget > <os:DataRequest key="siteSettings" method="extensions.get" > command="GetSiteSettings"/> > <os:DataRequest key="friendRequests" method="extensions.get" > command="GetFriendRequests"/> > > // Second rpc call > <os:PeopleRequest key="friends" userId="@viewer" groupId="@friends" > count="20"/> //Count for default members gadget > <os:PeopleRequest key="isViewerAdmin" userId="@viewer" > groupId="ADMINS"/> > </script> > > Am I missing additional params? > > - Cassie > > > On Wed, Jun 3, 2009 at 3:50 PM, Kevin Brown <[email protected]> wrote: > >> I get that when I don't include a correct xmlns declaration for my >> template. >> Does your namespace declaration match what's expected exactly? >> >> On Wed, Jun 3, 2009 at 3:43 PM, Cassie <[email protected]> wrote: >> >> > I have a gadget that is doing server side data pipelining and has a >> request >> > that looks like this: >> > >> > <os:DataRequest key="settings" method="extensions.get" >> > command="getSettings" >> > ... /> >> > >> > This is alongside an os:PeopleRequest, os:ViewerRequest etc. The normal >> > people and viewer requests are working fine for me, but the datarequest >> is >> > failing because on PipelinedData line 365 inside of createDataRequest the >> > method uses the call attrNode.getLocalName(). >> > >> > getLocalName() continually returns null for all of the attributes on that >> > datarequest on my box. getNodeName() however returns the right thing - >> > "command", "key" etc >> > >> > So, I'm wondering if anyone else has seen this problem and if it would be >> > an >> > issue to switch from getLocalName to getNodeName. (Note the other request >> > parsing calls know what the names of the attributes are so they call >> > getAttribute(name) which isn't affected here) >> > >> > Thanks! >> > - Cassie >> > >> >
