[responding waaay after the fact...] The metadata call is one of the few that does support jsonp. If you've been following along you'll see that the JSON-RPC endpoint supports it now and I have a patch review up for REST support.
Next step is to convert the metadata servlet into a proper 'Apps' handler that can be used with JSON-RPC and/or REST, eliminating one more custom piece of code/logic. On Tue, Mar 9, 2010 at 1:28 AM, Tim Wintle <[email protected]>wrote: > On Mon, 2010-03-08 at 14:25 -0800, Paul Lindner wrote: > > > > I'd love to see someone take this patch and make it generic.. If I > > had some > > spare cycles I'd do it myself... > > Unless I've missed something, it doesn't seem practical to have the > option of building the user pref UI client side unless the metadata call > supports JSONP or similar for X-domain metadata requests. > > > I.e. for this patch to work the javascript gadget object must have been > created with the correct user pref schema - which (as far as I know) can > either be: > > * Fetched from a container which already knows the user pref schema for > that gadget (in which case it could have templated the form cheaply > server-side). > > * Fetched via a POST metadata request. (with X-domain issues > surrounding this) > > We've used both of these techniques here - The server side technique is > more customizable and IMO better, but it can't be used on static pages, > and it either leads to a slight extra delay as the metadata request is > made, or (if cached) to noticable data integrity errors if the gadget > spec is updated in shindig's cache but not in the container's cache. > > The second technique requires a hidden gadget inserted onto the page > which can make the metadata call (as it's on the same domain), and then > use gadgets.rpc to send the schema back to the container. > > As I say, I may have missed an important call at some point that may > have made this easier - but it seems allowing cross-domain access to the > metadata call would be preferable in the second situation. > > Tim > > >
