Hi Johan, I think support for JSONP is a great idea! And I'm glad you understood the intention behind Exhibit.loadDataFromTable. Which helps illustrate that although I have ideas of where Exhibit is going, I really have no time to implement those ideas. So any help with coding and designing the infrastructure is greatly appreciated. :-)
My thesis advisor has been pushing me to support many input formats. If he had his way, Exhibit would be reading Bibtex files and Excel spreadsheets directly! (Parsing Excel files in Javascript?!) So if you give me a patch of importers, you're helping me graduate earlier, haha :-) We can carry out discussion about the nitty gritty technical details of this importer architecture off the list. David Johan Sundström wrote: > I'd like to adopt Exhibit to interface not only with static JSON data > sets, but dynamic JSONP data, a web service consumption format > increasingly available these days (especially Yahoo!, but also Google > and many others have started to catch on here). > > JSONP, summarically, bridges the same-domain restriction of > xmlhttprequest, by serving and consuming data as you would include any > javascript code, and the data payload is a common JSON object > encapsulated in a javascript callback of your own choosing (you > specify its name in a URL query parameter named "callback"). An > example (somewhat relaxed -- purists might argue the array should have > been encapsulated in an object with an items property, as does > Exhibit): > http://www.gvisit.com/json.php?sid=gvisit&callback=Exhibit._internalCreate > > Few services today natively produce Exhibit compatible JSON output, > but massaging a JSON schema into any other is a relatively > uncomplicated task, so it isn't very difficult to achieve something > like this. > > I would find it natural to extend the Exhibit block design model a bit > to cater use cases like this through adding importer components, just > as well as the present exporters. JSONP importers would register a > JSONP feed URL and an optional schema translator function with some > method similar to the Exhibit.loadJSON, Exhibit.loadDataFromDomNode > and Exhibit.loadDataFromTable methods already sketched in the present > API on trunk (I find the latter methods very interesting, for graceful > degradation and present-day search engine interoperability reasons -- > if you have any design thoughts I'd be glad to hear some, and might > contribute the code, if they are far away from any present roadmaps). > > My reason for bringing up the JSONP issue isn't so much to ask for > help implementing the feature, but to get your input on a design you > might consider for inclusion in your upstream codebase, so I needn't > fork my own just to add functionality largely orthogonal to the neat > facet browser. > > _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
