Exhibit 2.0

Exhibit 2.0 is under heavy development and has not been released in any form. Please do not rely on it yet. Use it only if you're sure you want to be the bleeding edge.

For migrating from 1.0 to 2.0, see this message.

[edit]

The 2.0 API URL

  • bundle=false By default, a bundled version is loaded, meaning lots of files are concatenated into larger files that can be fetched in fewer HTTP requests from simile.mit.edu, meaning quicker load times for you and your visitors. When living on the bleeding edge of development (the 2.0 branch is still busy, and has not entered maintenance and bug fixes only mode, as the 1.0 branch has), the bundled version is not always in sync with the latest state of all those tiny files it is made up from, so if you want to make sure you run the very latest code, use this option.
  • autoCreate=false By default, Exhibit tries to create a database, load data referenced by <link>s in <head>, and then, if there is no ex:ondataload handler on the <body> element, create an exhibit. You can avoid this behavior by setting autoCreate to false.
  • views=... Comma-separated list of views that will not be loaded by default, unless asked for by listing them here. Presently, the only views loaded just-on demand are "timeline" and "map".
  • gmapkey=<86 character Google Maps key here> When using map view, you need to list your Google Maps API key for the URL your Exhibit resides on. (If you list this parameter, views=map is implied, if you're feeling lazy.)
  • locale=<language code> Force the Exhibit into using the specified language locale, if supported. Legal language codes are presently ISO-3166 country codes (2 characters), but ISO-639 language codes (3 characters) will be supported. Presently, Exhibit by default is English (en), and has Spanish (sp) and Swedish (sv) locales registered. The present state of the 2.0 API's localization is also most likely broken and pending serious refactoring.
  • callback=<javascript function name> On including the Exhibit 2.0 API, your page's <head> tag is typically scanned for <link rel="exhibit/data"> elements pointing out Exhibit data resources that are loaded, a database object is set up and loaded with them, the exhibit object is created and initialized with the DOM configuration of all exhibits set up in the page. You can override that behaviour by providing a callback argument, which will get called instead, as soon as all of Exhibit has been loaded, if you want to do something else then instead. So if you specify callback=foo, foo() will be invoked when the Exhibit API is fully loaded and available. You might want to peek through the code that would otherwise be run, if you would want to do something similar.

This is probably mostly useful if you are doing something magic, like rendering Exhibits in other people's web pages by loading Exhibit from a bookmarklet or user script. If you are doing that, you are likely also interested in the next two parameters:

  • js=<url> You may specify any numer of javascript files (as separate js=<url> parameters), which will be loaded together with the Exhibit API, before firing the callback parameter.
  • css=<url> Like the js parameter, you may list any number of CSS files that are to be loaded.
  • A rather fully laden example query (here separated by whitespace for readability -- remove those), showing how to combine parameters, utilizing lots of the above, for loading the unbundled files, jQuery, YUI-Ext 0.33, Exhibit, some YUI-Ext CSS, both timeline and map views, and log in the Firebug console when everything has been loaded:

?bundle=false &js=http://jquery.com/src/jquery-latest.pack.js &js=http://ecmanaut.googlecode.com/svn/trunk/lib/YUI-Ext-0.33.js &css=http://www.jackslocum.com/deploy/yui-ext/resources/css/yui-ext-css-1228.php &views=timeline,map &gmapkey=you'll-have-to-list-your-own-key-here &callback=(function(){console.log(%22Loaded!%22)})

Append the query to the API url, and watch the magic happen. :-)

--Ecmanaut 18:06, 23 May 2007 (EDT)

[edit]

Exhibit 2.0 Road map

  • The Todos section lists some bite-sized tasks, and here are some even less structured, potentionally sometimes overlapping, notes on where things are headed, taken down from recollection of things discussed on-list and/or on IRC. Some hints can be gleaned from the recommendations of preparation for UROPs that will be part of Exhibit's grandiose future.
  • Refactor Exhibit to use jQuery (18k), instead of reinventing so much of it less well thought through on the spot as we need features it already has. For instance, we really need an animation kit, and jQuery sports a great one; visual jQuery has plenty pleasant docs to peruse on the subject -- peek at Effects -> animate, for instance. Much other DOM dribbling is suspected to shrink noticably on moving from DOM APIs to jQuery.
  • ISO 639 language codes will be supported, and locales will move from en->eng, sp->spa and sv->swe in the directory tree. Two letter aliases will be understood and remapped to these as well. Present source tree does not have file naming consensus across languages, for no good reason.
  • Loading all locales at the same time will probably be supported, so changing language can be done client side and run time. (Perhaps not via the Exhibit UI itself, but certainly via some javascript crafted by the exhibit author.) Primary reason to allow this might rather be to allow sumo bundling.
  • Exhibit's database operates solely on sets. That used to mean that exhibit expressions doing add() across some facet, for instance, would not add all items matched, but one of each matched. Exhibit expressions will support .@ and !@ for evaluating to arrays rather than collapsing to sets prior to calling the function. (This will not change the database, though, only the expression parser.)
  • Bundles are presently not 100% bundled up into one javascript file and one CSS file to load, but still loading locales and some views on demand. This is subideal for some kinds of deployment (like user scripts, where the entire API should ideally be available instantly, client side), where loading everything there is at once in a big sumo package works better. Both modes of use have their merits, and should probably be available side by side.
  • Moving to JSDoc for making automatic reference documentation of all APIs and code.
  • Possibly also moving to using Selenium for automated test suites. Having done so, we should also submit Exhibit to Mozilla's repository of web APIs used for doing browser regression testing, which means we'll be less likely to get issues with future Firefox (and possibly other browsers) releases for using code or features not already exercised by their present test suites.
  • TabularView should take optional render templates where you lay out each <tr> however you like, using the common DOM layouting features.
  • Support for embedding expressions within formatting specs (for table view and the like); something looking a bit like CSS (supporting number, date, text, image, url, item and currency) - see details

--Ecmanaut 18:53, 23 May 2007 (EDT)

Retrieved from "http://simile.mit.edu/wiki/Exhibit/2.0"